Unable to see emonTx inputs

Getting Started
21

Hi Paul,

Thank you- I tried the first part, and nothing happens.

Looking at the board, one of the solder joints does look a bit dry. I will
get the iron out and touch them all up to be sure.

I did previously hit the “emonbase update” button on emoncms local. But
since then I have redone the SD card image. Will this have written onto the
RFM12B as well? Having said that, I don’t think it worked before I hit
update.

When you say to try putting another sketch onto the RFM12Pi, how would this
be done (through the Pi, or another means?)

Will get back to you soon.

Chris

22

Yes! this would have most definitely have been the cause of the issue if it hadn’t already not worked, so you may have more than one issue now.

Yes, sorry another way of saying “installing firmware”. The RFM2Pi board’s software is referred to as firmware in a more general term, but also refered to as a “sketch” in Arduino speak.

What Glyn and I have tried walking you though (above) is installing a firmware to the RFM2Pi via the Pi. The firmware is in “hex file” form which is the result of compiling the “sketch” in an IDE (Integrated Development Environment).

1 Like
23

Hi again. I’ve resoldered the joints, but nothing has changed. The command;

sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

doesn’t do anything.

I’m wondering if the RFM12B is dead. I have a spare one somewhere, so I might swap it over when I get some time. Will let you know how it goes.

Unless you have any other suggestions?

Chris

24

Did you stop emonhub first?

sudo service emonhub stop

This is required since emonhub is hogging the serial port.

25

Yes- still doesn’t come back with anything. Unless it takes a while (have waited over 5 mins)?

26

Are you able to link the Rx and Tx pins of the Pi’s GPIO together using a female-female link wire or something similar?
Obviously the Pi should be powered down whilst removing the RFM2Pi and fitting the link, but once powered up you can test the Pi’s serial port lines, connectors and port mapping all in one go by using minicom, anything written to the serial port should echo back and be displayed by minicom.

27

Would that be GPIO pins 14 adn 15 on the below?

image.png856×722 125 KB

28

Correct, outside row, 4th and 5th pins down from the corner of the Pi,

29

If I’ve understood right, the object here will be to see if the Pi is functioning correctly, i.e, what signals is it sending to the RFM12Pi.

I have another Pi with another RFM12Pi module on it, which is working fine. I just removed the RFM12Pi and replaced it with the one that doesn’t seem to work. I get the same problem- green led stays on, not picking up any nodes.

So surely this says that the Pi is fine, and the issue is with the RFM12Pi or the RFM12B module?

Then the test on the Pi you suggested isn’t needed?

Chris

30

Almost!

your test proves there IS something wrong with the RFM2Pi but it does not prove there is nothing wrong with the Pi.

Whilst the suspect RFM2Pi is on the known good Pi, try the avrdude test command (assuming that is also running an emonSD image that is)

sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

If there is no response from the suspect RFM2Pi then it looks like the first Pi MIGHT be ok but the “linked pin test” or moving the known good RFM2Pi to the first (suspect?) Pi would confirm the Pi is ok (or not)

If there is a response from the suspect RFM2Pi when on the known good Pi, that would suggest there is also a problem with the first Pi.

31

So I got a response;

pi@emonpi(ro):~$ sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

avrdude-original: Version 6.1, compiled on Jul  7 2015 at 10:29:47
                  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.01s

avrdude-original: Device signature = 0x1e950f
avrdude-original: safemode: lfuse reads as 0
avrdude-original: safemode: hfuse reads as 0
avrdude-original: safemode: efuse reads as 0

avrdude-original: safemode: lfuse reads as 0
avrdude-original: safemode: hfuse reads as 0
avrdude-original: safemode: efuse reads as 0
avrdude-original: safemode: Fuses OK (E:00, H:00, L:00)
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
pi@emonpi(ro):~$
32

I’m afraid I don’t know what any of this means! Broken pipe?

33

Can you confirm, was that from the suspect rfm2pi on the known good Pi?

Don’t worry about the strace: |autoreset: Broken pipe they are an unavoidable annoyance from using pipe and appear even during a fully successful upload. The important part is it is clearly communicating with the device bootloader which means you can install a firmware.

[edit] If this is the suspect rfm2pi on the known good Pi, you could continue with the previously suggested steps

rpi-rw
sudo chown pi:pi -R RFM2Pi
cd RFM2Pi
git pull
cd firmware/old/RF12_Demo_atmega328
sudo service emonhub stop
sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RF12_Demo_atmega328.cpp.hex
sudo service emonhub start

at which point the “suspect rfm2pi” should start receiving data as the known good rfm2pi was. Then if that is the case, return the “now fixed rfm2pi” back to it’s original “suspect” Pi and see if that works, if not we need to focus on that.

34

That’s correct. I have used the pi to upload the firmware onto the ‘dodgy’
RFM12B.

Chris

35

i was editing my reply while you were posting.

So have you already installed a new FW? or just tested as per your log above? that has just read the chip details not uploaded FW. see the [edit] part of my last post

36

Just saw your reply. Yes, I did this, using the commands you gave earlier in the thread. The green LED light is now permanently off. No inputs can be seen on emoncms (which they can with the fully working RFM2Pi.).

I’m now going to try the working RFM2Pi on the ‘dodgy’ Pi.

37

Ok, so the working RFM2Pi doesn’t seem to work on the dodgy Pi (using sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 causes SSH to freeze, as in previous cases.)

Will try the pins on the Pi.

38

Did you restart emonhub on the good Pi after loading FW to RFM2Pi?

You should also be able to use minicom and confirm the rfm2pi is reponding to commands like “v” for the firmware version etc. Do you run the stock rfm network setting? ie group 210 and 433Mhz, emonhub only set those at start up or after the conf is edited.

Ensure “quiet = false” is set in [[RFM2Pi]] [[[runtimesettings]]] in emonhub.conf too, that may help see more data.

ok that doesn’t sound good. Do you have a spare SDcard ? or can you confirm the SDcard image in the suspect Pi is absolutely stock? you haven’t altered anything at all?

39

The SD card was written earlier in the week, but I did change the config file- there are two settings to do with HDMI which I altered so that it would display on a VGA display. This was so I could access the pi without knowing it’s IP address (the pi is on my officr network and I wasn’t sure how to find the IP address; fing didn’t work).

Could this have affected anything?

40

Sorry gents. I’m confused, and you probably are too. I decided to go back to the beginning again to try and get my head around things;

Setup 1. Pi (working) + RFM2Pi (working)
Bizarrely, this didn’t see to work to start with. No inputs were being recorded. Then, apparently for no reason, it started working. Sometimes there is no input for over a minute. Is this normal? Possibly a separate issue!

Setup 2. Pi (working) + RFM2Pi (dodgy)
Contrary to my previous post, this is now working as well as setup 1, giving me input readings every few seconds. However, as I write, there has been over 4 min gap between two inputs. Is this normal?
I’m guessing putting the correct firmware onto the RFM2Pi seemed to do the job.

Setup 3. Pi (dodgy) + RFM2Pi (working)
Now working! However, when I do the avrdude test command (stopping emonhub before, and start after), I still get no response.

Setup 4. Pi (dodgy) + RFM2Pi (dodgy)
Working! Same as setup 3, though- no response to the avrdude test.

So, somehow, things seem to be working…sort of.

Any thoughts?