FEC

[hprice@bektek.com (Harold Price)]

>The programs need a couple of things to make them more useful to
>ham radio.  Especially we non-programmers and MS-DOS types.

Yes, indeed they do.  I put an early version of Phil's FEC code on the air
last year.  What I did was write a driver for a DRSI card so I could get
access to raw bits (I used the sync mode of the SIO/SCC).

Once you have raw bits, you need to regain frame sync so you can tell where
the first bit of the encoded frame is.  I used an 8-byte sync vector,
sliding all bits through a hamming-distance calculator (doing an XOR between
the sync vector and the shift register, counting the one bits, and rejecting
if the number of one bits is above a threshold limit).  This allows a
slightly damaged sync vector to be detected, while rejecting random noise as
well as the target vector not shifted to the right position yet.

I also used an end of frame sync vector as a kludge to tell how many bits to
clock through the sequential decoder.  Once I detected the start and end of
the frame, I fed it to the decoder. It worked pretty good in actual on-airs
tests against a Reed-Solomon implementation.  I also did some bit
interleaving to solve a problem with double bit errors.  As I was using NRZI
to allow the SCC to recover clock, a single hit sometimes resulted in two
bit flips.  The more bits in error in a row, the longer it takes the decoder
to converge.  In general, interleaving is frowned on, unless you know
something about the incoming errors.  In my case, using the interleaving
reduced the average CPU load to decode the frames.

Harold