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 ??
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 ???
Any clue?
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.
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.
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.
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.
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
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.
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.
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).
At least if that did slip through and make it to emoncms, thatâs only one contaminated input rather than 13.
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:
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?]
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 
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.
I see no reason why not, for the emonpi it just needs adding here
Something like
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
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).
1 Like
Ok! (also a short answer 
)
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.
No. as it is from the shop
Here you go
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 <file>..." 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 <partno> Required. Specify AVR device.
-b <baudrate> Override RS-232 baud rate.
-B <bitclock> Specify JTAG/STK500v2 bit clock period (us).
-C <config-file> Specify location of configuration file.
-c <programmer> Specify programmer type.
-D Disable auto erase for flash memory
-i <delay> ISP Clock Delay [in microseconds]
-P <port> Specify connection port.
-F Override invalid signature check.
-e Perform a chip erase.
-O Perform RC oscillator calibration (see AVR053).
-U <memtype>:r|w|v:<filename>[: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 <exitspec>[,<exitspec>] List programmer exit specifications.
-x <extended_param> Pass <extended_param> to programmer.
-y Count # erase cycles in EEPROM.
-Y <number> 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: <http://savannah.nongnu.org/projects/avrdude/>
^CTraceback (most recent call last):
File "/usr/bin/autoreset", line 42, in <module>
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$
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
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.
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.
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 (29.4 KB)
Is there a safe win7 utility I can use to flash the emontx?
TX