[OpenTRV-dev] CRC computation

[Damon Hart-Davis]

No (if I’m right) because that behaves poorly on a 16-bit (2-byte) payload: see table 4.

Rgds

Damon


On 20 Apr 2014, at 20:47, Bo Herrmannsen <EMAIL ADDRESS HIDDEN> wrote:

> not sure at all but should it not be:
> 
> CRC-7: 0x48 = (x7+x4+1)‡
> 
> -----Oprindelig meddelelse----- From: Damon Hart-Davis
> Sent: Sunday, April 20, 2014 9:44 PM
> To: Closed list for developer discussions
> Subject: [OpenTRV-dev] CRC computation
> 
> Duh!  My brain hurts!
> 
> Can anyone confirm/deny if this, just written by me, is a correct implementation of CRC7 (0x5B polynomial) as given in the paper specified?
> 
> // Update 7-bit CRC with next byte.
> // Polynomial 0x5B = (x+1)(x^6 + x^5 + x^3 +x^2 + 1).
> // See: http://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
> // For 2 or 3 byte payloads this should have a Hamming distance of 4 and be within a factor of 2 of optimum error detection.
> uint8_t crc7_5B_update(uint8_t crc, const uint8_t datum)
> {
> crc ^= datum;
> for(uint8_t i = 0; ++i <= 8; )
>   {
>   if(crc & 0x80)
>     { crc = (crc << 1) ^ 0x5B; }
>   else
>     { crc <<= 1; }
>   }
> return(crc & 0x7f);
> }
> 
> I’m after something with good behaviour on a 2-byte payload and need a 7-bit CRC in this case for packing efficiency.
> 
> Also, I assume that it’s customary to start with 0xff for the CRC before feeding it real bytes, unless there is a good reason otherwise?
> 
> Rgds
> 
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>