www.a00.de > tcpgroup > 1995 > msg00290

TCP-group 1995

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


>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.


Document URL : http://www.a00.de/tcpgroup/1995/msg00290.php
Ralf D. Kloth, Ludwigsburg, DE (QRQ.software). < hostmaster at a00.de > [don't send spam]
Created 2005-01-02. Last modified 2005-01-02. Your visit 2021-10-18 18:10.27. Page created in 0.0179 sec.
[Go to the top of this page]   [... to the index page]