Mark Jordan wrote: > I have to decode a 100-bit serial data stream received via radio. > The original data is FEC encoded, but passes through a /XOR with > itself before going to the radio modulator. The /XOR is between the > current bit and the previous bit in the stream. > That /XOR at the transmitter seems to be stupid. A NRZI conversion > would do lots better there. Or a proper data scrambler, depending on what the intent is. Usually, long-distance communication systems (both wired and wireless) want to randomize the statistics of the data bits so that timing recovery is more reliable. There are commonly-used data scrambling circuits (anywhere from 2 to 16 bits long) used for this purpose. The corresponding descrambling logic at the receiver end has well-known characteristics with regard to error propogation, and the FEC algorithms are designed to take this into account. The /XOR gate basically produces a pulse whenever the input data changes state, so if a pulse is created or lost because of noise in the channel, bits from there to the end of the frame at the output of the decoder will be flipped. > So, I can decode the frame correctly at the receiver side, but when > an error occurs, just one wrong bit is sufficient to trash the whole > frame due to that /XOR at the transmitter. In case two bits are wrong, > the FEC sometimes can correct the error. > > As I'm not allowed to modify the transmitter side, I'm looking for a > clever way to decode such a frame. No, with such a terrible transmitter implementation, you'll have to do an exhaustive search in order to decode the frame. For each bit position in the frame, try flipping the bits from there to the end and see whether the FEC can make sense out of it. If not, try the next position. Obviously, you need to have an FEC implementation on the receive side that can handle up to 100x the bandwidth of the channel. That cheap /XOR gate is basically negating most of the benefit of all that expensive FEC logic at both ends of the link. You really need to argue strenuously for a change. If you can't delete the /XOR gate itself (is it embedded in the radio module?), perhaps you can insert some logic upstream of it to cancel out its effect. Your only other option is to hope that the frames are transmitted redundantly and that it's OK to simply drop the bad ones altogether. -- Dave Tweed -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.