SEDSAT-2 Communications Design Notes 20080425

From SEDSWiki

Jump to: navigation, search

Contents

Full-duplex comms over a half-duplex channel

Two way communication over a half-duplex channel requires a multiple-access scheme: FDMA or TDMA

  • FDMA: frequency division, different transmitters use different frequencies so that they can both transmit on the channel without interfering with each other. Most (all?) handheld transceivers don't support this kind of operation.
  • TDMA: time division, different transmitters transmit in different periods of time. The only remaining option for SEDSAT-2.

TDMA scheme

TDMA requires some system to co-ordinate when the satellite can transmit, and when it is the ground stations turn to transmit, making sure the two don't try and transmit at the same time. Many implementations of TDMA use complex clock-synchronisation systems to synchronise the clocks on the two transmitters, and then defines time periods (with millisecond resolution) during which each transmitter is allowed to transmit. Keeping the clocks synchronised is hard though.

A simpler way of using TDMA is to make it so that the ground station tells the satellite when to transmit. For example, the ground station tells the satellite to "transmit one frame". The Ground station then immediately switches into receive-mode, and the satellite starts transmitting the one frame, and ground receives it.

The ground station can still do error detection etc... and it can ask for retransmission of frames, providing the frames are in the satellite buffer. So we still need the sliding window protocol, but now we use the ground station to determine when we transmit, whereas in the previous system (with seperate uplink and downlink frequencies, ie. FDMA), the satellite can transmit whenever it likes because the ground station was assumed to always be listening.

However, we loose the ability to broadcast telemetry periodically with this approach, as we rely on the ground station to initiate a transmission (to get telemetry information, the ground station would have to send a "send telmetry packet" command to the satellite). But this might not be a problem, as broadcasting isn't allowed on the amateur bands, so we may have been breaking the amateur license if we did broadcast telemetry information. But it is a fine line between beacons (which need to be broadcast by definition, and which are allowed), and periodic telemetry broadcast, so maybe we should investigate this legal aspect of things a bit more, just to make sure we know where we are with it.

Synchronisation

How does the satellite (and ground) synchronise together at the start of a transmitted frame?

Usually a "preamble" is used, which is just a bunch of alternating 1's and 0's. When the preamble starts, the Tx and the Rx are out of sync and so the Rx can not correctly determine what is a 1 and what is a 0, because it doesn't know when it should "look" at the transmitted data. But the preamble can be used to synchronize the receiver to the transmitter, so that by the end of the preamble, the two are synchronised and data transmission can take place. At the end of the preamble, a frame-start code is sent, which tells the receiver that everything after the frame-start code, until the frame-stop code, is data.

But what if there are some bit errors during the preamble, or during the frame start? That may mess the system up. The solution (I think) is that the way we code the preamble should be much simpler than the one for data. (I need to check this, I'm not entirely sure about it.)

For example, we may want to transmit data at 9600bps with an error rate of 1e-3 errors/bit (ie. 1 error in 1000 bits). This may (as an example) require a SNR of 20dB if we use PSK. So we design our system for a 20dB SNR, but then we decide to only transmit the preamble at 1000bps. At 1000bps we might (for example) only need 3dB SNR to achieve a error rate of 1e-3, so as we have a 20dB SNR we will get an error rate of 1e-6. ie. the preamble will hardly every have an error in it. To understand this fully, we need a channel model, and that will let us run some simulations to see how the system actually performs.

Doppler shift

Once we have used our preamble to synchronise the transmitter and receiver, we still have doppler shift in the signal due to motion of the satellite. So the frequency of the input data will change slightly. We need to take data in asynchronously and output it synchronously, eg a FIFO buffer. Maybe we need to do more than this to compensate for doppler shift, I'm not sure yet.


Comments from discussion with Lavina

In discussing this with Lavina, she had some good comments:

Personal tools