> -----Original Message-----
> From:
RemoveMEpiclist-bouncesTakeThisOuT
spammit.edu [
EraseMEpiclist-bouncesspam
spamBeGonemit.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-JonesKILLspam
oclaro.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-bouncesSTOPspam
spam_OUTmit.edu [
spamBeGonepiclist-bouncesSTOPspam
EraseMEmit.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 <
KILLspamrhprosserspamBeGone
gmail.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 <
EraseMEsarinsukumar
EraseMEgmail.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
> >> >>>
> >> >>> --