What is the Symbol rate?
What does FEC mean?
Symbol rate
As you will see from the 'Add Channels' of the Digibox, there are two settings for the Symbol rate - 22 and 27.5. This is measured in Mbaud, megabaud, and represents 22,000,000 or 27,500,000 transitions per second. Effectively, this is a measure of
how 'fast' data is sent from the satellite to your Digibox.
To see this in comparison:
- 8 Kbit
- Econet - average speed. :-)
- 56 Kbit
- A standard 'fast' modern modem, you might be using this for dial-up access to the Internet.
- 64 Kbit
- ISDN (the 'fast digital' service before ADSL was invented)
- 512 Kbit
- Slow bargain-basement ADSL
- 600 Kbit
- The minimum sustained data rate required to burn a CD at '4X'.
- 2 Mbit
- Typical English non-city ADSL
- 16 Mbit
- Typical French non-city ADSL (my little local library, out "in the sticks", achieves this)
- 22 Mbit
- The slower symbol rate supported by the Digibox
- 27 Mbit
- The faster symbol rate supported by the Digibox
It might seem like the satellite service is over ten times faster than typical English broadband. In technicality this is true, however note that the satellite service may be delivering some eight television channels (with digital audio) and maybe a number of radio channels too. In comparison with wired systems, the French Wanadoo/Orange LiveBox includes support for the digital television service, but it requires around 6 Mbit of the available bandwidth, so you'd need 8 Mbit ADSL as a minimum.
Note also that for satellite reception there's a enormous amount of redundancy in the signal in order to provide effective error correction. It is not possible to say "hold up, I
missed that bit, send it again please" so the signal must be able to recover itself to a high degree.
FEC
This means 'Forward Error Correction'.
Many of you who have used modems will be used to ARQ. This system notices if the data is corrupt and requests a repeat transmission. Slightly more complex is the TCP/IP system. Have you ever noticed, during a download, that your modem was blinking away but the download percentage remained fixed a while and then shot up a few percent at one time? This is TCP in action. It asked for a repeat of a damaged chunk of data, but unlike some early download protocols, it would carry on going and fill in the hole when the resend arrives.
This, very obviously, requires a two-way link between yourself and whatever comms service you are connected to.
With satellite broadcasting, this is impractical. If frames hit the screen fifty times a second and one frame is missed, even with modems and stuff it would be difficult to request a resend of a damaged frame - you can't buffer too many else the lag wouldn't be acceptable, and you have to insert a 'missing' frame into the data stream.
But no, we are left with a one-way communication. Astra to you.
Or, to take a more extreme example, exploration satellites. If it takes, say, eight or so minutes to receive information then it is simply not possible to think of 'resend' requests. In some cases, like the Jupiter mission or comet chasers or even Huygens - the satellite may have been destroyed before its information reaches Earth.
It would seem like the easy answer is to transmit everything three times. Rather like an autopilot, it would work on a best of two system. This doesn't really help though as the reliability disappears as the conditions worsen. If two of the three pictures are corrupt, and one is perfect, our best of two approach would favour the corrupt picture!
What works out much better is to employ some clever system into the picture data itself. This would then not only tell us if something is corrupt, but in a number of cases we can work out from the corruption what the original data should have been. A simple form is seen in teletext where each line is ham coded. Unfortunately video frames are much more complicated than that, so demand a more complex system - such as Reed Solomon. Also, unlike teletext, there is no possibility of waiting for the frame to refresh. If it is missed, it is missed.
In addition, the correction system needs to be adaptive. Key frames and audio will need a higher lever of error protection than the fill-ins as they are more important.
All of this must be worked out and added to the signal in advance, hence Forward Error Correction.
I do not know what the 2/3, 3/4, and 5/6 settings relate to. Perhaps this is a 'type' of error correction; i.e. three bytes in = two bytes out; 4 = 3; 6 = 5? Something like that.
Copyright © 2006 Richard Murray