Circrane Solar Pool Thermometer - almost there

[HSkul]

  I purchased a cheap 433 MHz pool thermometer on Amazon (see details here).  The rtl_433 software is able to read the signal using the following:

Use a flex decoder with -X 'n=name,m=OOK_PPM,s=1940,l=3892,g=3908,r=8780'

The transmitted code is 45 bits sent 8 times (single 0 bit at the end I think), except for the last transmission the ending zero bit is missing.  Based on me playing around I think the code is something like this:

10010011 10110000 TTTTTTTTTTTT 00000000 CCCCCCCC 0

----------------  --------------  --------------------------- ---------------  -------------------

 8 bit ID?     battery?       temperature       humidity?       CRC?

• The first 8 bits seem to be fixed so it may be the ID.
• I haven't been able to get the next 4 bits to change and I suspect that it might be battery (0, 1/3, 2/3, 3/3, working on getting battery to show something else than 2/3).  The receiver is supposed to get battery status (according to pictures on Amazon) but no battery status is shown on the receiver so I don't know what  is not working.  I guess it could also be part of the ID.
• The next 4 bits are always 0000
• Temperature is 12 bits signed integer.  Divide by 10 to get temperature in Celcius
• Next 8 bits are always 0 and I suspect that they are for humidity values for weather stations (no humidity here)
• Finally there are 8 bits which I'm assuming are some sort of a CRC
• Ends with a single 0 bit for the first 7 transmissions

So 20.3C transmission is this:

{45}93b00cb003d0, {45}93b00cb003d0, {45}93b00cb003d0, {45}93b00cb003d0, {45}93b00cb003d0, {45}93b00cb003d0, {45}93b00cb003d0, {44}93b00cb003d

  My question is, anyone have any idea what the CRC might be or how I might go around figuring it out?  I've tried several common CRC-8 methods but nothing seems to match.

  Here are few different values with the final zero bit:

93b00b000380
93b0035003f0
93b002f00190
93b000200ee0
93b0ffa007f0
93b0ff2006f0
93b0fef00c80
93b0fec004d0

  Thanks,

  HS

[Christian Z.]

Looks good already. What is the timing output of -A ? Likely the gap should be longer, i.e. if maxiumum gap in the timings is 3908 then it should be g=5000

The last bytes does look like a checksum, but the usual tools (reveng, revdgst) can't find anything. Here is a BitBench of the data. With much more data it should be possible to map the checksum out.

[HSkul]

  Here is an update.  Looks like the second byte is not the battery.  This product is actually not as advertised as the receiver doesn't show any battery status, neither for the chargeable battery on the transmitter nor the AAA batteries in the receiver.  I've charged the transmitter up 100% in the sun and the second byte doesn't change so no battery signal and the receiver doesn't show battery status.

 Here is what I get with -A.  I'm not entirely sure how to read this:

Analyzing pulses...
Total count:  367,  width: 1176.40 ms (294101 S)
Pulse width distribution:
 [ 0] count:  367,  width:  500 us [492;520] ( 125 S)
Gap width distribution:
 [ 0] count:  120,  width: 3892 us [3888;3900] ( 973 S)
 [ 1] count:  239,  width: 1936 us [1924;1952] ( 484 S)
 [ 2] count:    7,  width: 8768 us [8764;8772] (2192 S)
Pulse period distribution:
 [ 0] count:  120,  width: 4392 us [4388;4416] (1098 S)
 [ 1] count:  239,  width: 2440 us [2432;2452] ( 610 S)
 [ 2] count:    7,  width: 9264 us [9264;9272] (2316 S)
Pulse timing distribution:
 [ 0] count:  367,  width:  500 us [492;520] ( 125 S)
 [ 1] count:  120,  width: 3892 us [3888;3900] ( 973 S)
 [ 2] count:  239,  width: 1936 us [1924;1952] ( 484 S)
 [ 3] count:    8,  width: 8920 us [8764;10004] (2230 S)
Level estimates [high, low]:  15982,    334
RSSI: -0.1 dB SNR: 16.8 dB Noise: -16.9 dB
Attempting demodulation... short_width: 1936, long_width: 3892, reset_limit: 8776, sync_width: 0

Use a flex decoder with -X 'n=name,m=OOK_PPM,s=1936,l=3892,g=3904,r=8776'

I'd like to figure out the checksum in the end.  Any other tools out there?  I tried ChatGPT but it was too complicated for it.

  Thanks,

    HS

[Jim K]

Any further luck here?  I attempted to reverse engineer the CRC but didn't find a pattern in the data.  Adding some messages from my sensor below (without the first seven with the trailing 0).  Also my sensor is labeled FCC ID 2ATK8SH-PT-002.

92600f4005b
92600f500d8
92600f6005d
92600f700de
92600f8004f
92600f900cc
92600ee007d
9260111007f
926010000cc
92600f20059

-A output

Analyzing pulses...
Total count:  367,  width: 1191.95 ms           (297988 S)
Pulse width distribution:
 [ 0] count:  367,  width:  532 us [512;580]    ( 133 S)
Gap width distribution:
 [ 0] count:  128,  width: 3860 us [3816;3880]  ( 965 S)
 [ 1] count:  231,  width: 1904 us [1852;1932]  ( 476 S)
 [ 2] count:    7,  width: 8728 us [8712;8752]  (2182 S)
Pulse period distribution:
 [ 0] count:  128,  width: 4392 us [4384;4404]  (1098 S)
 [ 1] count:  231,  width: 2440 us [2432;2452]  ( 610 S)

 [ 2] count:    7,  width: 9264 us [9264;9272]  (2316 S)
Pulse timing distribution:

 [ 0] count:  367,  width:  532 us [512;580]    ( 133 S)
 [ 1] count:  128,  width: 3860 us [3816;3880]  ( 965 S)
 [ 2] count:  231,  width: 1904 us [1852;1932]  ( 476 S)
 [ 3] count:    8,  width: 8888 us [8712;10004] (2222 S)
Level estimates [high, low]:  15819,   1790
RSSI: -0.2 dB SNR: 9.5 dB Noise: -9.6 dB
Frequency offsets [F1, F2]:   -2780,      0     (-10.6 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB038040702140F14077022B88182828182828182828181828282828282828282818181818181818282828282828282828281828281818281828355+AAB037040102140F14077022B881828281828281828281818282828282828282828181818181818182828282828282828282818282818182818355
Attempting demodulation... short_width: 1904, long_width: 3860, reset_limit: 8756, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=1904,l=3860,g=3884,r=8756'

[Christian Z.]

It doesn't look like a CRC, not enough randomness. Looks like an XOR pattern (for fixed bit changes there are fixed bit toggles in the checksum). We'd need much more unique values to find the checksum algorithm.

[Jim K]

Here is more data.

92600e6006d
92600e700ee
92600e8007f
92600e900fc
92600ea0079
92600eb00fa
92600ec007b
92600ed00f8
92600fd00c8
9260111007f
9260121002f
926012800bc
926011c00e8
926012000ac
926011f006d
926011800ec
926011400f8
926010d005b
926010a00da
926010800dc
926010600ce
926010400c8
92601030049
9260101004f
926010000cc
92600ff00ce
92600fe004d
92600fc004b
92600fb00ca
92600fa0049
92600f900cc
92600f8004f
92600f700de
92600f6005d
92600f500d8
92600f4005b
92600ef00fe
92600e4006b
92600e100ec
92600c20009
92600c0000f
92600bf000e
92600be008d
92600bc008b
92600bb000a
92600cb009a
92600d4003b
92600d500b8
92600d8002f
92600dd00a8
92600e20069
92600f0005f
92600f20059
926010200ca
9260105004b
9260107004d
9260109005f

[Christian Z.]

That shows a somewhat broken LFSR as checksum. We'd need to see changes at other places in the data, it's not clear how to continue the LFSR pattern.

It seems the 0x08 bit is strangely stuck and the carry in the last row should have been one row later?

See here which single bit changes cause what change in the checksum:

https://triq.org/bitbench/#c=0000004000%20c0&c=0000002000%2060&c=0000001000%2030&c=0000000800%2010&c=0000000400%2004&c=0000000200%2006&c=0000000100%2083&f=8b%208b%208b%208b%208b%20%7C%208b&z=1

[Jim K]

I started working on a feature branch for this sensor.  I am not a C programmer so I would appreciate help.  Still haven't gotten anywhere with the CRC.

https://github.com/Ceer123/rtl_433/tree/feat-circrane

model     : Circrane Pool Thermometer              Sensor ID : 2342
Temperature: 18.2 C      mic       : NONE

[HSkul]

   Looks like we have the same thermometer so we should be able to figure this out between the two of them.  Note that as far as I can tell, the battery indicator doesn't work for neither the transmitter nor the receiver.  The pictures on Amazon show that there should be a battery indicator for both, but at least on mine (and the 'professional' reviewers on Amazon) they are absent (although the 'professional' reviewers didn't notice).  So my guess is that there is no signal for battery status.

  Based on the additional data from you it looks like the data is structured like the following:

10010011 10110000 TTTTTTTTTTTT 00000000 CCCCCCCC 0

----------------  --------------  --------------------------- ---------------  -------------------

 Manfc ID   -ID-0000       temperature       humidity? checksum

So first are 8 bits of manufacturers ID (93), then 4 bits (or I maybe 8 bits) of thermometer ID (mine is 'b', yours is '6') followed by 4-bit zero.  12 bit of temperature, 8-bits of zeros (probably reserved for humidity) followed by some checksum and a zero bit.

  Note that supposedly these have a fixed channel so I don't think the 4 bit ID is a channel number.

  Here are some additional values from my thermometer.  I'll take a second look at this checksum now that it looks like it is some sort of a LFSR.

93b00b000380
93b0035003f0
93b002f00190
93b000200ee0
93b0ffa007f0
93b0ff2006f0
93b0fef00c80
93b0fec004d0

93b0fe700d80
93b0fd4000d0
93b00c1002b0
93b00bf00a90
93b00c9003b0
93b00c400ac0
93b00c5002f0
93b00c200ae0
93b00ca00be0
93b00c600aa0
93b00c400ac0
93b00be002a0
93b00b700b90
93b00c600aa0
93b0092005e0
93b0044002c0
93b003700390
93b00d700190

  I can help with the C programing once we figure out the checksum.

  I tried letting AI figure out the checksum but it seemed too complicated and required a paid account.

  HS

[Jim K]

I have mine working now with the branch I posted above.  Seems to work ok for what I need it to do.  I haven't seen any odd readings, so while calculating the checksum would be great, the current method of requiring 4 identical messages seems to be good enough to filter out noise.