# Unable to get new emonTx working with existing emonPi **URL:** \ **Category:** Hardware\ **Created:** [18 November 2017 16:43 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686 "2017-11-18T16:43:01Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [20 November 2017 20:35 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/21 "2017-11-20T20:35:47Z")
Just looking at the log line 26 2017-11-20 21:24:21,788 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz q0 USA 0 is USA correct ?? ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [20 November 2017 20:38 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/22 "2017-11-20T20:38:27Z")
at line 329: 2017-11-20 21:25:15,764 DEBUG RFM2Pi 15 Timestamp : 1511209515.76 2017-11-20 21:25:15,765 DEBUG RFM2Pi 15 From Node : 7 2017-11-20 21:25:15,765 DEBUG RFM2Pi 15 Values : [1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 2017-11-20 21:25:15,766 DEBUG RFM2Pi 15 RSSI : -59 node 7 ??? ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [21 November 2017 23:43 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/23 "2017-11-21T23:43:09Z")
Any clue? ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [22 November 2017 00:10 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/24 "2017-11-22T00:10:12Z")
Node 7 is correct. The DIP switch subtracts 1 from the NodeID. It was Node 8, it is now Node 7. USA = 0 is correct. You are in Italy and the DIP switch should be “OFF”. I’m sorry but I don’t know enough about emonHub to help you any more. @pb66 is the best person to help, but he is a busy man. [Edit] There is something very peculiar happening. At line 271 `2017-11-20 21:25:14,802 DEBUG RFM2Pi 11 NEW FRAME : OK 7 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-62)` There I see the data I expect: 4 x power, 1 x voltage, 6 x temperature, 1 x pulse. This appears to be the first of the factory test transmissions from Node 7. It counts down from 10, but is sent so rapidly that many messages are missed. But the next at line 278 `2017-11-20 21:25:14,917 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 7 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-61)` is cut short as it has only 20 bytes of payload, not 26. After this, the messages appear to be cut short with only 5 temperatures and no pulse count sent. But what I don’t understand is this appears to be fairly consistent - 5 temperatures only instead of 6, and no pulse count. `2017-11-20 21:28:39,825 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 7 189 255 0 0 0 0 0 0 16 96 184 11 184 11 184 11 184 11 184 11 (-57)` `7 ` — Node ` 189 255` — Power 1 = -67 ` 0 0 0 0 0 0` — Powers 2-4 ` 16 96` — Voltage = 24496 ` 184 11 184 11 184 11 184 11 184 11` — 5 x temperature = 3000 ` (-57)` RSSI And this behaviour repeats - each time you reset, the factory test is sent normally, then it changes to “short” payloads, almost every time the same 5 temperatures, no pulse count. Have you recompiled and reloaded the emonTx sketch, or is it as it came to you from the shop? At the moment, I cannot explain this. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [22 November 2017 10:11 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/25 "2017-11-22T10:11:07Z")
> [@Nicola\_Reina](#): > > Any clue? In short, not really! Yesterday I saw your post/data and nedded some time to ponder on it some more, the day ran away from me and I didn’t get back to it. ditto much of what @Robert.Wall has said. Your initial ref to node 9 threw me too, Can I assume that comment was based on your assumption the new node id would be 9 not 7 and that you haven’t actually seen a node 9? Node 8 does become node 7 when the dip sw is switched, as odd as that might seem. > [@Nicola\_Reina](#): > > 2017-11-20 21:24:21,788 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz q0 USA 0 This is actually from the emonPi (node 5), it includes the group and frequency for the receiver which obviously would effect using the emonTx, but the USA bit is only relative to the Vrms of the emonPi, but yes all appears ok. Determining the factory test being the source of the “good” packets with all zero’s is a big help, it is now clear why we were getting what I would call “weird” results in that we could see the packet wasn’t right (no voltage or temps) and yet they passed CRC. We can see the factory test countdown from 10 to 0 in lines 271 though 335 line 271 is 10 and passes CRC line 278 is 8 and fails CRC line 300 is 5 pass line 307 is 3 pass line 328 is 1 pass line 335 is 0 pass Then 20s later at line 468 we see the first “real” packet and that is discarded and again 10s later at line 509, the discarded packets are seen pretty regularly until the next factory test around line 1028. So now we know why the zero’s are occurring that just leaves us with why the emonTx packets are failing CRC more often that not, (whilst they seem to pass CRC at the factory test at start up) the fail at line 278 can be ignored, I think to receive as many good packets as it did when they are made up of all zero values and in such quick succession, only one fail is good going. The make up of the discarded packets looks ok except they are terminated at 20 values, this is normal for discarded packets as they could be of an enormous size if bourne from some unrelated device, displaying only the first 20 values was always big enough but the payload size has out grown that threshold now. > [@Robert.Wall](#): > > At the moment, I cannot explain this. Nor I… I was led astray by the test payloads, I do not use the stock FW on emonTx’s so I have never seen this behaviour, I do not recall any reports of this type before. I think this was a red herring and we now have a straightforward case of packets with good rssi being discarded. @Nicola_Reina has your usb programmer turned up yet? Do you have access to the command-line in the emonPi? I think we need to attempt a manual FW update just to see if it is up to date, the update.log is inconclusive and the facility for a rfm2pi to pass it’s fw data out to emonhub has been removed in the emonpi varaint because it didn’t get implemented in emonPi. ```auto 2017-11-20 21:24:16,498 INFO MainThread RFM2Pi device firmware version & configuration: not available ``` ideally this needs reimplementing. But in the meantime we can check the emonPi FW repo version and check it actually successfully uploads it to the emonPi. From the command line ```auto cd emonpi git status ``` the reply should include ```auto On branch master Your branch is up-to-date with 'origin/master'. ``` Then if it does say that, try ```auto sudo service emonhub stop avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex sudo service emonhub start ``` post the output here, it should upload and verify the FW, it will take several seconds to complete. As a sidenote, IMO the factory test needs changing! Sending so many zero’s is asking for trouble, literally, we know about bitslip issues already, plus if a emontx is reset in service there are 11 chances of a all zero payload getting through and zeroing the users feeds, thus far I think this has been hidden by the fact a emonPi/emonBase takes longer to come on line than an emonTx, Perhaps it should “factory test” to a different node id or at least be made of a different number of values so that it gets rejected by emonhub. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [22 November 2017 10:34 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/26 "2017-11-22T10:34:12Z")
@glyn.hudson > [@pb66](#): > > As a sidenote, IMO the factory test needs changing! I concur. I minor change to the firmware (pass the address of the data packet to send\_rf\_data( ), instead of hard-coding it (as I did with the 3-phase sketch), would mean a totally different payload structure could be used - sending just one byte even - that emonhub would reject immediately. That’s even easier and probably more flexible than changing the NodeID, because that’s “hard-coded” once JeeLib is initialised (though again there’s no good reason for that, except it’s one less parameter to pass with each transmission). ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [22 November 2017 10:59 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/27 "2017-11-22T10:59:09Z")
> [@Robert.Wall](#): > > sending just one byte even At least if that did slip through and make it to emoncms, that’s only one contaminated input rather than 13. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [22 November 2017 16:59 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/28 "2017-11-22T16:59:52Z")
Is there a real danger that emonHub would fail to reject a one-byte payload when it was expecting 20 - 30 bytes? I’d have hoped not. It’s not even necessary to change `send_rf_data( )` because having looked at the test code – it doesn’t use it. So only a simple change to the test loop: ```auto for (byte i=10; i<255; i--) // Send RF test sequence (for factory testing) { rf12_sendNow(0, &i, sizeof(i)); delay(100); } ``` You don’t even need to reset ` emontx.power1=0;` afterwards, because it’s no longer been used for the test. Unless @gwil knows better, I can’t see that sending one byte rather than 26 invalidates the test in any way – it proves the rf module is transmitting, and it sends some numbers (except they’re bytes, not signed integers). [🙄 I’d forgotten that error packets are truncated in the log. Would it be too hard to have an ellipsis printed at the point where the cut-off is to remind dumb-clucks like me that this has happened?] ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 17:15 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/29 "2017-11-22T17:15:14Z")
Hi Programmer has landed…so tonight I will be able to check emontx fw. Sorry for this short answer from the phone. I will do the rest suggested and post results. Thanks again for the support . @glyn.hudson we still have a chance to save the return 🙂 ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [22 November 2017 17:34 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/30 "2017-11-22T17:34:42Z")
> [@Robert.Wall](#): > > Is there a real danger that emonHub would fail to reject a one-byte payload when it was expecting 20 - 30 bytes? I’d have hoped not. As would I, but A) I have no idea off-hand if the emonpi variant still rejects packets if the config is wrong, I know it no longer matters if the scales don’t align, it is apparently better to get data that is scaled incorrectly than blocking delivery to prompt correction. and B) users may not be using emonhub. > [@Robert.Wall](#): > > Would it be too hard to have an ellipsis printed at the point where the cut-off is I see no reason why not, for the emonpi it just needs adding here > Something like ```auto if (quiet_mode == 0) { //if the packet is bad Serial.print(F(" ?")); //Print the "bad packet" line prefix print_frame(20); //Print only the first 20 bytes of a bad packet if (rf12_len > 20) Serial.print(F("...")) // Print ellipsis if data omitted } ``` But this file doesn’t get used directly, it needs recompliling so the .hex is updated too likewise for the rfm2pi (regards the hex) but the file is different > as printing is deferred untill > so it would need something like ```auto for (byte i = 0; i < n; ++i) { if (!config.hex_output) printOneChar(' '); showByte(rf12_data[i]); if (rf12_crc) && (!config.quiet_mode) && (rf12_len > 20) showString(PSTR("...")); } ``` (untested) so the ellipsis get printed if crc failed, quiet mode is off and the length was originally over 20 (the “n” variable is over written so we can’t use that). ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [22 November 2017 17:35 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/31 "2017-11-22T17:35:42Z")
> [@Nicola\_Reina](#): > > Programmer has landed…so tonight I will be able to check emontx fw. > > Sorry for this short answer from the phone. > > I will do the rest suggested and post results. Ok! (also a short answer 🙂 ) ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 21:47 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/32 "2017-11-22T21:47:57Z")
So I finally have time to put my hands on. I do the following then: But in the meantime we can check the emonPi FW repo version and check it actually successfully uploads it to the emonPi. From the command line cd emonpi git status the reply should include On branch master Your branch is up-to-date with ‘origin/master’. Then if it does say that, try sudo service emonhub stop avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex sudo service emonhub start post the output here, it should upload and verify the FW, it will take several seconds to complete. ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 21:52 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/33 "2017-11-22T21:52:22Z")
> [@Robert.Wall](#): > > Have you recompiled and reloaded the emonTx sketch, or is it as it came to you from the shop? No. as it is from the shop ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 21:57 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/34 "2017-11-22T21:57:11Z")
Here you go 🙂 ```auto pi@emonpi(ro):emonpi$ clear pi@emonpi(ro):emonpi$ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) 1 hardware/emonpi/emonpi2c/ nothing added to commit but untracked files present (use "git add" to track) pi@emonpi(ro):emonpi$ sudo service emonhub stop pi@emonpi(ro):emonpi$ avrdude Usage: avrdude-original [options] Options: -p Required. Specify AVR device. -b Override RS-232 baud rate. -B Specify JTAG/STK500v2 bit clock period (us). -C Specify location of configuration file. -c Specify programmer type. -D Disable auto erase for flash memory -i ISP Clock Delay [in microseconds] -P Specify connection port. -F Override invalid signature check. -e Perform a chip erase. -O Perform RC oscillator calibration (see AVR053). -U :r|w|v:[:format] Memory operation specification. Multiple -U options are allowed, each request is performed in the order specified. -n Do not write anything to the device. -V Do not verify. -u Disable safemode, default when running from a script. -s Silent safemode operation, will not ask you if fuses should be changed back. -t Enter terminal mode. -E [,] List programmer exit specifications. -x Pass to programmer. -y Count # erase cycles in EEPROM. -Y Initialize erase cycle # in EEPROM. -v Verbose output. -v -v for more. -q Quell progress output. -q -q for less. -l logfile Use logfile rather than stderr for diagnostics. -? Display this usage. avrdude version 6.1, URL: ^CTraceback (most recent call last): File "/usr/bin/autoreset", line 42, in process() File "/usr/bin/autoreset", line 30, in process if dtr.match(input): KeyboardInterrupt pi@emonpi(ro):emonpi$ avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex avrdude-original: Using autoreset DTR on GPIO Pin 7 avrdude-original: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude-original: Device signature = 0x1e950f 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 "/home/pi/emonpi/firmware/compiled/latest.hex" avrdude-original: input file /home/pi/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex avrdude-original: writing flash (17898 bytes): Writing | ################################################## | 100% 2.54s avrdude-original: 17898 bytes of flash written avrdude-original: verifying flash memory against /home/pi/emonpi/firmware/compiled/latest.hex: avrdude-original: load data flash data from input file /home/pi/emonpi/firmware/compiled/latest.hex: avrdude-original: input file /home/pi/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex avrdude-original: input file /home/pi/emonpi/firmware/compiled/latest.hex contains 17898 bytes avrdude-original: reading on-chip flash data: Reading | ################################################## | 100% 1.96s avrdude-original: verifying ... avrdude-original: 17898 bytes of flash verified 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):emonpi$ ``` ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 22:09 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/36 "2017-11-22T22:09:03Z")
So the manual update of emonpi has been done. At first it seemed to have stopped sending data but then it started again… pheew… What shall I do with the emontx… reflash with the latest fw? TX ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [22 November 2017 22:14 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/37 "2017-11-22T22:14:18Z")
I cannot think of a good reason why that will solve the problem, but as both Paul and I cannot think of a good explanation, I think you should upload the latest sketch. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [22 November 2017 22:19 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/38 "2017-11-22T22:19:15Z")
The emonpi will definitely be using the latest FW now, there is nothing there to suggest it wasn’t already, but now we know for sure. I would be interested to know what firmware is installed before you update it though. It is printed to serial at start up. Plus rolling out too many changes in one hit will not tell us where the issue lays and make it harder to understand why, if a fix works, it did so. Therefore can you please check there is no change in activity since updating the emonPi before touching the emonTx. Perhaps do another reset and post the emonhub.log so we can see if the characteristics are the same. ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 22:35 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/39 "2017-11-22T22:35:37Z")
[emonhub.zip](https://community.openenergymonitor.org/uploads/default/original/2X/3/3c38a0870bfa2136ab4882e2e3e48d2c88ced849.zip) (10.4 KB) Here it is. reboot at 23:clock1030: emontx not connected ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 22:43 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/40 "2017-11-22T22:43:51Z")
Here at 23:40 I connect the emonhub. Same behaviour. at 23:41 I hit the reset button. Again. Just 1 sample then nothing [emonhub\_tx.zip](https://community.openenergymonitor.org/uploads/default/original/2X/b/ba113ec96c7dcec4904d29fe1c2c13a6c241ae02.zip) (29.4 KB) ---
**Author:** ![Nicola\_Reina](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/nicola_reina/32/5119_2.png) [@Nicola\_Reina](https://community.openenergymonitor.org/u/Nicola_Reina)\ **Post date:** [22 November 2017 22:44 UTC](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686/41 "2017-11-22T22:44:33Z")
Is there a safe win7 utility I can use to flash the emontx? TX [Previous page](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686.md?page=1) [Next page](https://community.openenergymonitor.org/t/unable-to-get-new-emontx-working-with-existing-emonpi/5686.md?page=3)