[amsat-bb] Re: ARRISSat Reception 14.45 UTC
karn at philkarn.net
Mon Apr 11 23:50:44 PDT 2011
BPSK-1000 uses "convolutional interleaving" with a depth of 16,384 symbols.
The symbol rate is 1 kHz (1,000 symbols/sec) so it takes 16.384 seconds for
a data symbol to pass through both the transmit and receive interleave
buffers. The transmitter delay changes a lot from one symbol to the next,
but every symbol experiences the same *total* (transmitter + receiver)
delay: 16,384 symbol times or 16.384 seconds. The idea of any interleaver is
to chop up (short) fades and spread them out in time so that they can be
easily corrected by the Viterbi error correction algorithm (which deals well
with random thermal noise but not with burst errors).
The usual rule of thumb is that an interleaver can easily handle a complete
fade lasting up to 10% of its length, as long as you give it time to recover
between fades. That would be 1.6 seconds, which seemed plenty long for a
continuously transmitting LEO spacecraft on 2 meters.
Of course, you pay a price in delay -- there's no way around it. I have
Sirius Satellite Radio in my car, and it always cuts out 4 seconds *after* I
drive into the parking garage at work. It doesn't come back until (at least)
4 seconds *after* I drive out and it sees the satellite(s) again. The reason
is exactly the same -- an interleaver that takes care of brief fades but not
the really long ones caused by driving into a parking garage.
I chose convolutional interleaving for BPSK-1000 because it has half the
delay of block interleaving for the same fade performance.
Convolutional interleavers also operate continuously, a good match to
ARISSat-1's continuous transmitter. At AOS, your deinterleaver is still full
of noise received earlier; it takes 16.384 seconds to flush it all out and
feed "solid" data to the decoder. During that time, it ramps from pure noise
to pure signal, and at some point it starts correcting what it sees.
Depending on how strong the signal is, that may happen before the flushing
is complete. I.e., it might reconstruct some of the missing symbols sent
before your AOS.
Similarly there is a slow ramp from solid signal down to pure noise over
16.384 seconds at LOS.
See how this helps handle fading? Even an abrupt, complete fade starts the
same, slow 16-second ramp down from signal to noise. If the fade ends only a
second or two later, the rampdown won't have progressed very far and the
decoder will still see mostly signal when the trend reverses and ramps back
up to pure signal. That takes a few extra seconds, but the error correction
can easily handle it all -- as long as the fade isn't *too* long.
Interleaving takes a signal that may be solid one moment and gone the next
and smooths it out so that the signal-to-noise ratio changes only slowly. It
literally averages the signal-to-noise ratio.
Since even a short LEO pass is usually several minutes long, these 16 second
fill/drain intervals didn't seem like a big deal. Besides, we've already had
a similar problem since the old days of the uncoded Phase III block
telemetry format. You might have AOS in the middle of a frame and have to
wait for the next one to start before you can decode anything. Interleaving
isn't really any worse.
The problem is that I didn't count on having the transmitter turned on for
only 40-60 seconds at a time. So....if the transmissions are only 40 sec,
and if you have to wait 16.384 seconds for the interleaver to fill, and you
can't rely on the last 16.384 seconds as the interleaver drains, that leaves
40 - 2*16.384 = 7.232 seconds of solid, noise-free "middle" to work with.
As I recall, ARISSat-1 data frames can be up to 512 bytes long. Ignoring
HDLC flags, bit stuffing, CRC, etc, that's 4K bits. At a data rate of 500
bps (the FEC is rate 1/2), 512 bytes will take 4096/500 = 8.192 seconds to
8.192 seconds is longer than 7.232 seconds.
But wait, there's more. If the satellite sends a series of back-to-back 512
byte frames, and the transmitter comes on too late after one has already
started, you'll have to wait for it to end before you can begin decoding the
next one. Meanwhile, the clock is quickly ticking down until the transmitter
goes OFF again...
Now this probably overstates the problem a bit. Being the engineer that I
am, this is a very conservative analysis -- I made the most pessimistic
assumption at each step. After all, I was stunned when somebody streamed
BPSK-1000 over the net with a lossy MP3 encoder and it *decoded*; I never
thought that would work.
Error correction can fill in for a remarkable variety of ills. In reality,
the satellite won't send a continuous stream of 512 byte frames. In reality,
the key-down intervals may be more than 40 seconds. So I actually won't be
too terribly surprised if the thing actually works. But it won't perform
anything like it will when the satellite is eventually operated in its
intended 100% duty cycle mode.
More information about the AMSAT-BB