On Mon, Apr 11, 2011 at 5:47 PM, Joe Fitzgerald [email protected]wrote:

I am curious to see how your BPSK1000 fares on a rapidly tumbling platform. Let's hope ISS doesn't start tumbling more than once per orbit!

It's a pretty sensitive mode, but it still won't work with a zero-watt transmitter.

If you do convince them to leave the ISS powered up on board ISS, we could evaluate rapit deep fades in the channel by putting middle school students in charge of holding an arrow antenna.

My concern is that the on/off cycling won't play well with my convolutional interleaver. It takes 16.384 seconds to fill the interleaver at AOS. You might get decoded data up to 8 seconds earlier than that if what you do get is very clean, but there's little margin for additional error correction.

And when the transmitter switches off, the interleaver will drain over 16.384 seconds as it fills with noise. If the signal in the last 16.384 seconds before switch-off is unusually strong, you may be able to decode data up to 8 seconds before LOS. But anywhere from 8 to 16 seconds will be chopped off *each end* of each already very short 40-60 second transmission.

I designed this signal to deal well with occasional deep fades lasting up to 1-1.5 seconds -- not for total "fades" lasting 2 minutes at a time. Had I known that this "emergency low power mode" was actually going to be used, I would have designed the whole mode completely differently, with block interleaving aligned to the transmit on/off times.

The golden rule of the modem designer: "know your channel". Optimizing for one impairment usually pessimizes it for something else.

To elaborate:

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

8.192 seconds is longer than 7.232 seconds.

Ooops.

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

Double oops.

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.

In low power mode, the transmission is started clean every time. A single telemetry data frame is only 256 bytes so about 4 seconds of data. After the 1 frame, the transmitter is left on until the interleaver is emptied.

Excellent. I don't think anybody ever told me this. I'm glad somebody noticed the problem.

Let's see...256 bytes is 2K bits. At rate 1/2, that encodes to 4K channel symbols that take 4.096 sec to send, just as you said.

The very first symbol of the frame hits the modulator right away at T=0, but the last symbol from the front of the frame won't come out until about T = 16.384 sec, the interleaver span.

4.096 sec after that (at T=20.48 sec elapsed time) the last symbol from the end of the frame emerges. So you take 20.48 sec, start to finish, to transmit 2k bits of user data for an effective data rate of 100 bps (vs 500 bps in continuous mode). And that's only counting the time the transmitter is on.

Does the transmitter then go off at 20.48 sec, or does another frame start? Where does the 40-60 sec interval come from?

During that 20.48 sec, 20,480 BPSK channel symbols are sent. But only 4K of them actually represent FEC-encoded user data; the other 16K symbols represent known (i.e., idle flag) bits and do not help decode the user data.

10*log10(4096/20480) is about -7 dB. I.e., a system that can operate at an Eb/No of about 5.5 dB now requires an overall Eb/No of 12.5 dB. That's about 3 dB worse than uncoded BPSK...

On the other hand, it should still be somewhat more fade-resistant than that...

Other than the obvious use of block interleaving, it is possible to improve the efficiency of convolutional interleaving (and coding) on short transmissions with "tail biting". You arrange the encoded symbols in a ring and walk around it once. Then you pick an arbitrary point in the receive buffer to start the Viterbi decoder, run it a few constraint lengths to get it synchronized, and then run it around the ring once to actually decode the packet. The tail of the packet gets interleaved with the head so you don't have to fill and drain it with padding. It's actually just a way to construct a block code (or interleaver) out of a convolutional structure.

You see why I wanted a command to turn interleaving on and off?