Post by thread:[EE] How to determine checksum/CRC parameters

Hi, I've been trying to decode the signals from an RF temperature and humidity sensor. The sensor is a small battery powered sensor which comes as part of an home 'weather station' The messages are all 36 bits long, I've worked out most of it, but it looks like there may be a 4 bit checksum or crc at the end, which I have been unable to work out. Here are some examples, with the information I know. Each message contains a ID (which changes every time the sensor is reset and it used to 'pair' the sensor to the display unit), channel id, 12 bit signed temperature reading and humidity as 2 BCD digits. I think the last 4 bits are some sort of checksum/crc This is what I know of the protocol so far ID? CH ?????? Temperature Humidity CRC? 0001 01 001010 010100110000 1100 0010 1100 0001 10 001010 111100110000 0010 0010 0111 0001 11 001010 011100110000 1100 0010 0111 0001 10 001000 111000110000 0010 0010 0101 0001 10 001000 000100110000 0010 0010 1001 0001 10 001000 100100110000 0010 0010 0001 I think the bits marked ?????? include battery level, and I'm not sure what else. I have lots of data, so I'm thinking that it should be possible to work out the CRC algorithm, however I've tried various crc calculators such as http://www.lammertbies.nl/comm/info/crc-calculation.html but have not been able to find the crc parameters. I've also tried crcbfs.pl to find the crc parameters, however this method requires that I have at least 2 strings of different lengths (which I don't have). Does anyone have any suggestions of how I might work out this CRC (if indeed it is a CRC)? Regards Matt

Hi Matt. I'm about to start a similar exercise so am quite interested in your results. Is yours similar to the one at <www.dse.co.nz/dse.shop/4b4d2e94014260502741c0a87f3b066f/Product/View/Q4255> ?? It would seem to have very similar capabilities. Richard P 2010/1/13 Matt Callow <spam_OUTmc-listsTakeThisOuTtesco.net>: {Quote hidden}> Hi, > > I've been trying to decode the signals from an RF temperature and > humidity sensor. The sensor is a small battery powered sensor which > comes as part of an home 'weather station' > The messages are all 36 bits long, I've worked out most of it, but it > looks like there may be a 4 bit checksum or crc at the end, which I > have been unable to work out. > > Here are some examples, with the information I know. Each message > contains a ID (which changes every time the sensor is reset and it > used to 'pair' the sensor to the display unit), channel id, 12 bit > signed temperature reading and humidity as 2 BCD digits. I think the > last 4 bits are some sort of checksum/crc > > This is what I know of the protocol so far > > ID? CH ?????? Temperature Humidity CRC? > 0001 01 001010 010100110000 1100 0010 1100 > 0001 10 001010 111100110000 0010 0010 0111 > 0001 11 001010 011100110000 1100 0010 0111 > 0001 10 001000 111000110000 0010 0010 0101 > 0001 10 001000 000100110000 0010 0010 1001 > 0001 10 001000 100100110000 0010 0010 0001 > > I think the bits marked ?????? include battery level, and I'm not sure > what else. > > I have lots of data, so I'm thinking that it should be possible to > work out the CRC algorithm, however I've tried various crc calculators > such as http://www.lammertbies.nl/comm/info/crc-calculation.html but > have not been able to find the crc parameters. > > I've also tried crcbfs.pl to find the crc parameters, however this > method requires that I have at least 2 strings of different lengths > (which I don't have). > > Does anyone have any suggestions of how I might work out this CRC (if > indeed it is a CRC)? > > Regards > > Matt > >

Hi Richard, I don't think it's the same (although it may use a similar protocol). Mine came from Jaycar (they no longer stock it). The remote sensor shows both temp and humidity on the LCD display. As far as I can tell, it doesn't have any brand name on it. Matt 2010/1/13 Richard Prosser <.....rhprosserKILLspam@spam@gmail.com>: {Quote hidden}> Hi Matt. > > I'm about to start a similar exercise so am quite interested in your results. > Is yours similar to the one at > <www.dse.co.nz/dse.shop/4b4d2e94014260502741c0a87f3b066f/Product/View/Q4255> > ?? > > It would seem to have very similar capabilities. > > Richard P > > 2010/1/13 Matt Callow <mc-listsKILLspamtesco.net>: >> Hi, >> >> I've been trying to decode the signals from an RF temperature and >> humidity sensor. The sensor is a small battery powered sensor which >> comes as part of an home 'weather station' >> The messages are all 36 bits long, I've worked out most of it, but it >> looks like there may be a 4 bit checksum or crc at the end, which I >> have been unable to work out. >> >> Here are some examples, with the information I know. Each message >> contains a ID (which changes every time the sensor is reset and it >> used to 'pair' the sensor to the display unit), channel id, 12 bit >> signed temperature reading and humidity as 2 BCD digits. I think the >> last 4 bits are some sort of checksum/crc >> >> This is what I know of the protocol so far >> >> ID? CH ?????? Temperature Humidity CRC? >> 0001 01 001010 010100110000 1100 0010 1100 >> 0001 10 001010 111100110000 0010 0010 0111 >> 0001 11 001010 011100110000 1100 0010 0111 >> 0001 10 001000 111000110000 0010 0010 0101 >> 0001 10 001000 000100110000 0010 0010 1001 >> 0001 10 001000 100100110000 0010 0010 0001 >> >> I think the bits marked ?????? include battery level, and I'm not sure >> what else. >> >> I have lots of data, so I'm thinking that it should be possible to >> work out the CRC algorithm, however I've tried various crc calculators >> such as http://www.lammertbies.nl/comm/info/crc-calculation.html but >> have not been able to find the crc parameters. >> >> I've also tried crcbfs.pl to find the crc parameters, however this >> method requires that I have at least 2 strings of different lengths >> (which I don't have). >> >> Does anyone have any suggestions of how I might work out this CRC (if >> indeed it is a CRC)? >> >> Regards >> >> Matt >> >> -

Hi Matt, Thanks. The dse one will display temperature & humidity (alternately) on the same display, or just the temperature, dependent on setup. I have a second receiver unit (broken display) that I'm hoping to connect to a sound card or datalogger to record the incoming bits. It will be interesting if the transmitted number of bits are the same. As you say, the protocol may be the same anyway - or may be entirely different ! Possibly the first 4 bits are a protocol identifier anyway? Have you decoded the temperature & humidity data ? On my one it's fairy obvious that the checksum / crc (etc.) is not very elaborate - gross errors are quite common and I often get a phantom channel 3 reading of rubbish, even though I only have 2 channels operating. (And am not aware of any neighbours with the same system). Richard 2010/1/13 Matt Callow <.....mc-listsKILLspam.....tesco.net>: {Quote hidden}> Hi Richard, > > I don't think it's the same (although it may use a similar protocol). > Mine came from Jaycar (they no longer stock it). The remote sensor > shows both temp and humidity on the LCD display. As far as I can tell, > it doesn't have any brand name on it. > > Matt > > 2010/1/13 Richard Prosser <EraseMErhprosserspam_OUTTakeThisOuTgmail.com>: >> Hi Matt. >> >> I'm about to start a similar exercise so am quite interested in your results. >> Is yours similar to the one at >> <www.dse.co.nz/dse.shop/4b4d2e94014260502741c0a87f3b066f/Product/View/Q4255> >> ?? >> >> It would seem to have very similar capabilities. >> >> Richard P >> >> 2010/1/13 Matt Callow <mc-listsspam_OUTtesco.net>: >>> Hi, >>> >>> I've been trying to decode the signals from an RF temperature and >>> humidity sensor. The sensor is a small battery powered sensor which >>> comes as part of an home 'weather station' >>> The messages are all 36 bits long, I've worked out most of it, but it >>> looks like there may be a 4 bit checksum or crc at the end, which I >>> have been unable to work out. >>> >>> Here are some examples, with the information I know. Each message >>> contains a ID (which changes every time the sensor is reset and it >>> used to 'pair' the sensor to the display unit), channel id, 12 bit >>> signed temperature reading and humidity as 2 BCD digits. I think the >>> last 4 bits are some sort of checksum/crc >>> >>> This is what I know of the protocol so far >>> >>> ID? CH ?????? Temperature Humidity CRC? >>> 0001 01 001010 010100110000 1100 0010 1100 >>> 0001 10 001010 111100110000 0010 0010 0111 >>> 0001 11 001010 011100110000 1100 0010 0111 >>> 0001 10 001000 111000110000 0010 0010 0101 >>> 0001 10 001000 000100110000 0010 0010 1001 >>> 0001 10 001000 100100110000 0010 0010 0001 >>> >>> I think the bits marked ?????? include battery level, and I'm not sure >>> what else. >>> >>> I have lots of data, so I'm thinking that it should be possible to >>> work out the CRC algorithm, however I've tried various crc calculators >>> such as http://www.lammertbies.nl/comm/info/crc-calculation.html but >>> have not been able to find the crc parameters. >>> >>> I've also tried crcbfs.pl to find the crc parameters, however this >>> method requires that I have at least 2 strings of different lengths >>> (which I don't have). >>> >>> Does anyone have any suggestions of how I might work out this CRC (if >>> indeed it is a CRC)? >>> >>> Regards >>> >>> Matt >>> >>> --

Your message is obviously being blocked by nybbles. There are several possibilities for the final nybble: 1. It's parity, even or odd. 2. It's a checksum or the complement of a checksum. 3. It's a CRC or the complement of a CRC, in which case there are only 16 possible polynomial nybbles to use. 4. It's none of the above. The brute force method of cracking the code is to check each one of these possibilities on your test set to see which works. At 08:21 PM 1/12/2010, Matt Callow wrote: {Quote hidden}>Hi, > >I've been trying to decode the signals from an RF temperature and >humidity sensor. The sensor is a small battery powered sensor which >comes as part of an home 'weather station' >The messages are all 36 bits long, I've worked out most of it, but it >looks like there may be a 4 bit checksum or crc at the end, which I >have been unable to work out. > >Here are some examples, with the information I know. Each message >contains a ID (which changes every time the sensor is reset and it >used to 'pair' the sensor to the display unit), channel id, 12 bit >signed temperature reading and humidity as 2 BCD digits. I think the >last 4 bits are some sort of checksum/crc > >This is what I know of the protocol so far > >ID? CH ?????? Temperature Humidity CRC? >0001 01 001010 010100110000 1100 0010 1100 >0001 10 001010 111100110000 0010 0010 0111 >0001 11 001010 011100110000 1100 0010 0111 >0001 10 001000 111000110000 0010 0010 0101 >0001 10 001000 000100110000 0010 0010 1001 >0001 10 001000 100100110000 0010 0010 0001 > >I think the bits marked ?????? include battery level, and I'm not sure >what else. > >I have lots of data, so I'm thinking that it should be possible to >work out the CRC algorithm, however I've tried various crc calculators >such as http://www.lammertbies.nl/comm/info/crc-calculation.html but >have not been able to find the crc parameters. > >I've also tried crcbfs.pl to find the crc parameters, however this >method requires that I have at least 2 strings of different lengths >(which I don't have). > >Does anyone have any suggestions of how I might work out this CRC (if >indeed it is a CRC)? > >Regards > >Matt > >

What ever you should have the crc polynomial that used in the crc caculation in the transmitter YOurs SaRIn.... On Tue, Jan 12, 2010 at 5:21 PM, Matt Callow <RemoveMEmc-listsTakeThisOuTtesco.net> wrote: {Quote hidden}> Hi, > > I've been trying to decode the signals from an RF temperature and > humidity sensor. The sensor is a small battery powered sensor which > comes as part of an home 'weather station' > The messages are all 36 bits long, I've worked out most of it, but it > looks like there may be a 4 bit checksum or crc at the end, which I > have been unable to work out. > > Here are some examples, with the information I know. Each message > contains a ID (which changes every time the sensor is reset and it > used to 'pair' the sensor to the display unit), channel id, 12 bit > signed temperature reading and humidity as 2 BCD digits. I think the > last 4 bits are some sort of checksum/crc > > This is what I know of the protocol so far > > ID? CH ?????? Temperature Humidity CRC? > 0001 01 001010 010100110000 1100 0010 1100 > 0001 10 001010 111100110000 0010 0010 0111 > 0001 11 001010 011100110000 1100 0010 0111 > 0001 10 001000 111000110000 0010 0010 0101 > 0001 10 001000 000100110000 0010 0010 1001 > 0001 10 001000 100100110000 0010 0010 0001 > > I think the bits marked ?????? include battery level, and I'm not sure > what else. > > I have lots of data, so I'm thinking that it should be possible to > work out the CRC algorithm, however I've tried various crc calculators > such as http://www.lammertbies.nl/comm/info/crc-calculation.html but > have not been able to find the crc parameters. > > I've also tried crcbfs.pl to find the crc parameters, however this > method requires that I have at least 2 strings of different lengths > (which I don't have). > > Does anyone have any suggestions of how I might work out this CRC (if > indeed it is a CRC)? > > Regards > > Matt > > -

Matt, Do you have enough data to be able to look at a single bit change (temperature ?) and see how that changes the final nibbles. This should at least assist in figuring out if it's a crc or a simple checksum. Also - How did you capture the data? Have you got a logic analyser or did you use a sound card on a PC & translate it from there? Richard 2010/1/13 Sarin Sukumar A <spamBeGonesarinsukumarspamBeGonegmail.com>: {Quote hidden}> What ever you should have the crc polynomial that used in the crc > caculation in the transmitter > YOurs SaRIn.... > > On Tue, Jan 12, 2010 at 5:21 PM, Matt Callow <TakeThisOuTmc-listsEraseMEspam_OUTtesco.net> wrote: > >> Hi, >> >> I've been trying to decode the signals from an RF temperature and >> humidity sensor. The sensor is a small battery powered sensor which >> comes as part of an home 'weather station' >> The messages are all 36 bits long, I've worked out most of it, but it >> looks like there may be a 4 bit checksum or crc at the end, which I >> have been unable to work out. >> >> Here are some examples, with the information I know. Each message >> contains a ID (which changes every time the sensor is reset and it >> used to 'pair' the sensor to the display unit), channel id, 12 bit >> signed temperature reading and humidity as 2 BCD digits. I think the >> last 4 bits are some sort of checksum/crc >> >> This is what I know of the protocol so far >> >> ID? CH ?????? Temperature Humidity CRC? >> 0001 01 001010 010100110000 1100 0010 1100 >> 0001 10 001010 111100110000 0010 0010 0111 >> 0001 11 001010 011100110000 1100 0010 0111 >> 0001 10 001000 111000110000 0010 0010 0101 >> 0001 10 001000 000100110000 0010 0010 1001 >> 0001 10 001000 100100110000 0010 0010 0001 >> >> I think the bits marked ?????? include battery level, and I'm not sure >> what else. >> >> I have lots of data, so I'm thinking that it should be possible to >> work out the CRC algorithm, however I've tried various crc calculators >> such as http://www.lammertbies.nl/comm/info/crc-calculation.html but >> have not been able to find the crc parameters. >> >> I've also tried crcbfs.pl to find the crc parameters, however this >> method requires that I have at least 2 strings of different lengths >> (which I don't have). >> >> Does anyone have any suggestions of how I might work out this CRC (if >> indeed it is a CRC)? >> >> Regards >> >> Matt >> >> -

2010/1/13 Richard Prosser <RemoveMErhprosserTakeThisOuTgmail.com>: > Matt, > Do you have enough data to be able to look at a single bit change > (temperature ?) and see how that changes the final nibbles. This > should at least assist in figuring out if it's a crc or a simple > checksum. Yes, I have loads of data. Here are some examples: T H 13.4 86 00000111110001100001000001100001 0100 13.5 86 00000111110011100001000001100001 1000 13.1 86 00000111100011000001000001100001 1110 13.0 86 00000111100001000001000001100001 0001 12.3 88 00000111110011011110000000010001 0011 12.3 89 00000111100011011110000010010001 1011 > > Also - How did you capture the data? Have you got a logic analyser or > did you use a sound card on a PC & translate it from there? I used a soundcard on a PC, with this input amplifier. http://www.jaycar.com.au/productView.asp?ID=KA1811 Matt {Quote hidden}> > Richard > > 2010/1/13 Sarin Sukumar A <sarinsukumarEraseME.....gmail.com>: >> What ever you should have the crc polynomial that used in the crc >> caculation in the transmitter >> YOurs SaRIn.... >> >> On Tue, Jan 12, 2010 at 5:21 PM, Matt Callow <EraseMEmc-liststesco.net> wrote: >> >>> Hi, >>> >>> I've been trying to decode the signals from an RF temperature and >>> humidity sensor. The sensor is a small battery powered sensor which >>> comes as part of an home 'weather station' >>> The messages are all 36 bits long, I've worked out most of it, but it >>> looks like there may be a 4 bit checksum or crc at the end, which I >>> have been unable to work out. >>> >>> Here are some examples, with the information I know. Each message >>> contains a ID (which changes every time the sensor is reset and it >>> used to 'pair' the sensor to the display unit), channel id, 12 bit >>> signed temperature reading and humidity as 2 BCD digits. I think the >>> last 4 bits are some sort of checksum/crc >>> >>> This is what I know of the protocol so far >>> >>> ID? CH ?????? Temperature Humidity CRC? >>> 0001 01 001010 010100110000 1100 0010 1100 >>> 0001 10 001010 111100110000 0010 0010 0111 >>> 0001 11 001010 011100110000 1100 0010 0111 >>> 0001 10 001000 111000110000 0010 0010 0101 >>> 0001 10 001000 000100110000 0010 0010 1001 >>> 0001 10 001000 100100110000 0010 0010 0001 >>> >>> I think the bits marked ?????? include battery level, and I'm not sure >>> what else. >>> >>> I have lots of data, so I'm thinking that it should be possible to >>> work out the CRC algorithm, however I've tried various crc calculators >>> such as http://www.lammertbies.nl/comm/info/crc-calculation.html but >>> have not been able to find the crc parameters. >>> >>> I've also tried crcbfs.pl to find the crc parameters, however this >>> method requires that I have at least 2 strings of different lengths >>> (which I don't have). >>> >>> Does anyone have any suggestions of how I might work out this CRC (if >>> indeed it is a CRC)? >>> >>> Regards >>> >>> Matt >>> >>> --

Hi Mike, Thanks for your reply, however I don't think this is the answer. In the second example, you say there are 3 bits set in column 2. In fact there are 4. It should read: T=13.5 H=86 0000 0111 1100 1110 0001 0000 0110 0001 1000 <--checksum 2433 <--bits set in columns So the theory doesn't hold for this data set. I've also tested it with more data, and it doesn't seem to hold. Matt 2010/1/13 Michael Rigby-Jones <RemoveMEMichael.Rigby-JonesEraseMEEraseMEoclaro.com>: {Quote hidden}> It looks like a simple parity check to me. Put the nibbles into columns and count the number of bits set in each column, an odd number gives a zero in the checksum and an even number gives a one, e.g. for the first two lines of data shown below: > > T=13.4 H=86 > 0000 > 0111 > 1100 > 0110 > 0001 > 0000 > 0110 > 0001 > > 0100 <--checksum > 1433 <--bits set in columns > > > T=13.5 H=86 > 0000 > 0111 > 1100 > 1110 > 0001 > 0000 > 0110 > 0001 > > 1000 <--checksum > 2333 <--bits set in columns > > > Regards > > Mike > >> {Original Message removed}

Have you considered the possibility that either the data or the checksum/crc might have been received wrong and that the checksum/crc check really should have discarded the reading? /Ruben {Quote hidden}> Hi Mike, > > Thanks for your reply, however I don't think this is the answer. In > the second example, you say there are 3 bits set in column 2. In fact > there are 4. It should read: > > T=13.5 H=86 > 0000 > 0111 > 1100 > 1110 > 0001 > 0000 > 0110 > 0001 > > 1000 <--checksum > 2433 <--bits set in columns > > So the theory doesn't hold for this data set. I've also tested it with > more data, and it doesn't seem to hold. > > Matt > > 2010/1/13 Michael Rigby-Jones <RemoveMEMichael.Rigby-Jonesspam_OUTKILLspamoclaro.com>: > > It looks like a simple parity check to me. Put the nibbles into columns and > > count the number of bits set in each column, an odd number gives a zero in the > > checksum and an even number gives a one, e.g. for the first two lines of data > > shown below: > > > > T=13.4 H=86 > > 0000 > > 0111 > > 1100 > > 0110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 0100 <--checksum > > 1433 <--bits set in columns > > > > > > T=13.5 H=86 > > 0000 > > 0111 > > 1100 > > 1110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 1000 <--checksum > > 2333 <--bits set in columns > > > > > > Regards > > > > Mike > > > >> {Original Message removed}

Sorry about that, tired old eyes I guess! Mike {Quote hidden}> -----Original Message----- > From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [EraseMEpiclist-bouncesspamspamBeGonemit.edu] On Behalf > Of Matt Callow > Sent: 14 January 2010 01:02 > To: Microcontroller discussion list - Public. > Subject: Re: [EE] How to determine checksum/CRC parameters > > Hi Mike, > > Thanks for your reply, however I don't think this is the answer. In > the second example, you say there are 3 bits set in column 2. In fact > there are 4. It should read: > > T=13.5 H=86 > 0000 > 0111 > 1100 > 1110 > 0001 > 0000 > 0110 > 0001 > > 1000 <--checksum > 2433 <--bits set in columns > > So the theory doesn't hold for this data set. I've also tested it with > more data, and it doesn't seem to hold. > > Matt > > 2010/1/13 Michael Rigby-Jones <RemoveMEMichael.Rigby-JonesKILLspamoclaro.com>: > > It looks like a simple parity check to me. Put the nibbles into columns > and count the number of bits set in each column, an odd number gives a > zero in the checksum and an even number gives a one, e.g. for the first > two lines of data shown below: > > > > T=13.4 H=86 > > 0000 > > 0111 > > 1100 > > 0110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 0100 <--checksum > > 1433 <--bits set in columns > > > > > > T=13.5 H=86 > > 0000 > > 0111 > > 1100 > > 1110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 1000 <--checksum > > 2333 <--bits set in columns > > > > > > Regards > > > > Mike > > > >> -----Original Message----- > >> From: piclist-bouncesSTOPspamspam_OUTmit.edu [spamBeGonepiclist-bouncesSTOPspamEraseMEmit.edu] On > Behalf > >> Of Matt Callow > >> Sent: 13 January 2010 10:44 > >> To: Microcontroller discussion list - Public. > >> Subject: Re: [EE] How to determine checksum/CRC parameters > >> > >> 2010/1/13 Richard Prosser <KILLspamrhprosserspamBeGonegmail.com>: > >> > Matt, > >> > Do you have enough data to be able to look at a single bit change > >> > (temperature ?) and see how that changes the final nibbles. This > >> > should at least assist in figuring out if it's a crc or a simple > >> > checksum. > >> Yes, I have loads of data. Here are some examples: > >> T H > >> 13.4 86 00000111110001100001000001100001 0100 > >> 13.5 86 00000111110011100001000001100001 1000 > >> > >> 13.1 86 00000111100011000001000001100001 1110 > >> 13.0 86 00000111100001000001000001100001 0001 > >> > >> 12.3 88 00000111110011011110000000010001 0011 > >> 12.3 89 00000111100011011110000010010001 1011 > >> > >> > > >> > Also - How did you capture the data? Have you got a logic analyser or > >> > did you use a sound card on a PC & translate it from there? > >> > >> I used a soundcard on a PC, with this input amplifier. > >> www.jaycar.com.au/productView.asp?ID=KA1811 > >> > >> Matt > >> > > >> > Richard > >> > > >> > 2010/1/13 Sarin Sukumar A <EraseMEsarinsukumarEraseMEgmail.com>: > >> >> What ever you should have the crc polynomial that used in the crc > >> >> caculation in the transmitter > >> >> YOurs SaRIn.... > >> >> > >> >> On Tue, Jan 12, 2010 at 5:21 PM, Matt Callow <@spam@mc-lists@spam@spam_OUTtesco.net> > >> wrote: > >> >> > >> >>> Hi, > >> >>> > >> >>> I've been trying to decode the signals from an RF temperature and > >> >>> humidity sensor. The sensor is a small battery powered sensor which > >> >>> comes as part of an home 'weather station' > >> >>> The messages are all 36 bits long, I've worked out most of it, but > it > >> >>> looks like there may be a 4 bit checksum or crc at the end, which I > >> >>> have been unable to work out. > >> >>> > >> >>> Here are some examples, with the information I know. Each message > >> >>> contains a ID (which changes every time the sensor is reset and it > >> >>> used to 'pair' the sensor to the display unit), channel id, 12 bit > >> >>> signed temperature reading and humidity as 2 BCD digits. I think > the > >> >>> last 4 bits are some sort of checksum/crc > >> >>> > >> >>> This is what I know of the protocol so far > >> >>> > >> >>> ID? CH ?????? Temperature Humidity CRC? > >> >>> 0001 01 001010 010100110000 1100 0010 1100 > >> >>> 0001 10 001010 111100110000 0010 0010 0111 > >> >>> 0001 11 001010 011100110000 1100 0010 0111 > >> >>> 0001 10 001000 111000110000 0010 0010 0101 > >> >>> 0001 10 001000 000100110000 0010 0010 1001 > >> >>> 0001 10 001000 100100110000 0010 0010 0001 > >> >>> > >> >>> I think the bits marked ?????? include battery level, and I'm not > sure > >> >>> what else. > >> >>> > >> >>> I have lots of data, so I'm thinking that it should be possible to > >> >>> work out the CRC algorithm, however I've tried various crc > calculators > >> >>> such as www.lammertbies.nl/comm/info/crc-calculation.html > but > >> >>> have not been able to find the crc parameters. > >> >>> > >> >>> I've also tried crcbfs.pl to find the crc parameters, however this > >> >>> method requires that I have at least 2 strings of different lengths > >> >>> (which I don't have). > >> >>> > >> >>> Does anyone have any suggestions of how I might work out this CRC > (if > >> >>> indeed it is a CRC)? > >> >>> > >> >>> Regards > >> >>> > >> >>> Matt > >> >>> > >> >>> -- > >>