Archived Forum

Good work getting uip and running.  

What sketch are you running on your emonTx shield? It looks like a decoder error. The default emonhub.conf is expecting 5 x integers "power1, power2, power3, power4, Vrms". You might have to adjust the .conf file (edit via emonHub tab in local Emoncms to match what your transmitting. 

[[6]]
    nodename = emonTxShield
    firmware =emonTxShield
    hardware = emonTxShield
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms
       datacode = h
       scales = 1,1,1,1,0.01
       units =W,W,W,W,V

Default .conf file:

https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf

Hi,

I'm running the Shield_CT1234_Voltage sketch on Arduino Uno. I edited the .conf file to match the example but it didn't fix the problem,

I logged into the emonpi using putty and found the following exception when the thread died. Any ideas?

pi@emonpi ~ $ Exception in thread RFM2Pi:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
    self.run()
  File "/home/pi/emonhub/src/interfacers/emonhub_interfacer.py", line 73, in run
    rxc = self.read()
  File "/home/pi/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 127, in read
    c.rssi = int(f[-1][1:-1])
ValueError: invalid literal for int() with base 10: '-\xb33'

It looks like you are getting some rogue characters slipping in from somewhere. The payloads should only consist of numeric values beyond a leading "?" or "OK" and the trailing rssi in parenthesis. The traceback confirms the "-\xb33" is not an integer and causes the the thread to crash as the rssi should be an integer and not contain "�". emonhub could be altered to handle the exception better but the fact remains the serial data is being corrupted somehow. 

It looks like it only effects the invalid packets (but this is quite a small amount of log so may not be the case) ifthat is the case the issue may be sidestepped by setting [[RFM2Pi]] [[[runtimesettings]]] quietmode = true in emonhub.conf, that will instuct the rfm69pi to not pass the invalid packets, again not really a fix.

To fix this you will first need to know if its coming in via the serial port, try stopping emonhub " sudo service emonhub stop" and using a serial console like "minicom" to see the raw serial data, from what you've said it shouldn't take long to see whether there are any non-numerical values being passed outside the range of 0 to 255, or odd symbols etc

the rfm69pi to emonhub connection must have exclusive use of the serial port and if anything else attempts to use the port then you will get un predictable results. I sort of half expect an outside influence as there is no reason for the rfm69pi to pass erratic data and yet emonhub logs the corrupt data almost immediately upon receipt.

So can you test does it do it in quiet mode? Can you see anything in minicom? (you can restart emonhub again with " sudo service emonhub start" after testing) and also do you know what version firmware is running on the rfm69pi? or more importantly what baud it is running at?

Paul

Hi Paul,

Thanks for your assistance, I set the quiet mode to true as follows, It looks like the bit rate is 38400. not sure how to see the firmware version.

[interfacers]
### This interfacer manages the RFM2Pi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,
       
        # datacode = B #(default:h)
        # scale = 100 #(default:1)
        group = 210 #(default:210)
        frequency = 433 #(default:433)
        baseid = 5 #(emonPi default:5)
        quiet = true #(default:true)
        calibration = 230V #(UK/EU: 230V, US: 110V)
        # interval = 300 #(default:0)
        # nodeoffset = 32 #(default:0)

I also had a look at the minicom output with the emonhub stopped and this is data from minicom

OK 6 0 0 0 0 0 0 0 0 213 94 (-29)
 ? 6 0 0 0 0 0 0 0 0 94 212 (-29)
 ? 51 18· 118 239 191 94 24³ 201 164 163 29 208 143 165 63 220 128 222 196 190
 ? 19 240 8 54 17 213 73 ·1 103 91 111 233 30 231 199 255 45 243 171 250 253 (-
 ? 128 142 215 254 181 ²�L¤&¦&S)�Â�Â�²����ºÂ��ª��¢���ÊʪÊʊ�������ÂB
 ? 46 13· 26 14 67 232 223 95 232 120 95 234 176 20 167 26 210 9 61 223 114 (-9
OK 6 0 0 0 0 0 0 0 0 2 95 (-29)
OK 6 0 0 0 0 0 0 0 0 122 94 (-32) �
                                    ? 197 16 95 205 198 193 80 80 72 102 140 31
OK 6 0 0 0 0 0 0 0 0 91 94 (-30)
 ? 5 241 71 128 99 230 233 143 196 108 134 85 4 243 11 128 55 191 128 203 31 (-
 ? 142ӊ�����ª¢��Â����ºÊʂªÊʚ���¢²��ª�����Êʊ�²¢ª�²º��ÂBj���Jj�Êʚ²Â�º��Bj
OK 6 0 0 0 0 0 0 0 0 237 94 (-29)
 ? 59 27 28 15 65 25 251 80 98 230 197 185 231 199 30 40 54 175 236 131 251 (-1
OK 6 0 0 0 0 0 0 0 0 205 94 (-28)
 

Could this be 433 MHz interference?

I'm not able to say with absolute certainty that it's not RF interference, but I suspect not. I would expect anything not discarded or handled by the rfm69pi firmware to be numerical, anything else that is not a valid command and actioned will be garbage and cause the packet to be discarded.

If you send a question mark from minicom, the help text should be returned which will include the firmware version. Is this help text totally legible or contain rogue characters like the log above?

Another test could be to remove the rfm69pi and retest with minicom, there should be no data traffic with emonhub stopped and the rfm69pi removed as they need exclusive use. If there is any data appearing in minicom that would suggest something else is using the serial port and if that data is garbage as above, it may be using a different baud rate, so you could try some other baud rates to help identify the source by making the data legible.

If there is no other serial traffic, it may be well worth trying to (re)install firmware to the rfm69pi.

Another quick test from emonhub could be to set 868MHz in emonhub.conf since your rfm69pi is tuned for 433 it will almost certainly not receive anything unless it is really close and ~868Mhz. That should help determine if it's from the serial port or air-bourne noise perhaps.

Paul

The help text is corrupted as well.I removed the rfm69pi and there was no data.

I tried setting to 868 mhz and I was still getting corrupt data. Went back to 433mhz and turned off the emontxshield and the corrupt data was still there.

I'm not sure how to reinstall the firmware.

Don

Do you recall the firmware version from when the help text printed?

The rfm69pi wiki has a guide on how to install firmware, I think most of the software is in place on the sdcard image you have although the "reset" interval duration will need to be edited if you are using avrdude v6.1, I'm sorry I don't recall if it is 5.11 or 6.1 on that image.

You should be able to update the reset script by just doing a git pull from the avrdude-rpi folder or you could just edit the /usr/bin/autoreset file directly,

The hex file to upload would probably be https://github.com/openenergymonitor/RFM2Pi/blob/master/firmware/RFM69CW_RF_Demo_ATmega328/V13_RFM69CW_RF12_Demo_ATmega328.cpp.hex

There is also update routines on the "emompi" image and also one in the rfm69pi repo I'm not sure the included one does the rfm69pi or not and the repo one uploads an earlier compile of the firmware (but could be easily edited)

Sorry the instructions are a bit crazy but I'm not 100% sure what bits you have exactly but I am 100% sure bits will have changed since and the wiki guide includes installing stuff you have already.

Paul

I tried to update the firmware but got the following error

pi@emonpi ~/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328 $ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RFM69CW_RF12_Demo_ATmega328.cpp.hex
avrdude-original: Version 5.11.1, compiled on May 23 2012 at 11:08:25
                  Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
                  Copyright (c) 2007-2009 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
avrdude-original: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x88
avrdude-original: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x88
                  Hardware Version: 1995538432
                  Firmware Version: 344576.4
avrdude-original: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
                  Vtarget         : 0.3 V
                  Varef           : 0.3 V
                  Oscillator      : 0.334 Hz
                  SCK period      : 142.2 us
avrdude-original: AVR device initialized and ready to accept instructions
Reading |                                                    | 0% 0.00s
avrdude-original: arduino_read_sig_bytes(): (a) protocol error, expect=0x10, resp=0xfc
avrdude-original: error reading signature data for part "ATMEGA328P", rc=-3
avrdude-original: error reading signature data, rc=-1
pi@emonpi ~/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328 $
 

I don't think this system is user friendly at all.

Don

Was emonhub stopped for the attempted firmware upload?

If there was no communication the error output would be quite different, it seems avrdude is able to speak to the rfm69pi's AVR but the responces arn't as expected, that maybe coincidence but it very much looks like something is still upsetting or interfering with the serial port.

Can you confirm you have no other hardware, wires or devices attached to the Pi's gpio and that you are using a "stock" shop bought SDcard and have not altered anything?

Can you get an ethernet cable to the Pi so the wifi dongle can be removed?

Did you purchase the power supply from the OEM shop? or do you know for sure it is stable/big enough?

Unfortunately yes, the system is a bit of a handful when things aren't going as intended. 

Paul

I think you need to stop emon hub before updating since it's using serial port:

sudo service emonhub stop 

Updating RFM69Pi firmware should not be required. Firmware has not changed for a long time. It's very strange you getting corrupted serial data, could be hardware issue. Does the unit visible look OK and properly seated ont he the Pi?  If you are still having issue drop an email to support@openenergymonitor.zendesk.com and we'll sort out a replacement. 

Hi,
I did stop emonhub service before doing the upgrade. It all looks good mounted ok etc. I will send an email.

Don