AMSAT-NA Digital Communications with Phase 3D

From Higher Intellect Documents
Jump to navigation Jump to search
                 AMSAT-NA Digital Communications with Phase 3D
   Originally published in QEX, The ARRL Experimenter's Exchange,
   February 1995.
   by Harold E. Price, NK6K
   The 400 kg Phase 3D satellite will have up to 250 watts output PEP, or
   about 60 watts continuous. Of that 60, the digital transponder (called
   RUDAK-U) will have about 20 watts allocated to it. The digital RF
   inputs and output come and go through an 10.7 MHz IF matrix, giving us
   access to a variety of uplink and downlink frequencies. The actual
   frequency bands are in Table 1.
   P3D will be flying a plethora of DSP-based modems. While the Surrey
   Satellite Technology UoSATs were the first to fly DSP modems on
   amateur spacecraft, P3D will be flying several, eight modulators and
   eight demodulators. The modems can appear anywhere within the digital
   sub bands described in Table 1.
   Most of the information below comes from the RUDAK-U project manager
   and lead hardware designer, Lyle Johnson, WA7GXD. The design is near
   final, but still subject to change. The basic configuration of the
   digital section is shown in Figure 1. There are two CPUs, a V53 and an
   80386. Each will have 16 MB of EDAC protected program and file storage
   space. Each processor has a connection to the payloads, via serial
   port, the one Mbit CAN-bus, or both. Each processor has its own set of
   "low" speed DSP-based modems (up to 56 kb or so). The processors share
   a single 256 kb modem.
   The two main processors are reloadable from the ground or each other.
   The DSP modems and payloads are reloadable from the ground via the
   main processor's on-board storage. The processors/DSP modem complex
   has 18 programmable processors.
   The 9600 baud modems are hardwired, and will be used for the initial
   loading and as backup to the DSP modems. They will be on fixed
   frequencies in the digital sub band. At least one of the frequencies
   will not be published, to provide a contention-free command and
   loading channel.
   The DSP modulators and demodulators use the ADSP2171 CPU. Each
   modulator and demodulator chain has a separate processor, allowing the
   full power of the DSP chip to be used for a single half duplex link.
   This will allow high baud rates, up to 56 kb, or very heavily coded
   low baud rates. Each DSP has 10k bytes of internal, non-EDAC protected
   memory. The DSPs will perform an internal CRC on program memory every
   second and report back to the main processor, which will reboot the
   DSP on bad CRC or timeout.
   A demodulator is fed from a high speed video ADC. Though each
   demodulator could use its own ADC, each is seeing the same IF and
   could share an ADC with one or more other demodulators. The decision,
   as always, is one of redundancy versus complexity and as not yet been
   made. Each demodulator uses its own HSP50016 Digital Down Converter
   (DDC) to convert the digitized 10.7 MHz IF to a frequency range more
   suitable for digital processing.[1] This also allows the uplink
   frequency to be anywhere in the passband, under software control.
   Likewise, the modulators use the AD7008 Direct Digital Synthesizer
   (DDS) to generate 10.7 MHz IF. This allows the modulators to also
   appear anywhere in the passband, under software control. The DDC and
   DDS allow the processor to specify a phase increment to an internally
   generated sine wave. The DDS also allows an amplitude to be specified.
   Since the DSP need not generate each point on the sine wave, the input
   and output frequencies can be much higher than the DSP chip alone
   could use.
   The DDS and DDC can be used to allow each ADSP2171 to process more
   than one low bit rate signal at a time, giving us more than 16
   uplinks, perhaps as many as 32 or 48 low bit rate uplinks. What could
   we do with such a thing? Why, that's the fun part, of course. Readers
   are invited to send in application ideas for all this horsepower.
   Before we get too carried away with thoughts of competing with
   Qualcomm and Orbcomm, let's review the link budget.

   The above is an acronym for "There ain't no such thing as a free
   lunch," a phrase I was first exposed to as a child in Robert
   Heinlein's "The Moon is a Harsh Mistress", and which I've encountered
   in real life ever since. The P3D orbit (43,000 km) has a few
   advantages over the Low Earth Orbit (800-1300 km) spacecraft digital
   users are used to. The spacecraft is much further away, meaning it
   moves more slowly and is visible for longer periods of time. It is
   also larger, meaning it can generate much more power, for louder
   Here is the TANSTAAFL part.
   Since P3D is much farther away than a LEO satellite like KO-23, the
   path loss is also much greater. The increased path loss, in fact, just
   about wipes out the advantage of the higher power. For example,
   consider the case of a typical ground user of the 9600 UoSAT
   spacecraft, UO-22, KO-23, and KO-25. Most of them have what is called
   an "Oscar 10" class station, meaning tracking antennas with about 10
   dB gain, and 10 to 100 watts of uplink power. For the LEO satellites,
   with about two watts on the downlink, this gives plenty of link
   For P3D, a similar amount of downlink power results in -0.1 dB of
   margin. We have a rule of thumb in the amateur satellite world that
   says the link margin on paper needs to be about 10 dB to give adequate
   performance at a typical user station. This 10 dB is usually labeled
   "implementation loss", and in my case, equates to the inability to
   correctly place an N-type connector on a piece of coax. Some link
   margins for P3D, and the data you need to compute your own, are in
   Table 2.
   I want to be very clear on this. Much of the PR the P3D campaign sends
   out, and I'm guilty as well, has been talking about 250 watt
   transmitters and much improved link performance for current users. The
   250 watt figure and the improvements are from the point of view of
   current AO-10 and AO-13 voice users, not the current LEO 9600 baud
   data users.
   Still, the goal of the RUDAK-U module is to service the current
   digital satellite user community. To do this, we'll need to assign a
   substantial amount of our downlink power budget to a single 9600 baud
   downlink in the 70 cm band. This leaves us with the challenge of
   finding interesting applications for lower power, but presumably more
   heavily DSP-processed modulation schemes. We'll need matching DSP
   modems on the ground as well. In fact, the P3D project could well
   exceed the current amateur capacity to generate modem software.
   There are other factors to keep in mind. RUDAK can transmit on more
   than one downlink band at a time. For example, we expect the
   spacecraft will often be in a mode allowing both the 435 MHz and the
   2400 MHz downlink to be used. While we are servicing old-style users
   on 435 at 9600 baud, we could be handling gateways with big antennas
   and higher data rates at 2400 MHz. Back in the TANSTAAFL category,
   while each user will have a longer access time, several hours instead
   of ten minutes per pass; more users can see the satellite at the same
   time. Will this lead to more contention, or will the long access times
   lead to less contention, since users aren't all trying to download in
   the same ten minute interval.
   All in all, we believe that we can provide access to P3D from current
   UoSAT 9600 baud FSK class stations. We may also provide access to
   Microsat 1200 baud PSK users. We can also, simultaneously on the same
   or other bands, provide access with new modulation schemes and new
   protocols. There will be fun for protocol developers and well as
   software modem designers on this mission.

   [1] The DDC has been mentioned previously in QEX, see Anderson, P. T.,
   "A Simple SSB Receiver Using a Digital Down Converter", QEX, March
   1994, for an overview.
   Some photos of the RUDAK design team are available.
   Original article by Harold E. Price, NK6K ([email protected]), published
   in QEX, The ARRL Experimenter's Exchange, February 1995. Hypertext
   conversion by and feedback to KB5MU.