11 Juin 2011
Obviously the last 2 quartets of a 40 bits message are a kind of checksum or CRC. Indeed their value changes according to the other quartets of the message. If the other part of the message doesn't change they don't change.
But they change with enough randomness that they can't be a simple checksum.
Might that 2 last quartets be a CRC ? a 8 bits CRC ?
A CRC (Cyclic Redundancy Code) is an error detecting code that is calculed over a bunch of information and appended to it.
CRCs are very often used in data transmission over the air.
In such cases the information and the CRC are both transmitted. The receiver calculates the CRC over the information it has received and compares with the transmitted CRC. If both differ it means an error happens during the transmission of the message.
Refer to http://en.wikipedia.org/wiki/Cyclic_redundancy_check for more information.
For a more complete (but painless) comprehension the following website is kind of mandatory :
A painless guide to CRC by Ross Williams.
Before really trying to reverse-engineering this CRC I browsed a little and have found an interesting site :
Reverse-engineering a CRC by Gregory Ewing.
Gregory has managed to find the polynom of the CRC he tried to reverse-engineer by using specifically forged messages.
He generated a few messages composed of all bits to 0 except 1 :
message #1 : 00 80 00 message #2 : 00 40 00 message #3 : 00 20 00 message #4 : 00 01 00
In order to adapt this method to the TX29 sensor I patiently waited for the temperature to vary between the above values. I use the heat of my palms to slowly increase the sensor temperature.
Eventually I've got the following messages (hexa) :
9 a 6 6 0 1 6 a 6 8 9 a 6 6 0 2 6 a 4 5 9 a 6 6 0 4 6 a 1 f 9 a 6 6 0 8 6 a a b
01 02 04 08
68 45 with 68 => 4a 1f with 45 => 4a ab with 1f => 4a
But not that further.
In order to find the poly I have collected a set of messages that I know have been correctly received. In fact I have selected messages that I have received identically 2 or three times or more in a row.
And I developped a python script that tries every value of polynom on all the messages.
They are a total of 256 different polynoms for a CRC that is 8 bits long, so the brute force approach should not be too long.
For the record at first I had a bug in my polynom division function and I did not manage to find a polynom that matches for all my messages with an initial register value of 0.
That's why I modified the python script so that it scans all the initial values from 0 to 255 for every polynom from 0 to 255.
But after having corrected my polynom division function I managed to find the polynom value (and the initial value which is 0).
The python script that do this is called brutef.py is available as part of this source package.
Again I recommend that you carrefully read Ross Williams's A painless guide to CRC.
Eventually I found the polynom value : 0x31 (0x131)
The CRC polynom is thus : x8 + x5 + x4 + 1
It is simply a standard CRC-8 (width 8 bits).
The python script called raw.py implements this CRC in order to check the received messages.
It is very interesting to know the CRC used by the TX29 and TX29D sensors because after a few experiments it occured to me that the transmission is not very reliable.
It may be due to my soldering skills, to my test setup, or it may also be due to interferences in the 868MHz band.
I observed that the following accidents occur frequently at the reception :