EmonTx v2 unreliable data transmission

markb · 25 November 2018 22:17

Hello all,

I have a Raspberry Pi with RFM2B module running Emoncms, along with an EmonTx v2 and EmonTH v2.

The EmonTH transmits data reliably and is all visible in Emoncms, with an RSSI of about -60.

The EmonTx does not transmit reliably, here is a snap shot from today:

The RSSI is around -25/30. When a transmission fails I see this in the logs:
Discarding RX frame 'unreliable content'? 10 250 1 0 0 0 0 34 164 (-29)

Here is the output from Emonhub:

2018-11-25 22:16:27,991 DEBUG    RFM2Pi     35448      RSSI : -26
2018-11-25 22:16:27,994 DEBUG    RFM2Pi     35448 Sent to channel(start)' : ToEmonCMS
2018-11-25 22:16:27,997 DEBUG    RFM2Pi     35448 Sent to channel(end)' : ToEmonCMS
2018-11-25 22:16:28,130 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 15 125 58 39 251 215 171 236 228 192 185 212 59 233 157 39 190 180 128 126 150 (-85)
2018-11-25 22:16:28,208 DEBUG    MQTT       Publishing: emon/emontx1/power1 444
2018-11-25 22:16:28,214 DEBUG    MQTT       Publishing: emon/emontx1/power2 0
2018-11-25 22:16:28,219 DEBUG    MQTT       Publishing: emon/emontx1/power3 0
2018-11-25 22:16:28,224 DEBUG    MQTT       Publishing: emon/emontx1/power4 3362
2018-11-25 22:16:28,230 INFO     MQTT       Publishing: emon/emontx1/rssi -26
2018-11-25 22:16:28,237 INFO     MQTT       Publishing: emonhub/rx/10/values 444,0,0,3362
2018-11-25 22:16:28,243 INFO     MQTT       Publishing: emonhub/rx/10/rssi -26
2018-11-25 22:16:31,788 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 15 222 14 227 29 101 168 204 96 243 245 103 35 83 63 212 120 125 130 230 42 (-84)
2018-11-25 22:16:33,325 DEBUG    RFM2Pi     35449 NEW FRAME : OK 10 190 1 0 0 0 0 34 13 (-28)
2018-11-25 22:16:33,332 DEBUG    RFM2Pi     35449 Timestamp : 1543184193.32
2018-11-25 22:16:33,334 DEBUG    RFM2Pi     35449 From Node : 10
2018-11-25 22:16:33,336 DEBUG    RFM2Pi     35449    Values : [446, 0, 0, 3362]
2018-11-25 22:16:33,339 DEBUG    RFM2Pi     35449      RSSI : -28
2018-11-25 22:16:33,341 DEBUG    RFM2Pi     35449 Sent to channel(start)' : ToEmonCMS
2018-11-25 22:16:33,343 DEBUG    RFM2Pi     35449 Sent to channel(end)' : ToEmonCMS
2018-11-25 22:16:33,468 DEBUG    MQTT       Publishing: emon/emontx1/power1 446
2018-11-25 22:16:33,475 DEBUG    MQTT       Publishing: emon/emontx1/power2 0
2018-11-25 22:16:33,480 DEBUG    MQTT       Publishing: emon/emontx1/power3 0
2018-11-25 22:16:33,486 DEBUG    MQTT       Publishing: emon/emontx1/power4 3362
2018-11-25 22:16:33,491 INFO     MQTT       Publishing: emon/emontx1/rssi -28
2018-11-25 22:16:33,498 INFO     MQTT       Publishing: emonhub/rx/10/values 446,0,0,3362
2018-11-25 22:16:33,503 INFO     MQTT       Publishing: emonhub/rx/10/rssi -28
2018-11-25 22:16:33,630 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 3 123 127 252 186 215 205 39 253 206 197 177 22 223 107 22 150 15 94 114 127 (-86)
2018-11-25 22:16:37,698 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 11 123 65 177 167 195 62 159 212 152 214 45 30 229 22 15 30 114 175 88 160 (-84)
2018-11-25 22:16:39,942 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 191 1 0 0 0 0 34 96 (-28)
2018-11-25 22:16:40,099 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 165 195 248 135 180 214 142 106 16 92 0 83 196 233 177 154 167 194 211 63 (-85)

Can anyone help with this issue?

Thanks,

Mark

Bill.Thomson · 25 November 2018 22:26

The lines in your log example marked as unreliable content all have an RSSI of approximately -85
which suggests you have a signal strength issue. i.e. signal level is too low. Yet the example I quoted from
your post shows an RSSI of -29, which is higher than necessary, but shouldn’t cause any problems.

What is the distance between the emonTx and RasPi? Are there any obstacles between the two?

Robert.Wall · 25 November 2018 23:09

“Unreliable” I think means that the checksum has failed. It might be a data rate issue where the transmitted data rate has drifted due to the recent low temperatures we’re experiencing?

Bill.Thomson · 25 November 2018 23:12

True enough.

I’ve noticed that -85 is (more or less) right on the edge of where many users start to have issues
related to low RSSI.

Robert.Wall · 25 November 2018 23:23

Looking just now at my V2 running the emonLibCM library test, there’s a period of about 1 day when the RSSI is comfortably in the -90’s, and I can’t see an obvious periods of signal loss.

Bill.Thomson · 25 November 2018 23:28

That’s how it should be, but I’ve seen a few instances where users mentioned intermittant operation
with an RSSI of -85. Possibly a result of other signals on or very near the RFM operating freq, that
get masked when the desired to undesired signal strength ratio is high enough. Then something changes.
e.g. they move either or both ends of the radio link, and the desired to undesired sig strength ratio drops to a
point where the interfering signal causes problems.

markb · 26 November 2018 08:28

Thanks for the prompt replies.

I believe the unreliable content lines at around -85 are nothing to do with my monitoring setup, just some other signal in the area. It’s the shorter lines like the one which I quoted on it’s own at around -28 which appear to be the missed data points. The EmonTx is literally just the other side of a single layer brick wall to my RasPi, and it’s in the conservatory so temperatures shouldn’t be too low.

My EmonTH which is further away in the garage, has a quality of 98%.

Robert.Wall · 26 November 2018 12:15

I wonder whether the signal is too strong, and it is overloading the front end of the receiver?
(For comparison, mine is the width of the garage plus a single brick wall away from the RPi - I lifted the V2 a little higher to be above the car roof, now I’m seeing about -66 dB.

How long has the emonTx V2 been running unreliably?

markb · 26 November 2018 12:25

Interesting thought, I will move the RPi to the other end of the house and see if there is any improvement.

It has never been reliable. It seems within a period of say 24 hours it will go for a number of hours being quite reliable then several where it’s not reliable at all.

Robert.Wall · 26 November 2018 12:33

By delving into the inner workings of JeeLib, it’s possible to control the output power. So if moving the RPi away helps, we can look at lowering the output power of the V2, which will allow the RPi to stay where it was.

[Edit]
In fact, when the old grey matter got going, I remembered that I’ve got a “transmit-only” crib of JeeLib, and when I found it, the command for setting the output power is commented! So if the experiment works, it’s a relatively simple matter of swapping the library for this special one.

Bill.Thomson · 26 November 2018 14:02

According to the RFM69 datasheet, the receiver front end should be able to handle a fairly
strong signal w/o any issues.

Robert.Wall · 26 November 2018 14:18

@Bill.Thomson lf the RPi is displaying the RSSI, surely this infers that it’s a RFM69CW in the receiver? And that has a front end that’s allegedly more sensitive than the RFM12B.

Bill.Thomson · 26 November 2018 14:20

D’Oh!
Yep. Yer right. I was going by this:

and even then, RFM2B should be RFM12B.
But as you mentioned, the 12B doesn’t have RSSI capability.

Post edited to reflect RFM69 vice RFM12.

Robert.Wall · 26 November 2018 14:26

RSSI is available from the RFM12B as a voltage (IIRC, Martin Roberts did a RF signal strength monitor with a GLCD by wiring that to an analogue input) but I don’t think the RFM12Pi did that - though I could well be wrong.

Bill.Thomson · 26 November 2018 14:29

I remember Martin’s adaptation of an emonGLCD now that you mention it.
Pretty slick use for an emonGLCD.

markb · 26 November 2018 20:03

So I’ve moved the RPi and RSSI is now around -65. Unfortunately I am still having the same problem. Here is the graph from today:

(I only moved it about 20 mins ago but there are lots of data points missing).

The emonTx was a self build unit - as far as I’m aware there’s nothing wrong with the soldering etc, but obviously if there’s anything with the hardware that might cause such issues I would be interested to know. Also if there’s any further probing I can do to establish why the checksum is failing…

Mark

Robert.Wall · 26 November 2018 22:11

The possibility of overloading the receiver was a long shot, but worth a try.

Do you mean that you assembled it from the kit, or what? I’ve never heard of this problem before, so I’m struggling to try to figure out exactly what is happening. Are you using an up-to-date JeeLib when you compile the sketch? If you haven’t, that might be a sensible thing to try.

markb · 27 November 2018 09:47

There used to be a kit sold which consisted of the PCB and some of the harder to get components, which is what I used for this (emonTx).

I can’t remember exactly what version of JeeLib I used, I guess the one that was current when I made it (around a year ago I think). I will try reloading the sketch with the latest and see if there is any improvement.

emjay · 3 December 2018 17:25

Looks more like a minor frequency mismatch. If the transmitted envelope is biased to one side of the receiver pass band, this increases the chance of decoding ‘0’ for ‘1’ (or vice versa at the other side of the pass band). Add in a temperature variation which will also move the transmitted envelope a few ppm and you will go from mostly decoding properly to mostly decoding incorrectly. This will be caught by the CRC check - “unreliable…”

For experimentation, tweak the easiest code to get at. The centre frequency is defined in the rf library setup call. Use a delta of say 5khz iteratively - you will soon see if you are heading on the wrong direction.

markb · 3 December 2018 22:06

Thanks for the input. I’ve had a look through some of the Jeelibs libraries and also OEM ones but can’t work out where it is set. There is a function setFrequency in this file on line 124: jeelib/RF69.cpp at master · jeelabs/jeelib · GitHub, not sure if that’s the right thing or indeed where it is used.

If you or anyone else has any ideas please let me know!