Sherlock Holmes: what am I receiving? :-)

bvrslypp · 2017-01-08T15:16:12.067Z

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

pb66 · 2017-01-08T16:51:24.516Z

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.

bvrslypp · 2017-01-10T23:41:06.219Z

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

Bill.Thomson · 2017-01-11T07:34:06.658Z

bvrslypp:

with a couple of ‘peaks’ at -80

-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.”

bvrslypp · 2017-01-11T22:27:01.601Z

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.

Bill.Thomson · 2017-01-12T07:44:55.160Z

bvrslypp:

I think I read somewhere that RFM module takes -80 as cut off value

That’s often referred to as MDS, or Minimum Discernable Signal.
In RF parlance, a “peak” is a maximum signal value.

pb66 · 2017-01-12T18:45:42.886Z

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.

Bill.Thomson · 2017-01-13T02:38:10.000Z

pb66:

or should that be under?

Yes, under, as the number represents signal strength.

To put it in perspective:

0dBm = 1mW (mW = milliWatt)

-80 dBm = 0.01 µW (µW = microWatt)