1. Home
  2. Embedded Programming
  3. FEC - Forward Error Correction on a PIC?
  4. Page 2

FEC - Forward Error Correction on a PIC?

I think that you are trying to solve the wrong sort of problem.

The first thing is to make a good physical connection between the end points and my guess is that after that there is no need for any elaborate FEC systems. Some CRC may be needed to detect some random errors perhaps once a day or once a week.

The RS-232 standard was originally designed for low speed connections between a computer and a modem in the same room. Using it for long distance or high speed connections is just asking for troubles.

One of the worst things about RS-232 is that it is unbalanced (i.e. the signal is referenced to signal ground) but if there is a galvanic connection between the ends and due to quite large ground potential differences between the ends, a large ground loop current may flow in the signal ground, causing all kinds of troubles, especially, if the link ends are in different buildings.

One way around this is using optoisolators at least at one end. This will break the ground loop current.

However, if optoisolation is required and the speeds are quite low, as in this case, it would be even simpler to use the traditional 20 mA current loop system. I have used such systems at 9600 bit/s in a system with slip rings and with 220 V 10 A mains in adjacent rings. This required some hacking in the protocol retransmission system to avoid backlogs when one data transmission direction was temporarily off due to dirty rings and some arching in the mains rings. Normally

20 mA systems work very well in less demanding applications.

A more modern system is to use the differential RS-422 connection,which works reliably even on high speeds, but again, galvanic isolation is preferred and thus, you have to be careful about cable shield grounding (usually only at one end).

With speeds as low as 1200 bit/s you should be able to communicate for a kilometer or more.

It is quite hard for me to think about a situation in a wired slow speed connection in which FEC is needed.

The situation is radically different if a radio link is involved, in which case some interleaving and FEC is justified in most cases, but I haven't seen any references to radio links in this thread.

Paul

Reply to
Paul Keinanen
Loading thread data ...

I am so sorry to have not mentioned this earlier. It is indeed for use over a radio.

I have made a modem which takes rs232, converts it to analogue tones and squirts it in to a transmitter. "jetmarc" has hit the nail on the head. I loose only the bit here or there but the use of start & stop bits leaves me open to difficulty. That is why I would like to convert the framed asynchronous data with its vulnerabilities to a synchronous one without the start & stop bits. Once I have my hands on a continuous bitstream I can add fec easily (I guess). It also has the added benefit of removing the 20% of my air time that is taken up with start & stop bits.

Reply to
MarkyC

I don't suppose you would share?

Marky C

Reply to
MarkyC

Yes indeed, since quite a few people would have been able to pinpoint the problems with asynchronous characters immediately.

In radio systems, the bandwidth is always limited and thus the rise and fall times are quite long. With some noise added to the signal and a level sensitive triggering will make detecting the start bit timing quite vulnerable and the sampling times for the rest of the bits can be quite far away from the nominal point, at which point the slope to the next state might have already started.

A suitable preamble in front of a frame can be used in obtain exact bit timing, since the random noise errors can be averaged out during the preamble, thus the sampling times of the actual data bits hit close to the centre of bit, reducing the risk for bit errors.

Radio amateurs have used the AX.25 protocol in packet radio for two decades. The protocol is a variant of the SDLC/HDLC protocol with start/end flags (7E) and bit stuffing to avoid the flag sequence in actual data.

Quite a few systems at 1200 bit/s have been implemented with bit banging in old PC:s running MS-DOS and controlling an external FSK modem chip. The Baycom implementation used the PC serial port control signal pins (e.g. RTS/CTS) and the PMP (Poor Man's Packet) the parallel port pins for reception and transmission. The source was available at least for the PMP implementation. The PIC should be able to handle the bit banging as well.

The AX.25 is just using the CRC and relies on retransmissions if errors occur. This might be sufficient in your case, especially if the errors are truly single bit errors, with at most a single bit error in each frame, this might even be correctable as described in this thread.

However, in radio communication, burst errors are more likely in ground based systems, taking out multiple adjacent bits. Simply adding FEC bits into the frame does not help, since too much related information is missing. The message needs to be interleaved all over the frame at transmission and if a burst error takes out some bits, after deinterleaving, the bit errors are converted to random bit errors all over the frame,which is then easily correctable using FEC.

The frame header, bit stuffing, preamble, CRC and possible FEC can easily consume any gain that you might get, so you would still be able to transfer only 120 net data bytes each second in the best case.

Paul

Reply to
Paul Keinanen

It's difficult to talk to you, given the email " snipped-for-privacy@a.a"

Reply to
jetmarc

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.