Re: R: [amsat-bb] Observed AO-40 FEC coded telemetry

[Phil Karn <karn@xxxxxxxx>]

i8cvs wrote:

> If a different syncronization vector is transmitted by AO40 at the beginning
> of a FEC coded A block than the beginning of  this block cannot be
> recognized by the actual demodulators or by the actual software until
> modifications are made by the experts to make possible to manage 39 15 ED 30
> and the other code for FEC at the same time.

I perform synchronization very differently in the FEC format. Because 
the whole purpose of the FEC format is to withstand deep, rapid fading, 
I didn't want to rely on a conventional sync vector at the beginning of 
the frame that could be taken out by a short fade at the wrong moment.

So my FEC format interleaves both the encoded data and the sync. The 
purpose of interleaving is to take a short fade (or interference hit) 
that would otherwise kill several consecutive bits and spread those 
errors out over the whole frame where the FEC decoder (in this case, a 
Viterbi decoder) has an easier time correcting them. The sync vector is 
similarly spread out over the whole frame.

I use 2D bit block interleaving with dimensions 65 x 80. That is, I form 
a 2-dimensional array of bits with 65 rows and 80 columns, for a total 
of 65x80 = 5200 bits. That takes exactly 13 seconds to transmit at 400 
bps, the fixed rate of the IHU telemetry stream.

The first row of the interleaver always contains a fixed 65 bit sync 
vector; the other rows contain the FEC-encoded telemetry data. While the 
interleaver is filled by rows, it is transmitted by columns. So the 
first bit on the channel is the first bit of the sync vector, followed 
by the first bit of FEC-encoded data, then the 65th, the 130th, and so 
on. After 80 bits, the second bit of the sync vector is transmitted, 
followed by the 2nd bit of FEC encoded data, and so on until the whole 
interleaver array has been transmitted. Combine this with the two layers 
of FEC coding, and any single bit in the original user data will affect 
*many* transmitted bits all throughout the frame -- just what you need 
to protect it against a fade.

At the receiver, the received data is written by columns into another 
65x80 array, this one undoing the effect of the interleaver at the 
transmitter.

Correct block synchronization is clearly vital; if the receiver doesn't 
put the bits into the de-interleaver in the same places they occupied in 
the interleaver at the transmitter, the FEC decoder will see total 
garbage and fail to decode.

Because parts of the sync vector may be missing even with the 
interleaver, I can't look for sync by simply searching for a fixed bit 
pattern as is done in the uncoded format. Instead I use a "correlator", 
a DSP mechanism that looks for "similarity" (if not exactness) between 
an incoming signal and a local replica.  I simply consider every 
incoming bit as the possible first bit of a new frame, and then see what 
the correlator says (remember, it knows where all the sync bits are 
relative to the start of the frame). If the correlator says there's a 
very good match between the incoming signal and the sync vector, I try a 
FEC decode; if that succeeds, then I know I have it right. If not, I 
keep looking.

Sync search can be pretty compute-intensive, but fortunately our 
computers are now pretty fast and have no trouble dealing with a 
heavily-coded 400 bps signal in real time.

Phil



----
Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org