Hi Phil, You are just forgetting. Remember that we needed it in a "pull" rather than "push" interface? That makes it easy to sync everything up.
Low power mode works something like this (my memory isn't great either) When it is time to send a frame, the next data frame gets created and encoded. Then the Tx is turned on and bits start coming out. When the encoder is ready for the next frame, we don't send anymore and the encoder is fed fill characters. Since we know that the interleaver is still full, a timer is started to clear the interleaver. After the interleave is cleared, the Tx can be turned off. So, the actual Tx ON time depends upon the size of the frame but it is always ON at least ~30 seconds to have time to finish the voice announcements or SSTV on the FM downlink. This worked flawlessly in lab testing of the satellite including tests with significant fading of the BPSK link. 73, Tony AA2TX --- At 06:21 AM 4/12/2011, Phil Karn wrote: >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? > > > > _______________________________________________ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
