New thread here -- there's already one on decoding the 606TX sensor RF data but this is specifically about the check-bits. If you want a good puzzle to work on, this is it.
Here's what I've been able to figure out so far about the message, which is 32-bits long. All data is big-endian order (MSB first, LSB last).
Bits 0..7 are a "rolling code" that randomly changes whenever the sensor is reset (e.g. batteries changed)
Bit 8 is a "battery okay" bit that goes to zero when battery voltage drops below about 2.6 volts.
Bits 9..11 are always zero as far as I've seen.
Bits 12..23 are temperature as a signed (two's complement) 24-bit integer value in 0.1C units. For example 25.0C is coded as the integer 250 and -19.9C is coded as the integer -199.
Bits 24..31 appear to be some sort of checksum/CRC/hash code.
I've not been able to figure out what algorithm is used to compute the check bits. I'm not really great at this but I've seen others work miracles. I've tried using the "crcre.exe" utility with no luck -- but that doesn't necessarily mean all that much.
If anyone can help figure this out it would be much appreciated!
Below are some 32-bit captures in hexadecimal to help in figuring the check bits. The last two hex digits in each line are the check-bits.
Thanks in advance if anyone can figure this out!!!
738fd5e3
7380f6a3
738100a7
73810153
7381027e
7381d197
73809dec
738060b4
fb81004a
fb01009f
fb01016b
688f9de5
688f3377
688f3ab4
688F2B2E
688F29F7
688F2543
688F22ED
688F2319
I've been able to figure out a couple of CRC-type checksums using reveng, an open source program to reverse engineer such computations.
If that doesn't work right off the bat, it is important to capture as many messages as possible. In particular, messages where the data differ by a single bit are extremely useful to deduce the type of checksum.
I've tried "reveng" -- sometimes also called "crcre" with no luck.
There are a couple of sequences above that vary by only one bit:
738100=>a7
738101=>53
738102=>7e
also here:
fb8100=>4a
fb0100=>9f
There's a lot of change in the check bits...a7 to 53 to 7e. That seems to rule out a simple checksum. Regarding crcre I've tried little endian, big endian and also tried reversing the bit and/or nibble order of the check bits all with no luck.
I could (with a bit of work) generate some more sequences where the last two or three data nibbles change by one bit...but I don't have control over all bits of the message so there are limits to how far I could go with that idea.
As I said above, I don't have a great aptitude for this type of task and I'm hoping someone else may have some ideas.
I tried a bit with reveng and got nowhere.
Check out this heroic (and successful) effort. Maybe some ideas there.
At the risk of being arrogant...great minds think alike 
I have previously seen the referenced web page and like you marveled at (and made use of) the effort.
Well, guess what -- this AcuRite sensor is using the same friggin' algorithm!!! Never woulda thought it but AcuRite must be partnering with AmbientWeather to produce the F007TH sensors. I suppose it could be a coincidence but this is such an unusual way to generate check bits (in the world of consumer weather sensors) and both of the sensors are using the exact same LFSR sequence. A coincidence? I think not.
Following the same trail as in the referenced web page I noticed that with single bit changes the modulo-2 difference (or sum -- they are the same -- as in Galois fields of 2) in the check bits was always the same. Meaning that all they were doing was adding (modulo 2) the output from a sequence whenever the data bit was "1".
The only difference is in the initial hash register value and the point at which the sequence starts.
So, thanks for your replies...even though I did much of this myself I would not have gotten there without your prodding.
If anyone wants the specific details, reply back and I'll post them.
P.S. Having an engineering background, I compared the PC boards in the F007TH and 00606TX sensors. While they are not identical copies, the RF transmitter circuits are close to identical, using the same transistors and this lends more credence to the idea that these sensors are very closely related.
Congratulations!
I did suspect there might be a connection between the two manufacturers, as it is easy to use CRC, and hard to imagine why anyone would go to the trouble to (re)invent such an obscure algorithm. Hey, Ambient and Acurite both start with "A"!
I am sure that other people would appreciate it if you could publish your version of the code to calculate the check bits, so please do. Give yourself some credit!
@whowever
Good job, can you post (pseudo) code of the solution?
Okay -- here is a link to a document which I've updated to include information about calculation of the hash code for this sensor. See pages 12-15.
If it's not clear from the document please post back here and I'll try to clarify.