Have you considered the possibility that either the data or the checksum/cr= c = might have been received wrong and that the checksum/crc check really shoul= d = have discarded the reading? /Ruben > 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=3D13.5 H=3D86 > 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 : > > It looks like a simple parity check to me. =A0Put the nibbles into colu= mns 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 o= f data > > shown below: > > > > T=3D13.4 H=3D86 > > 0000 > > 0111 > > 1100 > > 0110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 0100 =A0<--checksum > > 1433 =A0<--bits set in columns > > > > > > T=3D13.5 H=3D86 > > 0000 > > 0111 > > 1100 > > 1110 > > 0001 > > 0000 > > 0110 > > 0001 > > > > 1000 =A0<--checksum > > 2333 =A0<--bits set in columns > > > > > > Regards > > > > Mike > > > >> -----Original Message----- > >> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Beha= lf 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 : > >> > 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 =A0out if it's a crc or a simple > >> > checksum. > >> Yes, I have loads of data. Here are some examples: > >> T =A0 =A0 H > >> 13.4 =A086 =A0 =A0 =A000000111110001100001000001100001 0100 > >> 13.5 =A086 =A0 =A0 =A000000111110011100001000001100001 1000 > >> > >> 13.1 =A086 =A0 =A0 =A000000111100011000001000001100001 1110 > >> 13.0 =A086 =A0 =A0 =A000000111100001000001000001100001 0001 > >> > >> 12.3 =A088 =A0 =A0 =A000000111110011011110000000010001 0011 > >> 12.3 =A089 =A0 =A0 =A000000111100011011110000010010001 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=3DKA1811 > >> > >> Matt > >> > > >> > Richard > >> > > >> > 2010/1/13 Sarin Sukumar A : > >> >> What ever you should =A0have the crc polynomial that used in the crc > >> >> caculation =A0in the =A0transmitter > >> >> YOurs SaRIn.... > >> >> > >> >> On Tue, Jan 12, 2010 at 5:21 PM, Matt Callow > >> 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), =A0channel id, 12 = bit > >> >>> signed temperature reading and humidity as 2 BCD digits. I think t= he last > >> >>> 4 bits are some sort of checksum/crc > >> >>> > >> >>> This is what I know of the protocol so far > >> >>> > >> >>> ID? =A0CH ?????? Temperature =A0Humidity =A0CRC? > >> >>> 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 calcula= tors > >> >>> such as http://www.lammertbies.nl/comm/info/crc-calculation.html b= ut 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Ruben J=F6nsson AB Liros Electronic Box 9124, 200 39 Malm=F6, Sweden TEL INT +46 40142078 FAX INT +46 40947388 ruben@pp.sbbs.se =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist