I live in an urban environment, and I noticed that I pick up a lot of frames marked as “unreliable” by emonHub, but as it appears that there is some pattern in it, I am interested in what it could be…
unreliableFrames basement emonBase.txt (3.2 KB)
unreliableFrames master emonPi.txt (78.2 KB)
Any ideas welcome 
. I hope I did not post secret codes of my neighbours online
Based on the info in your other thread “Node 15 is not forwarded to remote emoncms.org” it looks like there is a lot of emonTx packets being lost or at least reception has failed and possibly retried multiple times.
When put in a spreadsheet it’s easier to pick out patterns, I have attached a spreadsheet with all the suspected “failed emontx” packets marked in purple and there are some other packets marked in red that also have a 184 & 11 at the end which is the 300 error code for an unused or faulty temp sensor.
What rssi’s are you seeing for successfully received packets from each device? (for each receiver if duplicating)
What sketches are you running?
Have you made any alterations eg to the payload or the send intervals?
Almost all the payloads appear the same length, that is because the receiver only prints the first 20 bytes of a failed packet so they are most likely incomplete.
EDIT - Forgot to attach this! (save as bvrslypp.xlsx, I had to add the .txt to upload)
bvrslypp.xlsx.txt (133.6 KB)
I have put both logs in one file, added headings and added 2 columns (marked in grey) 1 to show origin and the other shows the time in secs since the previous packet.
Thanks @pb66, excel makes it easier to look at.
My emonTX is ~40 cm from my master emonPi. The latter receives packets with rssi between -32 and -28 according to the log. I have not made alterations to the emonTX (yet )*.
My emonTH is a about 7 meters from my emonBase (and separated by two wooden doors), and receives emonTH packets at rssi between -75 and -71, with a couple of ‘peaks’ at -80. emonTH has been heavily modified (see other thread), but I kept the RFM code more or less intact. Maybe putting the thing in sleep mode tends to corrupt packets?
Does the emonBase also send packets? Maybe this is an explanation for the packets with 6 times 184 & 11.
*I am planning to set the sampling rate to 1s 
-80 represents the weakest of your three RSSI numbers. IOW, the larger the number, the weaker the signal.
Of the three emonTH values in your post, -71 is the “peak.”
Yes, I know, but I think I read somewhere that RFM module takes -80 as cut off value, discarding frames received with lower rssi? That’s why I mentioned.
That’s often referred to as MDS, or Minimum Discernable Signal.
In RF parlance, a “peak” is a maximum signal value.
Just looking at the bad packets alone make it tricky to draw conclusions, things like the time since last send for a certain device regardless of whether is was successful or not helps in determining the source too.
As does current “good” values to determine a packets source, plus if a payload is being intermittently corrupted it is easier to spot the bad one from the good ones, rather than just a mixed bag of bad ones.
The “sleep” theory is a possibility I guess, we found sometime ago that the emonTH sketches were prone to corruption when the rfm was woken and used to send before it was ready, a well place but small delay cured the issue. This was found by spotting the difference of one bit to one byte midway in a bad packet when comparing to surrounding good packets.
As for the -80dB threshold, I seem to recall this was a set threshold but cannot find any documentation to that effect, but regardless of whether it is coded or a natural effect, I do not recall seeing many, if any reports of successful packets over (or should that be under?) -80dB and yet we do see ample ( but far from all) packets fail at RSSI’s close to that so it would seem to be well placed if coded.
Yes, under, as the number represents signal strength.
To put it in perspective:
0dBm = 1mW (mW = milliWatt)
-80 dBm = 0.01 µW (µW = microWatt)