Archived Forum

Oh, here is the node configuration:

[[10]]
    nodename = Sovrum
    firmware = ""
    hardware = "emonTX V2"
    [[[rx]]]
        names = W, p, T1
        datacode = h
        scales = 1,1,0.01
        units = W,p,C

Privous one when i only ran temperature (worked good):

#[[10]]
#    nodename = Sovrum
#    firmware = ""
#    hardware = "emonTX V2"
#    [[[rx]]]
#        name = T1
#        datacode = h
#        scale = 0.01
#        unit = C

@Bjotksta,

The Discarding RX frame 'unreliable content' is because those packets are failing the CRC check, shown by the '?'.

If you could capture some more (with good packets in between), the bit position that is first failing will become clearer. The earliest part of the packet is ok since the node ID / length fields are correct - a glitch is occurring later on (seemingly quite early if that '52' is typical).

The signal strength is fine - this is more likely a timing issue.  Your version of EmonTX V2 is using an RFM12B radio module?

Thanks for the input!

Perhaps this is an error in the code of the emonTX, i should have a look at that.

The emonTX also has a RFM69 module.

Got some more frames:

How do you decode the data? 

2015-12-18 09:45:02,295 DEBUG    RFM2Pi     666 NEW FRAME : OK 10 16 2 2 0 189 6 (-61)
2015-12-18 09:45:12,101 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 21 2 2 0 189 6 (-47)
2015-12-18 09:45:22,396 DEBUG    RFM2Pi     667 NEW FRAME : OK 10 15 2 1 0 189 6 (-51)
2015-12-18 09:45:32,534 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 16 2 2 0 189 6 (-45)
2015-12-18 09:46:03,226 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 17 2 1 0 189 6 (-49)
2015-12-18 09:46:13,416 DEBUG    RFM2Pi     670 NEW FRAME : OK 10 20 2 2 0 189 6 (-46)
2015-12-18 09:46:23,647 DEBUG    RFM2Pi     671 NEW FRAME : OK 10 10 2 1 0 189 6 (-45)
2015-12-18 09:46:33,818 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 20 2 2 0 189 6 (-47)
2015-12-18 09:46:44,107 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 11 2 1 0 189 6 (-47)
2015-12-18 09:46:54,258 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 209 1 1 0 189 6 (-50)
2015-12-18 09:47:04,532 DEBUG    RFM2Pi     672 NEW FRAME : OK 10 208 1 2 0 189 6 (-45)
2015-12-18 09:47:14,710 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 189 1 1 0 189 6 (-45)
2015-12-18 09:47:25,013 DEBUG    RFM2Pi     673 NEW FRAME : OK 10 194 1 1 0 189 6 (-45)
2015-12-18 09:47:35,159 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 201 1 2 0 189 6 (-48)
2015-12-18 09:47:45,373 DEBUG    RFM2Pi     674 NEW FRAME : OK 10 217 1 1 0 189 6 (-46)

2015-12-18 09:50:49,257 DEBUG    RFM2Pi     682 NEW FRAME : OK 10 206 1 1 0 189 6 (-46)
2015-12-18 09:50:59,394 DEBUG    RFM2Pi     683 NEW FRAME : OK 10 202 1 2 0 189 6 (-46)
2015-12-18 09:51:09,650 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 216 1 1 0 189 6 (-45)
2015-12-18 09:51:19,836 DEBUG    RFM2Pi     684 NEW FRAME : OK 10 202 1 1 0 182 6 (-47)
2015-12-18 09:51:30,036 DEBUG    RFM2Pi     685 NEW FRAME : OK 10 200 1 2 0 189 6 (-45)
2015-12-18 09:51:40,305 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 198 1 1 0 182 6 (-46)
2015-12-18 09:51:50,464 DEBUG    RFM2Pi     686 NEW FRAME : OK 10 206 1 1 0 189 6 (-46)
2015-12-18 09:52:00,695 DEBUG    RFM2Pi     687 NEW FRAME : OK 10 216 1 1 0 182 6 (-45)
2015-12-18 09:52:10,884 DEBUG    RFM2Pi     688 NEW FRAME : OK 10 212 1 2 0 189 6 (-48)
2015-12-18 09:52:21,186 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 66 1 (-45)
2015-12-18 09:52:31,404 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 206 1 1 0 182 6 (-45)
2015-12-18 09:52:41,641 DEBUG    RFM2Pi     689 NEW FRAME : OK 10 202 1 2 0 189 6 (-45)

I can check and post the transmitter code after the weekend, but basically its a mix of the examples available on the site; emonTx_Pulse and emontx_temperature_power.

I agree a larger dataset is needed to make possible to recognize a pattern.

Is the emonTx v2 battery or AC powered?

How are the pulses being collected?

Is the RFM being put to sleep between sends?

Is the temp sensor just a regular ds18b20 ?

Can we see the sketch?

Since the packet and the crc do not match, the probability is one or the other is changed after it's set. The obvious (but IMO unlikely in this instance) is RF interference or poor signal etc. I don't think there are enough bits to suspect a "drift" especially if the issue is early in the packet. 

The chances are something is happening to the packet after crc is set but before transmission in the sketch following the edit to add pulse counting. whether it's the pulse counting itself or just a consequence of the change I wouldn't like to say. My feeling is it's a misbehaving interrupt routine altering or the rfm not being ready to use (see emonTH Unreliable reading timing?) or another similar timing issue.

Paul

@Bjotksta,

You could certainly drop the Tx power setting, even to minimum - there is plenty of signal there.  Good for battery life if you are using and will eliminate one possible cause of packet corruption due to voltage sag

Thanks for the inputs!

The node is powered via 5V USB. 

The pulses are collected with a TSL257 in a home-built enclosure. 

The temp sensor is a regular DS18B20.

Yes, the sketch is built up by the examples on github, which puts the RFM to sleep and wakes it up just before transmission without delay.

I also thought the interrupt routine may change the values between the CRC being calculated and transmission, so i modified it a bit after posting this thread, but there was no significant change. I even tried to send constant values, but without success.

Then I added a 120ms delay between wake-up of the RFM and the transmission (which seemed to be the cause in the thread regarding emonTH) and that made a huge difference. Since that moment I have not spotted a single disregarded frame!

I now have a working temperature sensor/energy consumption monitor!

Thanks for the help!

I am also seeing many discarded frames. What exactly did you do to add the 120ms delay? ie what did you edit and where?

Look in emontx_lib.ino, where the transmit function is:

void send_rf_data()
{
rf12_sleep(RF12_WAKEUP);
// if ready to send + exit loop if it gets stuck as it seems too
int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
rf12_sendStart(0, &emontx, sizeof emontx);
// set the sync mode to 2 if the fuses are still the Arduino default
// mode 3 (full powerdown) can only be used with 258 CK startup fuses
rf12_sendWait(2);
rf12_sleep(RF12_SLEEP);
}

Add a delay ( delay(120); )
After
rf12_sleep(RF12_WAKEUP);

/Bjorksta

I have found it but. What does it look like once done?  same line ? next line? I have no idea how to write this stuff so thanks in advance.

Mine is emontx3.4 so a bit different.

There are several different causes for packets being discarded due to crc failure. If you can post some of the discarded packets, it may be possible to confirm the actual cause. The fix used here is quite specific to the rf12 sleep routine affecting the next packet sent.

Is this in connection with the emonTx v3 you are posting about in another thread? If so, it is more likely to be due to the unused temp sensor circuits causing a long run of zero bits.

Paul

I have zero discards from the older Pi with rf12 emontx3.2 firmware even though the emontx are at long distance from Pi. And lots of discards from new Pi rf69 emontx3.4 firmware with node really close..

Could you post that as a longer text file - the single screen full is a bit limiting.  What is shown are discarded noise packets (look at the signal strength in brackets at the end of the packet dump).  The 'good' packets are way too strong - just fold the antenna up on the Tx side to get the strength below -30dBm

Paul, This is the new pi2 with emon tx3.4 with firmware as supplied 2 weeks ago. So temp string is 300 for non existent ones. I get zero discards from old pi(with new firmware) and emontx3.2 with zeros in temp string even though the emontxs are at range extremities. The emontx3.4 is reporting signals of -30 on good packets due to the 2 units being side by side. too strong? I did consider hard wiring them together but purchasing without rf modules wasn't possible I was told.

So are you actually missing any data ?

If so where are you seeing the data is missing? if in emoncms it may be a quirk of "fixed intervals" and you should check emonhub.log. 

"discarded" packets are anything that didn't pass the crc checks, this includes anything that is received from other non-rfm devices eg a neighbors doorbell, baby monitors etc, plus any rfm packets from another group and occasionally some corrupted valid packets caused by issues including those mentioned above eg bitslip or the rf12 wakeup issue.

If there are lost packets to be retrieved we may be able to find the cause by studying the "discarded" packets, to do that we would need a sizeable chunk of actual data that can be manipulated, sorted and searched rather than a picture of a snippet. The first thing to be done would probably be to filter out anything with a very low RSSI as it can be assumed these are distant devices of no interest (unless debugging a weak signal of course) then patterns and similarities between valid and failed packets are studied.

If you do not want to use the RF search the term "serial-direct" on this forum, it is possible to not use the rf regardless of whether the emontx is available without a fitted rfm module.

Paul

Thanks Paul,

Yes I saw the stuff about direct connection a little while back. That's what made me think of doing it because the devices are so close together in this instance. But when I discovered that the units came with rf anyway I decided to use rf.

What is interesting (I think) is that the older pi with 2 emontx3.2s and their firmware suffers zero discarded packets even though one emon tx is again 6 inches away from the pi and the other is 30yrds through 2 brick walls.

I think it is the term "discarded" that maybe unhelpful. lets use the term "garbage", most of the time the "garbage" is just that, garbage, not abnormal and of zero interest. The older system seems to be operating as expected, 30 yards and 2 brick walls isn't an impossible ask and the fact you have no dropped packets confirms that. there will be a difference in received signal strength between the near and far devices but you cannot see that as it is an rfm12b based receiver, another brick wall or 5 more yards may of had different results and if you were finding the occasional dropped packet the first easy check may have been to try and reduce that span to reduce signal loss as a test, but you are not so all is well on that front.

The newer system which I also suspect is not losing any packets is a rfm69 based receiver so it is a more sensitive receiver and will not only see stronger and more "good packets" but also more "garbage" as it has a stronger listener. it is also a potentially noisier frequency depending on other tech you and you neighbors have. so it is not abnormal to see lots of garbage in the -90 to -100 RSSI range and some in the -70 to -80 but at this time you would only really be interested in any packets in say the 0 to -40 range IF you were trying to locate missing packets, otherwise there is unlikely to be anything of interest.

Paul