Acurite 986 Refer Fridge device data collected

[oldunixguy]

Using my "Faraday cage" and instructions from you folks I have collected my first batch of data for this device. I will collect more as we determine where the problems may be and use different temps and signal attenuation.

Due to the proximity of the transmitter to the RTL-SDR antenna and the exclusion of all other RF this should be considered the maximum signal strength of this device.

This device reports about every 2 minutes. I recorded 157 samples. Samples 1-16 and 51-151 have a specific CRC error on the second packet. The device appears to send 2 consecutive packets each time.

Reports 17-50 and 152-157 indicate no errors.

So, I will attach a bad one (16) and a good one (17).

I would invite suggestions on how I can learn to take this data and decode and check it....

thanks

oldunixguy

[Christian Zuckschwerdt]

The code for this device isn't great but strangely works for me -- I can't see CRC errors here.

The protocol is:

a preamble: 2 times of 216 us pulse + 276 us gap, then 4 times of 1600 us pulse + 1560 us gap
39 bits of data: 220 us pulses with short gap of 520 us or long gap of 880 us.

A transmission consists of two packet that run into each other.

There should be 40 bits of data though. But the last bit can't be detected:

Maybe trying to decode 2 times with a 0 or 1 added might work.

[oldunixguy]

Christian,

1. I'm not sure what you mean that you cant see the CRC errors...

I'm using the code from 2018-05-02. The attached corresponding txt file shows that the 2nd packet has a CRC.

Why are you not seeing this? What is different from the source code you are running?

2. These CRC errors are not random. As I reported, the samples 1-16 and 51-151 have this CRC error on the second packet.

So they come in groups.  Blocks 17-50 and 152-157 indicate no errors. This suggests that either the device is creating a bad packet under some unknown condition or the rtl decoder has some flaw.

3. How do you create the image of the signal that you included here?

thanks

oldunixguy

[Robert Terzi]

See inline:

On 8/10/2018 2:44 AM, oldunixguy wrote:

Christian,

1. I'm not sure what you mean that you cant see the CRC errors...

I'm using the code from 2018-05-02. The attached corresponding txt file shows that the 2nd packet has a CRC.

Why are you not seeing this? What is different from the source code you are running?

Let's back track a bit to get us all on the same page. We know that there is a problem with either the hardware device or the code that demodulates the bits.  The problem is seen by the decoder (the device specific code that interprets the demodulated bits).  On some messages the final bit is missing which gives the wrong CRC.

I put in a work around where if the CRC fails to retry it by adding the missing bit.   Note: if the value of the missing bit was zero the CRC would pass either way because the bits are padded out.  It will only fail when the missing bit is a 1. 

The went in as part of PR #709 - https://github.com/merbanan/rtl_433/pull/709

If you don't have debugging turned up and are running the code after that fix was merged, you will *not* see a CRC error reported because the workaround resolves the problem.

Note: you can see the work around in the debug output you provided.

@0.000000s Acurite 986 sensor bad CRC: ea - 47 00 9e 00 6a
@0.000000s Acurite 986 CRC fix 6a - ea

0x6a was received as the CRC value in the message.   The computed CRC was 0xea,  adding 0x80 + 0x6a == 0xea, so it passes.

2. These CRC errors are not random. As I reported, the samples 1-16 and 51-151 have this CRC error on the second packet.

So they come in groups.  Blocks 17-50 and 152-157 indicate no errors. This suggests that either the device is creating a bad packet under some unknown condition or the rtl decoder has some flaw.

The error can only be see when the computed CRC has the high bit set.   A computed CRC value of < 0x80 will always pass.

Note: the decoder (the device specific code) is getting fewer bits on the message with the problem.  The demodulator is what is recovering the bit stream from the signal.   So the problem is either the hardware or the demodulator/choice of demodulation method.

3. How do you create the image of the signal that you included here?

I believe that image came from Audacity.  You can import the raw data into audacity.  Christian has written a nice plug-in for Audacity.  It take a few manual steps to get to a display like that.

http://triq.net/articles/sdr-nyquist-plugin-am-decode-iq-signals

If I'm interpreting that display correctly, the first track is the 1st message and the 2nd track is the repeat. You can see there is a pulse missing in the repeat.   I believe Christian answered this in his response to you.

>> 39 bits of data: 220 us pulses with short gap of 520 us or long gap of 880 us.

>> A transmission consists of two packet that run into each other.

>> There should be 40 bits of data though. But the last bit can't be detected:

In other words, how do you know if that last gap in the PPM is a short gap or a long gap?

Note: See the comments in Issue 202 by trlafleur - his conclusion is the device (firmware) is to blame.
-  https://github.com/merbanan/rtl_433/issues/202

>> Maybe trying to decode 2 times with a 0 or 1 added might work.

@zuckschwerdt - that's what PR 709 does and that why it "strangely works" for you.  ;-)

So, @oldunixguy is this not working well enough for you?

Hope this helps,
--Rob

thanks

oldunixguy

On Thursday, August 9, 2018 at 12:52:28 AM UTC-6, Christian Zuckschwerdt wrote:

The code for this device isn't great but strangely works for me -- I can't see CRC errors here.

The protocol is:

a preamble: 2 times of 216 us pulse + 276 us gap, then 4 times of 1600 us pulse + 1560 us gap
39 bits of data: 220 us pulses with short gap of 520 us or long gap of 880 us.

A transmission consists of two packet that run into each other.

There should be 40 bits of data though. But the last bit can't be detected:

Maybe trying to decode 2 times with a 0 or 1 added might work.

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/39b83269-6dc2-43b7-8e3c-c286c9121387%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[oldunixguy]

Rob,

thanks for the info....  I have a lot of problems with this device. So I decided to try and do tests to discover what might be wrong.

So my first test is to place it in an RF isolation box (Faraday cage). This would offer the input to the RTL-SDR to be the "best available". What I have provided already are the results of these. Clearly there is something wrong that repeats and affects the 2nd packet when it does.

You wondered why this result is not good enough. The issue here is that when I place these transmitters in my refer and fridge they perform extremely poorly. A significant majority of the packets are not processed for whatever reason. So this is the end goal to find out where that CRC failure is coming from (even tho the current code guesses a fix) and then add more attenuation to the RF and see where it fails for a configuration more closely representing my real world.

Are there any explanations on how the rtl_433 code works? Or how one uses the diagnostic output and manually decode what is happening?

thanks

oldunixguy

[Christian Zuckschwerdt]

Rob is correct on all points. (though I didn't use my Nyquist AM demodulator for Audacity -- the signal has enough offset for a proper visual impression).

The signal is really clean and easy to follow by hand. Perhaps load it in Audacity and transcribe the bits by hand. It's only 39 bits because there is no postamble. The run-in with the 2nd packet allows to read the 40th bit, but I'm not too sure if it will always be correct. I don't think the demodulator missed anything there. I guess I'll change it to PPM_PRECISE someday (i.e. not just a threshold for short/long but a fixed window).

Probably the mentioned fix already addresses your problems with the 1-16, 51-151 files and maybe the bad reception too? Otherwise it's a good debugging tool to stick a `bitbuffer_print(bitbuffer);` in the first few lines of the callback to see what the demodulator spits out.

There is also a feature with periodic reports on e.g. signal quality on the way: https://github.com/merbanan/rtl_433/pull/733

[Robert Terzi]

Inline:

On 8/11/2018 2:08 AM, oldunixguy wrote:

Rob,

thanks for the info....  I have a lot of problems with this device. So I decided to try and do tests to discover what might be wrong.

So my first test is to place it in an RF isolation box (Faraday cage). This would offer the input to the RTL-SDR to be the "best available". What I have provided already are the results of these. Clearly there is something wrong that repeats and affects the 2nd packet when it does.

I think we understand that problem and for me the fix to retry by adding the missing bit works. 

You wondered why this result is not good enough. The issue here is that when I place these transmitters in my refer and fridge they perform extremely poorly. A significant majority of the packets are not processed for whatever reason. So this is the end goal to find out where that CRC failure is coming from (even tho the current code guesses a fix) and then add more attenuation to the RF and see where it fails for a configuration more closely representing my real world.

If you run with debug turned on for long enough you should be able to determine whether the decoder is even firing once a minute, or whether there is more corruption in the packet beyond a missing final bit on the repeat.

There might be a case where the pulse timings no longer give the right shape for decoding when the signal is weak.  The question is whether the decoder is firing or not.   The experimental stats could help with that, or just run with debug and process the log.

I've found the 986 is difficult to receive and quality/reliability is very dependent on positioning -- i.e. polarization.  I've never seen the inside of the 986, but I suspect the antenna is poorly designed.  Changing the orientation (from vertical to horizontal and therefore the polarization changes) makes a big difference.   Pointing the bottom of the sensor towards the direction where the RTLSDR antenna is seems to help. All of my other devices are pretty reliable with a vertical antenna.  I haven't tried using a helical antenna.

If you think about the design of the 986, it wasn't designed for distance or reliability.  It is sold to transmit to a receiver that is on the other side of the door.

I think the "tower" sensor the 592 would be a better choice.  It is designed for distance, transmits 3 times every 18 seconds.

Are there any explanations on how the rtl_433 code works? Or how one uses the diagnostic output and manually decode what is happening?

That's so general it's hard to know where to start.

You could run with -A -I 1 which will enable the decoders, but run the pulse analyzer when no decoder matches the signal.

Alternatively you might want to add some debugging fprintf()s in the decoder to see where it bails out and if it is getting called.

Hope this helps,
--Rob

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/6e440db1-f04b-4e8d-8260-b7bceae4d652%40googlegroups.com.

[oldunixguy]

For those who may be interested here are some photos of the test box I use for these small 433 MHz transmitters. The cookie tin is about 9 in x 9 in and 4 in high and can fit in a refer or freezer.

oldunixguy

[oldunixguy]

Rob,

I can run this for a longer time and collect more.... However, in the 157 captures I made where the device reported every 1 minute 59 seconds not a single one was missed by the rtl-sdr. That was about 5.25 hours. I will go an add bitbuffer_print(bitbuffer) and see what I can learn. I will also let it run longer. These will still be at room temp...

I didn't know the 986 was designed for "local only"... even the magnetic mount for the base doesn't attach to the fridge/freezer as they are now all stainless steel and the mags are too weak for this alloy...

thanks

oldunixguy

[Bill Tracey]

For what it's worth, my experiences with the
Accurite 986 has been good to excellent. I've
got 2 pairs of Accurite 986 sensors I've been
running for more than a year. My setup is an
RTL-SDR dongle with a Diamond MR77 antenna
(https://www.universal-radio.com/catalog/hamantm/3243.html)
and an FM trap filter between the antenna and the
dongle. The antenna sits on a coffee can about 4
feet off the ground The 2 refrigerators are
roughly 20 and 50 feet from the antenna and I
usually get good decodes. The 986's I have send
2 reports when they report every 2 minutes -
sometimes (60%) I decode both packets but I'd
guess I see at least 1 packet every 2 mins at least 90% of the time.

The sensors are definitely position dependent --
I've got mine vertically on the door (the antenna
on the dongle is vertical), or clipped vertically
to a glass in the fridge. I did have to
experiment with placement to get reliable operation.

All in all I'm amazed they work as well as they
do and my compliments and thanks to the author(s) of the code.

Bill

At 06:43 PM 8/11/2018, Robert Terzi wrote:
>Inline:

>
>I've found the 986 is difficult to receive and
>quality/reliability is very dependent on
>positioning -- i.e. polarization. I've never
>seen the inside of the 986, but I suspect the
>antenna is poorly designed. Changing the
>orientation (from vertical to horizontal and
>therefore the polarization changes) makes a big
>difference. Pointing the bottom of the sensor
>towards the direction where the RTLSDR antenna
>is seems to help. All of my other devices are

>pretty reliable with a vertical antenna. I

[Robert Terzi]

Thanks for the info, Bill.   You've certainly got a good setup.  I have an MR77 (and an RH77ca) but I don't use them for rtl_433.  Though I wonder if a coil/helical would be better to capture both vertically and horizontally polarized signals.

It would be interesting if we had a good way of capturing RSSI or some SNR approximation over time.

One of the worst orientations that I noticed is with the sensor suction cupped to the side wall of the fridge.

Some quick and dirty stats with grep, uniq, wc -l, from my current logfile:

Time period is just under 219 hours, so roughly 13,110 minutes or 6,555 two minute intervals.

Sensor 1R    12,210 messages, 6,202 unique messages (discard repeats in the same second with uniq)
Sensor 2F       7,394 messages, 3,845 unique messages

So "1R" was received successfully about 95% of the time.  A repeat was received 6,008 times, so ~92% of the time.

The other sensor, "2F" was received successfully about 59% of the time. A repeat was received 3549 times, so ~54% of the time.  That sensor has always been "weaker" than the other.

Both sensors are in the same side-by-side refrigerator.  They are probably 25 feet from the RTLSDR.

My data is fed into rrdtool with 5 minute buckets. IIRC I'd need to not receive anything for 10 minutes before I'd get a NaN.  I don't see any NaNs in the rrd for the last 30 days.

--Rob

[Bill Tracey]

Rob -- neat quick analysis

At the risk of getting too much minutiae on the list ...

I went through my logs going back to Aug 1, so had 8548 2 minute
periods to look at:

Near (20ft) Freezer: uniq: 8311 (97%), total: 13347 (78%)
Near (20ft) Fridge: uniq: 8423 (99%), total: 12406 (72%)
Far (50ft) Freezer: uniq: 8282 (97%), total: 12167 (71%)
Far (50ft) Fridge (uniq) 8439 (97%), total: 13264 (77%)

Are you using lithium batteries in your 2F unit? Read somewhere
Alkaline's don't do too well below freezing.

I think the lower repeat success rate I've got my be due to the
sensors interfering with each other - they're all transmitting
nominally every 2 minutes, but they've each got there own opinion of
what 2 minutes is so they tend to drift into each other time
wise. I've also go 5 other temp sensors (Ambient Wx F007THs) so
someone's always chirping away it seems.

Bill