I have been asked write some hardware assembly (on a PIC), and I've decided it would be wise to add some data protection (such as Parity bit checking).

The data size is 16bits (2 bytes), so, what ever i choose, it will be for a small amount of information. Im currently thinking of just a basic parity check, or perhaps double parity...

But my quesiton is: Can anyone suggest a better algorithm for small amounts of data?

I've thought about perhaps a CRC, but the data size is 2 bytes... so this is probably overkill.. not sure really cause i've only read posts on CRC32.. but never played with it before...

What are your thoughts??
Thanx
Posted on 2002-06-05 15:36:12 by NaN
if your only going to be sending a few bytes at a time how about data replication? i.e. send the same info several times...if the received copies are identical then chances are it was an error free transmission...
Posted on 2002-06-05 15:43:00 by MArtial_Code
how about sending: a = parity, x = normal bit

a x x x x x x x
a x x x x x x x
a x x x x x x x
a x x x x x x x
a x x x x x x x
a x x x x x x x
a x x x x x x x
b b b b b b b

the b's are the 'vertical' paritys, this way even if there is a double invert on a row the vertical ones should pick it up

then just to be safe after every y blocks get a checksum back and compare to the checksum for the sent blocks

i used this type of method a while back in a really electrically noisy environment over a serial link (yeah should have used fibre :-) but worked really well
Posted on 2002-06-05 15:51:00 by Terab
The data protection involved in hardware is tough, if you've got silicon level implementations, then CRC is great.... If you've got to calculate it yourself, then the cost of CRC can cripple you, especially on small data items. Parity is ideal for simple data, when clocks are more important, but there is CRC16 which may be a better bet if the cost of computing it is relativly low, it'll give good protection to data ratio.

Mirno
Posted on 2002-06-05 17:24:32 by Mirno
I guess i need to give more info:

There will be say 100 devices in the field, all emitting an RF id #. The id # is what i want to protect, cause if miss understood things could go south ;)

So i dont really want to sent it more than once. If its determined to be error'd then just ignore the transmittion.

The CRC16 sound interesting, but my question is does this mean 16bits of data, or 16 bit address to 8 bits of data (as i understand CRC32 to mean?)...

As well do you know of any links? I can afford the CPU overhead, but uncertain of its worth. I still think parity looks best since the info being sent is soo small..

Thanx everyone for your thoughts so far!
:alright:
NaN
Posted on 2002-06-05 22:04:19 by NaN
http://cs.baylor.edu/~donahoo/classes/4321/HammingCorrection.pdf

Maybe, you could use two parity bits per byte and correct any
single bit errors? Google for 'ECC algorithm' for tons of links.

Oh, you only have 7 bits of data. The doc is a good example. ;)
  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

C C 1 C 1 1 1 C 1 1 1 1 1 1 1 ?

11 data bits
4 check bits

3 = 1 + 2
5 = 1 + 4
6 = 2 + 4
7 = 1 + 2 + 4
9 = 1 + 8
10 = 2 + 8
11 = 1 + 2 + 8
12 = 4 + 8
13 = 1 + 4 + 8
14 = 2 + 4 + 8
15 = 1 + 2 + 4 + 8
Bit 16 could be parity of 15 bits?
Posted on 2002-06-05 22:23:43 by bitRAKE
Thanx bitRake... I studied this method in school.. Its quite good. As well, its also possible to generate *other* xor patterns. There isnt just one "hamming code basis", however this is the standard ;)

(( I know, because the *other* basis showed up on the final exam, to which pissed off an entire class of students that never knew of such radical thoughts... grrrrrr ;) ))

I've spend the evening scouring the net, and have concluded the best approach should be using this method (for its simplicity), with Differntial Manchester Encoding to pass the data bit via. RF.

Thanx again for your input everyone!
:alright:
NaN
Posted on 2002-06-06 01:16:35 by NaN