Note: I've made progress over at the EE stackexchange on pulling bits out of the signal (see https://electronics.stackexchange.com/questions/145714/what-encoding-is-used-in-this-signal), but now i think this group might be more interested in determining the meaning.

Sniffing the data pin on the receiver's module, i'm getting a 64-bit packet every minute.

The manufacturer states the temperature range as being 0F-158F (see https://support.acurite.com/acurite/topics/what-is-the-temperature-range-of-the-00617)

Changing the station code (there's an A/B/C switch on both sensor and base station), i've been able to determine that the first two bits are the only thing that affects (00=A, 01=B, 10=C).

The sensor and base each have C/F switches, but since a) 1F is smaller than 1C and there is no fractional display, and b) the manufacturer seems to prefer to state the range in F, and c) the F range is strictly nonnegative, it seems likely to me that the data is transmitted in terms of F.

In order to send 159 different levels, it only needs 8 bits, so the remaining 54 (64 - 2 station - 8 minimum data) bits are probably some combination of product ID, battery-level info (it has a "low sensor battery" indicator on the base), extra (unshown) precision, and checksums/crcs. (Of note, despite both sensor and base displays showing min/max readings, they appear to be uncoupled -- resetting one resets its min/max to the next current reading -- so i don't think the sensor transmits its min/max.)

Here are some example captures. I realize i haven't put enough rigor into controlling the temperature yet, but it's interesting to note that the bits change a little even when the display doesn't. There are two things that i suspect could cause this -- 1) maybe there are extra, unshown bits of precision, and/or 2) there is some noise in the signal, as confirmed by viewing the trace on an analog scope, which frequently shows some bits whose length is indeterminately between zero and one. (This also lends support to the idea of a checksum, as i have not observed glitchy data on the base station's display.)

Also note that i have no idea of the bit-order (or endianness) of any of the data in here (other than the tiny hint that it might be MSB-first b/c station code B is "01" and C is "10", but i wouldn't put too much weight on that).

Some very raw initial captures:

0000011110011000110000000000000000000000100011100000001100101101 # 73F (h76F,l69F,bat ok)
00000111 10011000 11000000 00000000 00000000 10001110 00000011 00101101 # bytes? probably not.
000001111001100011[22x0                ]100011101000010010101010 # lotta zeroes.
0000011110011000110000000000000000000000100011100000001100101101 # 73F (h76F,l69F,bat ok)
0000011110011000110000000000000000000000100011101000010010101010 # 73F (h76F,l69F,bat ok)
0000011110011000110000000000000000000000100011100000010100101011 # 73F (h76F,l69F,bat ok)
                                                ^--first difference.

When "sitting still", a few bits near then end change:

0000011110011000110000000000000000000000100011101000010010101010 # 20(min)/23(cur)/25(max)
------------------------------------------------x-----xxx-----xx changing bits.
                                                     x       x   add'l changing bits.

I initially looked for 23d, since Celsius seemed more likely as a sensor output:

0000 0111 1001 1000 1100 0000 0000 0000 0000 0000 1000 1110   0000 0101 0010 1011
   0    7    9    8    C    0    0    0    0    0    8    E      0    5    2    B
0    E    9    1    3    0    0    0    0    0    1    7      0    A    4    D

0000 0111 1001 1000 1100 0000 0000 0000 0000 0000 1000 1110   1000 0100 1010 1010
   0    7    9    8    C    0    0    0    0    0    8    E      8    4    A    A
0    E    9    1    3    0    0    0    0    0    1    7      1    2    5    5

                                                  ^^^^^^-- 0x17 = 23C, which is 73.4F ?
                                                       ^^^^^^^^-- a more realistic 0x17 ?
                                                            no, b/c of the 0x07 above it.

Maybe we need to be looking for ~230(dec) instead of 23? 230=0xE6, 225=0xE1, 235=0xEB, 239=0xEF.
Those are (from 225 up): 11100001, 11100110, 11101011, 11101111. the "1110" is here, MSB-first:
      vvvv                                  vvvv
0000011110011000110000000000000000000000100011101000000110101111 <--.
0000011110011000110000000000000000000000100011101000001010101100    |
0000011110011000110000000000000000000000100011101000010010101010    |
0000011110011000110000000000000000000000100011101000010010101010    |
    ^^^^                                   ^^^^            ^^^^(but only once)
and here, LSB-first.

A pair of them is interesting b/c the cur and max are both 23C, while the min is 21C.

21C is listed as the min temp seen, and 210(degC*10)=0xD2=11010010. (21.9C=0xDB).
So that means we'd expect to see a 1101. Do we? MSB first, then LSB first:
                                             vvvv      vvvv vvvv (not consistent)
                                                            ^^^^ (not consistent)
Not really.

Let's reset the sender. Now min/cur/max are all 23C / 74F (yes, up from the 73F before).


Do we see 3 of the same pattern anywhere?

       vvvvvvvv vvvv 3x 1100 MSB-first

   ^^^^  ^^^^ ^^^^                        ^^^^             ^^^^ 5x 1100 LSB-first

  ^^^^^      ^^^^^                       ^^^^^             ^^^^ 3x 11000 LSB-first

Oddly, 11000b=24d, which is a bit of a near-miss for 23C readings. Probably not
relevant for the 74F unless there's a 50F offset... though come to think of it,
reading down to 50F probably covers the range people would want... Let's see
what the product manual says it can do:

  Temperature Range: 0º to 158º F, -18º C to 70º C
  Temperature Accuracy: +/- 2°

That... looks like degF might be worthwhile to consider.

Oh, but that was the webpage... the PDF says:

  32ºF to 158ºF; 0ºC to 70ºC

which frankly seems more likely.

I started coarsely manipulating the temperature and watching bits rise (^) and fall (v):

(Initially around 23C/74F):
                                                v     ^ v     v

Breathed on it up to 27C (81F):
                                ^      ^    vvv^    v v ^    v

It fell to 24C (75F):
                                v      vv   ^^^ ^    ^  v   ^ ^^
                                                v    v  ^    ^

Then to 24C (74F):
                                        ^      v    ^^^^v   vvv

Then to 23C (74F):
                                                     vv      ^^
                                                      ^v      vv

Still 23C (74F)  [max 27C (81F), min 23C (74F)].

Moved the sensor outside to let the temp fall.
Current & min fell to 20C (68F):
                                        v     v ^     v

Then to 19C (66F):
                                        ^    v^^      ^^^    v

Down to 17C (63F):
                                        v      v        v      ^

Down to 16C (62F):
                                                    v^vv    ^^^v

Where does the temperature data start? The only time we had a bit change in the first 40 bits was when i breathed on it. Let's repeat that to see if those were glitches:

33C (91F):
                                ^      ^^   v^v v     ^ ^   vv ^

Apparently not a glitch. That's a 1 in the 33rd bit, just like before. Maybe the first 32bits are ID? OR, since the temperature goes up another 67F(!!!), maybe all those zeroes are just the high bits of the temperature. (The observed range so far is only 62F-91F (29degF), which is only the middle 1/5 of 0F-158F (158degF)).

Here's where i determined station codes. It had been set to "A" so far. There are also B and C.

73F A:

72F B:
 ^                                            v^v   ^^^ v^  vv v
                                                ^     v ^     v

72F C:
^v                                                      vv
                                                v     ^ ^     ^

Okay, well, the first two bits are clearly station code.
  00=A, 01=B, 10=C

I explored the idea of some of the bits being the model number, but to no avail:

What are the ways to represent 00617, the model number?

6 1 7 = 110 001 111b = 0110 0001 0111b

ASCII for "617" is x36 x31 x37 = 00110110 00110001 00110111

Not seeing it in [000111100110001100000000000000]

More drift without a display change:

1000011110011000110000000000000000000000100011011000101100100110 a
                                                v      v^      ^
1000011110011000110000000000000000000000100011010000101010100111  b
                                                ^     v v     v
1000011110011000110000000000000000000000100011011000100000100101   c
                                                v     ^ ^     ^
1000011110011000110000000000000000000000100011010000101010100111  b
22C (71F):
                                                ^     v v     v
1000011110011000110000000000000000000000100011011000100000100101   c

Looking back at the data, i really need to explore more of the temperature range before drawing conclusions. Water baths below 32F are going to need salt, which is annoying, but at least 158F isn't too terrible for the plastic enclosure (according to http://www.machinist-materials.com/comparison_table_for_plastics.htm and http://plastictroubleshooter.com/ThePlasticTroubleshooter/melt_temps.htm , though it does feel like it could be PVC...).

Current assumption:

|  |               |
|  |               `-- 46 bits of data (temp and maybe batt and checksum
|  |
|  `-- 16 bits of ID (and/or maybe battery health?). Hasn't changed yet.
`-- 2 bits of station code (00=A, 01=B, 10=C)
  • Hi Rob, and welcome to the Reverse Engineering SE beta! We're excited to have new people contribute and your bonus rep indicates that you're already familiar with how SE sites work. That said, we've voted down your question for the following reasons... ??? Feb 19, 2016 at 8:36

1 Answer 1


Folks back on the Electronics SE ( https://electronics.stackexchange.com/a/257112/24681 ) have cracked the case.

There are, in fact, 8 bytes of data in a message.

The last byte(8) is an XOR checksum -- that is, XOR-ing all the bytes including it yields 0xFF.

The three bytes just before the checksum(5-7) are the temperature in Celsius, but encoded a little strangely -- of each byte, the low nibble (4-bits) is temperature data and the high bit (of the high nibble) is used to give the whole byte even parity.

The first two bits of the whole message are the station code (A=00, B=01, C=10).

The remaining bits are still unknown, but I haven't seen them change, either. They might be low-battery & product ID.



breaks into bytes:

10000111 10011000 11000000 00000000 00000000 10001110 00000011 10101101
^^-- station "C"                                               ^^^^^^^^-- checksum

the temperature is encoded:

                                    00000000 10001110 00000011
        even parity for each byte --^--------^--------^
                                        ^^^^-----^^^^-----^^^^-- data (0E3h)

0E3h is 227d, which is simply 22.7°C.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.