Acurite 606TX sensor decode fails, see attachments

[Sebastian Osterfeld]

I am working on reading out a variety of wireless thermometers, for example with rtl_433, which works really well, overall.

The following sensors are received and displayed correctly with the current build of rtl_433:

"Ambient Weather F007TH Thermo-Hygrometer"

"LaCrosse TX Temperature / Humidity Sensor"

"Fine Offset Electronics, WH2 Temperature/Humidity sensor"

However, when I try to received data from an Acurite 606TX sensor, something fails halfway through the decoding process.

The 606TX sensor sends exactly 8 repeats of a pulse position message (PPM), where pulses are 0.5ms, separated by positioning gaps which are either 2ms or 4ms long. The gaps between repeats are around 8.5ms long. The total transmission is almost a full second, repeated every 30 seconds.

The length of the total transmission makes this sensor less than optimal, since it increase the risk of collisions if there are multiple thermometers. Furthermore, the 606TX has indeed less range than, say, the F007TH. So I wouldn't recommend to buy it, but let's try to get the decoding right anyways.

Here is the problem:

rtl_433 -a seems to properly detect the 8 repeats and composes a nice bitbuffer.

rtl_433 -A however turns this into a 25 row bitbuffer, and I think this causes the decoding to fail.

I think maybe the definition of the pulse lengths for detecting and decoding the 606TX need to be adjusted... ? Probably lines 909, 910, 911 in acurite.c ?

Thanks!

[Sebastian Osterfeld]

Update: I think the problem is actually in pulse_detect.c

Something (the sensor, the software, or maybe RF noise) consistently generates two short ~516 us gaps in the data, which show up in the gaps histogram as bin [0]:

Gap width distribution (sorted by pulse count!):

 [ 0] count:    2,  width:   129 [129;130]      ( 516 us)                // This bin shouldn't have been created, but somehow it keeps happening

 [ 1] count:  144,  width:   515 [512;523]      (2060 us)

 [ 2] count:  112,  width:  1034 [1032;1042]    (4136 us)

 [ 3] count:    8,  width:  2281 [2277;2295]    (9124 us)

This then causes a failure pulse_detect.c where the threshold between short and long pulses is estimated as follows:

547: device.short_limit = (hist_gaps.bins[0].mean + hist_gaps.bins[1].mean) / 2; // Set limit between two lowest gaps

This erroneously calculates the limit for separating short and long gaps as (515+129) / 2 = 322 pulses, when really the calculation should have been (515+1034) / 2 = 774 pulses (or 3.1 ms). 

The following code change appears to fix the calculation:

547: device.short_limit = (hist_gaps.bins[hist_gaps.bins_count-2].mean + hist_gaps.bins[hist_gaps.bins_count-3].mean) / 2;

However, I am not entirely sure if this is the right approach. For example, with this change rtl_433 -A will now show the 8 message repeats nicely in the bitbuffer array (now same as rtl_433 -a), but it still doesn't detect or decode the bitbuffer 606TX data. Not sure why.

[Sebastian Osterfeld]

O.k., so there are two issues:

First, the histogram binning was not working, but can be fixed as described above.

Second, the 606TX bitbuffer is rejected too quickly in acurite.c:

773:    // do some basic checking to make sure we have a valid data record

774:     if ((bb[0][0] == 0) && (bb[1][4] == 0) && (bb[7][0] == 0x00) && ((bb[1][1] & 0x70) == 0))                    //This always fails on my 606TX

If the above test is simplified to only the first two conditions, I am now getting a correct temperature reading (and correct checksum ... ?).

However, the sensor ID is being shown as -79, this doesn't sound right.

With these two changes, the 606TX seems to work o.k.