[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] lost bytes and reed-solomon

From: Rick Parrish
Subject: Re: [Discuss-gnuradio] lost bytes and reed-solomon
Date: Sat, 26 May 2007 13:39:58 -0500
User-agent: Thunderbird (Windows/20060909)

Brett L. Trotter wrote:
Got a few good replies on my question about lost bytes. I appreciate the
input, that sounds like it'll work great in conjunction with the error
correction then. I'm hoping to have that in place within the next couple
of hours and start testing.
Two words ... preambles and frame sync.

One thing to be aware of ... it is possible with most software PLLs ... under crummy signal conditions ... to drop single bits (but not whole bytes). If the PLL is completely out of phase from where the mid point(s) of the symbol stream are located ... it can correct by either speeding up or slowing down. Depending upon the previous state and symbol history up to that point ... it can have the effect of inserting an erroneous bit or dropping a bit from the stream.

Any frames of data where this occurs are very likely trashed and not recoverable. You'll want a mechanism to reliably detect the start of each frame. For fixed sized frames of "N" bits ... bits added or missing distory the bit count for one frame. If you assume the next "N" bits belong to the next frame ... the bits in the next frame will be shifted by one bit ... effectively trashing the follow-on frames too.

Most protocols use a fixed bit pattern ... a frame sync ... to mark the beginning of each frame. You'll lose some bandwidth ... but it makes the job of recovering from a lost frame much easier.

If your protocol calls for short bursts of data ... you may want to pad the start of each transmission with an alternating symbol pattern. This gives the software PLL time to synchronize at the symbol level and accept the real data that follows.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]