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

Here is my board.

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 :slight_smile:

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