ad: SDRKits-1

Forward Error Correction

Discussion in 'Ham Radio Discussions' started by KX4Z, Jul 11, 2019.

ad: L-HROutlet
ad: l-rl
ad: Left-2
ad: Subscribe
ad: L-MFJ
ad: abrind-2
ad: Left-3
  1. KT1F

    KT1F Ham Member QRZ Page

    Of course. You don't need to understand any of the details to know that there's no magic way to send something over a less than perfect one way radio channel and guarantee that it will be received completely and accurately.
  2. KX4Z

    KX4Z Ham Member QRZ Page

    Wow -- as much as 100% overhead compared to the real signal if you cannot ask for resends!!

    KV6O points out it is completely necessary to have the ability to get resends, if you want to really get the message -- FEC helps, but ultimately ends up telling you that you did/didn't -- and can't fix it if you didn't.

    KT1F goes so far as to say it is basically OBVIOUS that you prefer the ability to get resends.....

    So that is helpful. I thought some people felt that ARQ (or the ability to get resends, fills, etc., as hams have done since the beginning of radio) was superfluous -- unnecessary -- in order to be certain of reception, because FEC would solve that problem....but it looks like there hasn't been a single person so far making that argument. Everyone seems to explain to me that FEC is extremely useful (although it increases the overhead, as much as to 100% of the message content)....but can't solve the whole problem.
  3. W6RZ

    W6RZ Premium Subscriber QRZ Page

    Actually, you can have more than 100% overhead. 1/4 and 1/5 rates are used for mobile satellite links.

    Here's a video of FEC in action. It's a DVB-S2X transmitter connected to a receiver. The transmitter is an SDR controlled with GNU Radio and the receiver is a commercial PCI board. As I reduce the transmit power, you can see the noise in the receiver constellation increase. Even when the constellation is unrecognizable, there are zero errors (until it gets below 8.3 dB of C/N).

    The FEC rate was 1/2 (90/180 LDPC code) with a resulting bitrate of 9.63 Mbps in a 6 MHz wide signal. Modulation is 8+8APSK.
  4. SM0AOM

    SM0AOM Ham Member QRZ Page

    What is discussed here is a classic problem in communications theory, what to do if your transmission channel is time-variable.

    One approach is to use a parity code that contains more information bits than necessary, and to replace missing information with what can be assembled from the extra bits.

    The other way is to send the data more than once, either at different times or on different frequencies, and to use a mechanism to discard the data which has been corrupted.

    The HF ionospheric channel is especially vulnerable to time variations, which either can be slow "flat fading", frequency and time dependent "selective fading" and finally fast "dispersion" or "flutter".

    A system designer that have to deal with especially the NVIS ionospheric channel need to have a lot of different "tricks" in the toolbox. One is time-diversity, another is frequency diversity or "narrow-band spread spectrum", another adaptive equalisers and adaptive data rates.

    Most designers use a mixture of these tools to maximise throughput and minimise error probability for a given channel propagation and interference profile.

    Early implementations that relied on quite primitive "block codes" had a non-zero residual error probability, which is caused by the inability of a simple parity code to detect multiple bit errors that change one character into another valid character.

    At very high bit error rates,above about 30 %, the risk for having one or more undetected incorrect characters in the CCIR 476 21 bit long block is about (34/128)^3 or 0.019. However, such a bad link would be unusable for traffic, as it would have a very hard time to synchronise.

    Protocols using CRC instead of simple parity codes have much lower undetected error rates.

    But in the end, no FEC system can replace a non-existent transmission channel.

    KX4O likes this.
  5. AG6QR

    AG6QR Premium Subscriber QRZ Page

    That's also true of a two way channel, especially if you add the constraint that you would like to have the message transmitted in a finite amount of time, which is usually the case in real world situations. (If you're willing to spend infinite time, then all those checksums and signature algorithms that have vanishingly low probability of failure will fail while you're waiting so long.)

    Both ARQ and FEC are techniques for spending more time and/or bandwidth to enhance reliability. Both are useful. Neither offers guarantees of accurate message delivery within a constrained time.
    W0PV likes this.
  6. KX4Z

    KX4Z Ham Member QRZ Page

    Oh you are SO RIGHT!!! I have sat there trying to get something through -- and the same thing happens whether digital or voice or cw --- and there are obviously times when you just aren't going to least that day.

    But it seems to sure help to have a wide array of tricks up your sleeve to throw at the problem....

    Thank you folks for your commentary and wise advice!!!! I wanted to be sure that I wasn't missing something. I have no idea why anyone would not realize that hobbling communications by not using various of these solutions is counter-productive.

  7. AI3V

    AI3V Ham Member QRZ Page

    Keep in mind that was just for the satellite link, the customer was free to add his own fec and or handshaking.

    Also understand we guaranteed a certain average level of service, which averaged out to just a few errors a day, (99.999 reliability over the course of a year) but as you posted we were not perfect and it caused, from time to time, some issues between us and our customers.

    One that I remember was NASA, they wanted zero errors over a 24 hour period.

    One can want anything....

  8. KT1F

    KT1F Ham Member QRZ Page

    This is true of course. I'm not sure if ARQ receivers typically send acknowledgements or only transmit if they need a repeat but if they send acknowledgements then I guess one big difference is that the sender knows whether or not it was successfully received.

    I guess FEC is somewhat similar to the UDP network protocol and ARQ is more like TCP.
    Last edited: Jul 12, 2019
  9. KX4O

    KX4O Ham Member QRZ Page

    I would think more like FEC (or CRC or both) is somewhat similar to UDP and FEC (or CRC or both)+ARQ is somewhat like TCP.
  10. AG6QR

    AG6QR Premium Subscriber QRZ Page

    I was going to tell a joke about UDP but I decided not to. I wasn't sure everyone would get it.
    K2CAJ and KV6O like this.

Share This Page