[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Fade remover

Jens wrote:

> Actually repetative coding is a very inefficient type of ECC. It is equivalent
> to just reducing the symbol rate. I.e. repeating every block 3 times would be
> equivalent to reducing the bitrate to 400/3=133.3 bps and thus increasing the
> symbol length to 7.5 ms. It does not produce any major gain since the
> constraint length of this code is 1, i.e. we do not implement a state machine
> at all.
> The only "effectiveness" lies in the fact that deep fades can be compensated
> for due to the form of interleaving introduced by repeating blockwise.

Rick (W2GPS) started this thread based on some discussions we had over the past
couple of weeks -- let me give a little more insight into the reasons I made the

First -- the problem that I was trying to suggest a simple solution to is this:
The situation now is that when AO-40 is not at perigee (i.e. between MA =30 and
MA=220) the EFFECTIVE telemetry rate is ZERO.
I believe that the only data being acquired now is from the 13M dish in Annapolis.

There are several compounded reasons for the poor data yield: The spacecraft
orientation is such the the medium-gain S-band antenna is pointed away from the
earth, which necessitates the copying of data from the antenna's sidelobes. This
is compounded by the satellite's high spin rate that causes an antenna to wipe out
the downlink signal every 3+ seconds, which causes the PSK demod to lose lock. And
all this happens during the time when 1/r^2 path losses make the intrinsic signal
be weak.

If the spin rate couple be slowed by a factor ~5, then some complete frames (sync
vector+512 bytes of data+CRC) would be heard between fades. But, alas, the news
from DJ4ZC is that for a few months (until the sun sensor can again see the sun),
the lack of attitude data precludes using the magentorquer to slow the spin rate
and re-orient the spacecraft.

The issue that Rick (W2GPS), Bob (WB4APR) and others are trying to wrestle with is
based on the presumption that it is good thing to acquire some telemetry during
the apogee portion where the current effective bit rate is ZERO. If there is no
need for such data, then there is no reason to try to effect a solution.

Since AO-40 has been wounded, there is an understandable desire to not screw up
the possibility of recovering a part of the mission -- this leads the spacecraft
engineering team to be extremely conservative. AO-40 is flying the same COSMAC
1802 IHU and IPS threaded interpretive software  that was on AO-10 21 years ago
and which Karl was using on German trains in the late 70's because it works and it
is very robust. It was chosen for AO-40 under the premise "It ain't broke -- don't
fix it!"

Back many years ago (in the Phase-3A and Oscar-10 era) I had a role in the IHU/IPS
and Ground Command group. I recall how deeply embedded the in architecture the
Sync Vector+512 data bytes is. I'm no longer in the decision loop, but I am quite
sure that any suggestion that a major change in the code would be rejected. Thus
the fact that you have shown us some simple C code is probably irrelevant. These
comments also apply to the code that runs on the ground at the command stations --
they should not make any changes from the system they are using that finally
(since ZL1AOX regained control on Christmas Day) is providing minimal
command/control of the ailing spacecraft.

All these factors led me to suggest a (less than optimum but MUCH better than what
exists now) scheme that would require minimal changes to the flight software and
which I believe meets the needs. For the period when 30 < MA < 220 when all the
"bad" problems happen, reduce the effective bit rate by a factor of N (My guess is
that the optimum N is probably 3) by sending each 512 byte block N times.

On at least one of the N transmissions, the sync vector can be detected and a
partial frame can be decoded. From this the phase (with respect to the decoder's
clock) of the 400 b/s clock can be determined and the relative position of all the
~1600 bits of data+sync vector+CRC can be assigned. Portions where the the data is
obviously good can be extracted immediately, while the "fuzzy" bits can be sorted
out between the redundant frames on the basis of majority vote plus a check to see
what decision matches the CRC. This type of soft decision is similar to a Viterbi
decoder, even though the way that the redundancy has been added is  far less than

Since each of the N blocks is identical, all the existing satellite data
acquisition schemes continue to work, albeit with fewer effective frames. I
perceive that this is very important to the AO-40 command and engineering team.

Of course, we could declare that apogee data is not needed and simply do nothing!

73, Tom

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org