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)
0000011110011000110000000000000000000000100011100000001100101101
00000111 10011000 11000000 00000000 00000000 10001110 00000011 00101101 # bytes? probably not.
0000011110011000110000000000000000000000100011101000010010101010
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)
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x-----xxx-----xx changing bits.
0000011110011000110000000000000000000000100011100000001100101101
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
0000011110011000110000000000000000000000100011100000001100101101
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
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)
0000011110011000110000000000000000000000100011100000001100101101
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
0000011110011000110000000000000000000000100011101000000110101111
0000011110011000110000000000000000000000100011101000001010101100
0000011110011000110000000000000000000000100011101000010010101010
0000011110011000110000000000000000000000100011101000010010101010
^^^^
^^^^ (not consistent)
Not really.
Let's reset the sender. Now min/cur/max are all 23C / 74F (yes, up from the 73F before).
0000011110011000110000000000000000000000100011101000100010100110
Do we see 3 of the same pattern anywhere?
vvvvvvvv vvvv 3x 1100 MSB-first
0000011110011000110000000000000000000000100011101000100010100110
0000011110011000110000000000000000000000100011101000100010100110
^^^^ ^^^^ ^^^^ ^^^^ ^^^^ 5x 1100 LSB-first
0000011110011000110000000000000000000000100011101000100010100110
^^^^^ ^^^^^ ^^^^^ ^^^^ 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):
0000011110011000110000000000000000000000100011101000100010100110
v ^ v v
0000011110011000110000000000000000000000100011100000101000100100
Breathed on it up to 27C (81F):
^ ^ vvv^ v v ^ v
0000011110011000110000000000000010000001100000010000000010100000
It fell to 24C (75F):
v vv ^^^ ^ ^ v ^ ^^
0000011110011000110000000000000000000000000011111000010000101011
v v ^ ^
0000011110011000110000000000000000000000000011110000000010101111
Then to 24C (74F):
^ v ^^^^v vvv
0000011110011000110000000000000000000000100011100000111100100001
Then to 23C (74F):
vv ^^
0000011110011000110000000000000000000000100011100000100100100111
^v vv
0000011110011000110000000000000000000000100011100000101000100100
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
0000011110011000110000000000000000000000000011001000100000100100
Then to 19C (66F):
^ v^^ ^^^ v
0000011110011000110000000000000000000000100010111000101110100000
Down to 17C (63F):
v v v ^
0000011110011000110000000000000000000000000010101000101100100001
Down to 16C (62F):
v^vv ^^^v
0000011110011000110000000000000000000000000010101000010000101110
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 ^
0000011110011000110000000000000010000001100001000000011010100011
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:
0000011110011000110000000000000000000000100011101000000110101111
72F B:
^ v^v ^^^ v^ vv v
0100011110011000110000000000000000000000100011010000111101100010
^ v ^ v
0100011110011000110000000000000000000000100011011000110111100000
72F C:
^v vv
1000011110011000110000000000000000000000100011011000110100100000
v ^ ^ ^
1000011110011000110000000000000000000000100011010000111110100010
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?
617d=0x269=1001101001b
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:
ss0001111001100011dddddddddddddddddddddddddddddddddddddddddddddd
--________________----------------------------------------------
| | |
| | `-- 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)
