If the rfm2pi has been successfully reflashed with the latest firmware it will now be using a baud of 38400 (regardless of being rfm12 or rfm69) so emonhub.conf will need to be changed.
1 Like
Yes I re flashed from the admin menu, it seems to not respond.
pi@emonpi:~ $ sudo systemctl stop emonhub.service
pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 9600
â Miniterm on /dev/ttyAMA0 9600,8,N,1 â
â Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H â
pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 38400
â Miniterm on /dev/ttyAMA0 38400,8,N,1 â
â Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H â
This is likely to be me not understanding but is flashing with success possible even if its a dead card ?
It is from 2013, all my devices are 868Mhz is it possible to buy 868 stuff from the store still?
Useful to know - thanks Paul.
No unlikely to be successful. When you update just the emonhub from the UI, is there anything in the logs?
[edit]
source for the update script https://github.com/openenergymonitor/EmonScripts/blob/stable/update/rfm12pi.sh
Try it manually and see what output you get.
wget https://raw.githubusercontent.com/openenergymonitor/RFM2Pi/master/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATmega328.cpp.hex -O rfm12pi.hex
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:rfm12pi.hex
Previously on the admin page it gave
Flashing RFM12Pi
avrdude-original: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/root/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyAMA0
Using Programmer : arduino
Overriding Baud Rate : 38400
avrdude-original: Using autoreset DTR on GPIO Pin 7
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 4.4
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude-original: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude-original: Device signature = 0x1e950f (probably m328p)
avrdude-original: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude-original: erasing chip
avrdude-original: reading input file "/opt/openenergymonitor/data/firmware/rfm12pi.hex"
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex auto detected as Intel Hex
avrdude-original: writing flash (8982 bytes):
Writing | ################################################## | 100% 3.08s
avrdude-original: 8982 bytes of flash written
avrdude-original: verifying flash memory against /opt/openenergymonitor/data/firmware/rfm12pi.hex:
avrdude-original: load data flash data from input file /opt/openenergymonitor/data/firmware/rfm12pi.hex:
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex auto detected as Intel Hex
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex contains 8982 bytes
avrdude-original: reading on-chip flash data:
Reading | ################################################## | 100% 2.79s
avrdude-original: verifying ...
avrdude-original: 8982 bytes of flash verified
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
avrdude-original done. Thank you.
strace: |autoreset: Broken pipe
Flashing RFM12Pi done
Having now tried again from ssh it errors, it also now errors in the admin page
pi@emonpi:~ $ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:rfm12pi.hex
avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfc
avrdude-original done. Thank you.
So perhaps it is hardware, I will clean it and if not hope 868Mhz still works on the new ones
Try a hard power cycle (not just a reboot - remove power).
More to the point, is it really a RFM12B thatâs trying to use the RFM69 code? Or vice versa? Itâs worth checking. Pictures of the RFM modules are in LearnâElectricity MonitoringâNetworkingâWhich radio moduleâIdentifying different Radio Modules
The sketch will lock solid if it is, but it will still be programmable.
Power removed from the pi and reapplied
Same thing.
avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude-original done. Thank you.
strace: |autoreset: Broken pip
A 433 MHz module will work at 868 MHz, but the range will be seriously limited, and if transmitting, you risk damage to the module if you turn the power up (because the output stage and antenna are not matched).
If you are replacing, itâs worth checking with the shop to see if theyâll either supply it without the radio module, or swap it for you.
That link is what is in GitHub for updating an RFM12Pi according to the update script (as posted).
The point is, what is the radio module itself? I understand in the early days, for the emonBase using Martin Harizanovâs âRFM12B Raspberry Pi expansionâ, RFM12Bs were used, then replaced by the RFM69CW. And then the âRFM12B Raspberry Pi expansionâ itself was replaced by the"RFM69Pi RaspberryPi RF expansion".
As far as I know, the emonPi has only ever had the RFM69CW.
I thought the 12/69 in the name refers to the RFM chip. @TrystanLea @glyn.hudson
The GitHub repository notes arenât definitive RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328 at master ¡ openenergymonitor/RFM2Pi ¡ GitHub but it does look like that is the right hex for the RFM12.
It ought to, but it doesnât with total unambiguity.
Very definitely a Martin Harizanovâs RFM12Pi âRFM12B Raspberry Pi expansionâ with very definitely a RFM69CW.
Iâm not saying this is the problem in this case, it looks like not, but itâs something to be aware of and check.
1 Like
Definitely a RFM12B. And unless you specifically uploaded the RFM12B version of the software, it will have defaulted to the RFM69 software and the sketch will lock up and not communicate.
This should not affect how the Pi itself runs, but of course if the radio isnât working, youâll have no input to emonHub, and nothing into anywhere else downstream.
The firmware that Trystan linked to (post 51) MQTT change now nothing works even after returning to defaults - #51 by TrystanLea is definitely for the RFM12B and communicates at 9600 baud (youâll need that setting in emonhub.conf).
But that is not the same as what Brian posted here (post 63) MQTT change now nothing works even after returning to defaults - #63 by borpin
I have that file on my emonPi, and the C source contains this:
#define RF69_COMPAT 1 // define this to use the RF69 driver i.s.o. RF12
If the .hex was compiled from that, and this link
has that same line in the source, IT WONâT WORK because it will be using RFM69CW commands to a RFM12B radio.
You must make sure you get the RFM12B compiled version RFM12_Demo_ATmega328.cpp.hex
Notwithstanding that, you should still be able to program the Atmel '328P.
The first problem will be communicating with the Atmel '328P in programming mode. Thatâs not happening, according to
avrdude-original: stk500_recv(): programmer is not responding.
When youâve solved that, the second problem will be getting the correct sketch, or changing that line and recompiling, and uploading it to the '328P.
Sorry Iâm not a Pi expert, so I canât help with the how-to.
[Edit]
Have you changed the clock speed of your Pi? Remove the following lines from /boot/config.txt :
arm_freq=1200
arm_freq_min=600
and replace with
[pi3]
arm_freq=1200
arm_freq_min=600
[pi2]
arm_freq=900
arm_freq_min=600
[all]
@TrystanLea, If Robert is correct, the emoncms update will break every installation with this board as that is the firmware in the update script.
Hang on @Robert.Wall, that is the one I linked to for the wget!
https://github.com/openenergymonitor/RFM2Pi/blob/master/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATmega328.cpp.hex
I downloaded and compiled the source, and neither the RFM12B nor RFM69CW versions matched any of the file sizes offered by Github. So I havenât a clue whatâs going on.
All I do know is if you havenât got the latest hardware (as I havenât), you canât blindly follow the instructions because of things like the ones I mentioned.
Yes, but you wrote that before we knew for certain that Dave had a RFM12B radio.
I suspect heâs by default loaded the '69 software. It doesnât explain why he canât communicate with the Atmel '328P though, unless arm_freq=1200 has crippled it.
But unless you use identical versions of the other libraries and/or core they wonât, will they?
I donât think that makes any difference - itâs just a UART that is being used - that refers to the SOC.
Based on his earlier post I was 99.9% confident 
Unless the timing has screwed up avrdude. It still should be set properly anyway, or shouldnât it?
So is it bricked and I should buy a new one ?
/boot/config.txt is empty