EMonTX Bad data after upgrade

borpin · 27 October 2020 17:05

NA7KR:

2020-10-27 09:51:20,402 DEBUG    RFM2Pi     34731 NEW FRAME : OK 15 69 66 85 85 142 126 85 85 85 85 95 85 85 85 85 85 85 85 173 170 170 170 241 85 85 85 182 170 170 170 101 32 101 32 101 32 85 85 85 85 (-68)

This EmonTX is still transmitting by RFM as well as by serial - that is why you are getting it twice. Note the 15 after the OK.

[edit]

Easily solved.

NA7KR · 27 October 2020 20:21

Do not then power the EmonTX directly with DC as well
It says DO NOT POWER for USB, if DC is not connected readings are all off as on as usb does not have the power to run them.

What do you want to comment out?

     ``` # emonhub/rx/10/values format
    # Use with emoncms Nodes module
    node_format_enable = 1
    node_format_basetopic = emonhub/

    # emon/emontx/power1 format - use with Emoncms MQTT input
    # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
    nodevar_format_enable = 1
    nodevar_format_basetopic = emon/```

Easily solved.
How?

Robert.Wall · 27 October 2020 21:56

What Brian is saying here is, despite your belief and assertion to the contrary, Node 15 is transmitting the data both serially and via the radio.

The solution is easy, turn off the transmitter. There are two ways to do that. If you connect the errant emonTx and its programmer directly to your computer, and you have the Arduino IDE on it, when you power the emonTx with the IDE’s Serial Monitor active, you’ll see an invitation to enter the access code +++, and having done that, a list of configuration commands. Type w0[enter], then s[enter] to save the command in EEPROM. You can then restore the emonTx to its place, and Node 15 should be gone.

The second way is to edit the sketch and hard-code that change, then recompile and reload the sketch.

That’s puzzling. Normally, the emonTx can get its power via the USB lead and programmer (the programmer from our Shop will do that - a third party one might not). But another user today has reported a USB lead with a failed Pin 1 (the +5 V) connection - did you get yours from our shop too?

The current required by the emonTx is not that great, at 5 V it is about 8 - 10 mA when not transmitting (which is how you have it). Your 2 A supply should not even notice three of those.

The full explanation is:
The emonTx is designed to take its power from the a.c. adapter in normal use with the radio, via the jumper link JP2 on the p.c.b. It can also take a 5 V d.c. feed from the USB socket, the battery holder (when requested), the programmer FTDI connector, the RJ45 connector (though this is normally an output to the pulse sensor) and the screw terminal strip. All these places are wired in parallel. Therefore, it’s not a good idea to (a) have the jumper in place and use the 5 V d.c., nor (b) to have multiple 5 V supplies, because one might back-feed the other(s).

I think Brian meant the two lines that follow the comment “Use with emoncms Nodes module”.

NA7KR · 28 October 2020 03:18

Thanks, both for help node 15 now removed.
Yes the Serial/USB was purchased at the same time

What is the best way to update the emonpi as web version and if run avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex

also does not work the same error.

avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x70
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0```

Robert.Wall · 28 October 2020 12:03

I’m not sure what you mean there: the version of emonCMS on www.emoncms.org is different to the version you have on your emonPi, so you must expect slightly different features and behaviour from it. In general, your emonPi version has more features, the multi-user version at emoncms.org generally lags behind the emonPi version.

Did you do sudo service emonhub stop before you sent that command?

If you did, I can’t offer an explanation as to why it doesn’t work. It works for me as-is on two emonPi’s, and if I change the baud rate to 38400, it works for an old emonBase with an old RFM2Pi add-on board.

N.B. you must do sudo service emonhub start afterwards.

NA7KR · 28 October 2020 16:42

Was say I can not update for in software admin link.

Yes stopped

pi@emonpi:~ $ sudo service emonhub stop
pi@emonpi:~ $ avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x70
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0

avrdude done.  Thank you.

borpin · 28 October 2020 17:13

@TrystanLea - Any ideas why this is failing?

borpin · 28 October 2020 17:18

If you just click on this, what is the resulting output? Exactly the same?

Please post all of the debug output.

NA7KR · 28 October 2020 18:20

Starting update via service-runner-update.sh (v3.0) ><br />
- emonSD version: emonSD-02Oct19<br />
- supported images: emonSD-24Jul20 emonSD-02Oct19 emonSD-17Oct19<br />
- emonSD base image check passed...continue update<br />
git pull /opt/openenergymonitor/EmonScripts<br />
  master<br />
* stable<br />
On branch stable<br />
Your branch is up to date with 'origin/stable'.<br />
<br />
nothing to commit, working tree clean<br />
Already up to date.<br />
-------------------------------------------------------------<br />
Main Update Script<br />
-------------------------------------------------------------<br />
Date: Wed 28 Oct 2020 11:18:43 AM PDT<br />
EUID: 1000<br />
openenergymonitor_dir: /opt/openenergymonitor<br />
type: firmware<br />
firmware: emonpi<br />
Reading package lists...<br />
Building dependency tree...<br />
Reading state information...<br />
python3-pip is already the newest version (18.1-5+rpt1).<br />
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.<br />
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple<br />
Requirement already satisfied: redis in /usr/local/lib/python3.7/dist-packages (3.5.3)<br />
Hardware detected: EmonPi<br />
Stopping emonPiLCD service<br />
Display update message on LCD<br />
-------------------------------------------------------------<br />
EmonPi Firmware Update (Discrete Sampling)<br />
-------------------------------------------------------------<br />
Start ATmega328 serial upload using avrdude with latest.hex<br />
Attempt: 1<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
Attempt: 2<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
Attempt: 3<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
<br />
waiting for emonpi to stop controlling LCD<br />
<br />
Starting emonPi LCD service..<br />
<br />
<br />
-------------------------------------------------------------<br />
emonPi update done: Wed 28 Oct 2020 11:19:09 AM PDT<br />
-------------------------------------------------------------</details><br />

borpin · 29 October 2020 08:00

TL;DR The utility avrdude-rpi still uses python which may be the issue @bwduncan @TrystanLea. @Martin_Harizanov - I note OEM fork is from you. Went back to the original repo and is still python as well.

In detail…

NA7KR:

Start ATmega328 serial upload using avrdude with latest.hex
Attempt: 1
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex
Note: progress written to logfile /var/log/emoncms/firmware.log

ERROR: Not in sync

Interesting.

Start ATmega328 serial upload using avrdude with latest.hex
chmod: cannot access '/var/log/emoncms/firmware.log': No such file or directory
Attempt: 1
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex
Note: progress written to logfile /var/log/emoncms/firmware.log

avrdude-original: Using autoreset DTR on GPIO Pin 7
strace: |autoreset: Broken pipe

ERROR: Not in sync

In your fiddling, have you changed the avrdude setup?

You are missing this message in the log.

avrdude-original: Using autoreset DTR on GPIO Pin 7

There is an extra script inserted to make the reset pin work on an RPi.

Check the links…

pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $ which avrdude
/usr/bin/avrdude
pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $ ls -la /usr/bin/avr*
lrwxrwxrwx 1 root root     52 Oct 17  2019 /usr/bin/avrdude -> /opt/openenergymonitor/avrdude-rpi/avrdude-autoreset
-rwxr-xr-x 1 root root 383576 Apr 12  2019 /usr/bin/avrdude-original
pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $

In simple terms

calling avrdude
calls dvrdude-autoreset
calls /opt/openenergymonitor/avrdude-rpi/autoreset (the script the generates the message above)
calls /usr/bin/avrdude-original

At this point I realised that autoreset is using Python and not Python3 which may be the issue.

bwduncan · 29 October 2020 17:41

ISTR porting this to Python 3 but maybe I never tested and pushed it. I’ll have a look.

bwduncan · 29 October 2020 17:55

Yes, I did. It’s a pull request on github. If someone could test it I would really appreciate it.

github.com/openenergymonitor/avrdude-rpi

Python3

openenergymonitor:master ← bwduncan:python3

opened 04:20PM - 17 Aug 20 UTC

bwduncan

+37 -52

This is a port and a rewrite. It's much simpler than the tentacles this code has… grown over the years leads one to believe! I hope this simplification is still sufficient. Specifically, I removed all the nonblocking complexity. One change that this introduces is that the code will now toggle the reset any time the DTR ioctl is called, not just the first time. I don't know if this is a bug fix or an incompatible behaviour change. Testing needed. The code still has a 5000s timeout, but it uses an alarm signal now instead of checking thousands of times a second. I don't know why this timeout is needed, but I left it in anyway. Also the code disables the GPIO warnings. This seems like a bad idea to me that is hiding some bug, but I also left that in.

NA7KR · 29 October 2020 18:25

Looks to be working now.
remamed avrdude to avrdude-origin and put a sybolic link /usr/bin/avrdude → /opt/openenergymonitor/avrdude-rpi/avrdude-autoreset

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/emonpi/firmware/compiled/latest.hex"
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex
avrdude-original: writing flash (18526 bytes):

Writing | ################################################## | 100% 2.58s

avrdude-original: 18526 bytes of flash written
avrdude-original: verifying flash memory against /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex:
avrdude-original: load data flash data from input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex:
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex contains 18526 bytes
avrdude-original: reading on-chip flash data:

Reading | ################################################## | 100% 1.94s

avrdude-original: verifying ...
avrdude-original: 18526 bytes of flash verified

avrdude-original done. Thank you.

SUCCESS: flash verifed

waiting for emonpi to stop controlling LCD

Starting emonPi LCD service..

-------------------------------------------------------------
emonPi update done: Thu 29 Oct 2020 11:19:45 AM PDT
-------------------------------------------------------------

Thanks all for you help

borpin · 29 October 2020 20:10

I was sure I’d checked. Looks like I’d clicked through to the original repo before checking the PRs - apologies. Many thanks.