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.
