Hello All, I have a BPSK demodulator that uses a Costa's Loop for suppressed carrier recovery. That part seems to be working just fine - it's correcting both frequency and phase. For symbol synchronization I am planning on taking a very simplistic approach: Sum up the energy at each sample time, average it, and pick the sample time with the highest energy content - this will be the sample that hopefully corresponds to the middle of the symbol. Is this a reasonable approach? Is there a reason why I would need to implement something more complex? This seems to be working with my test generator but doesn't seem to work with the real BPSK signal, where I see an extra zero or one in very predictable locations. Any idea what might be happening? Also, for background, I have 10 samples per symbol available. thanks, Joe
Symbol Synchronization for BPSK
Started by ●May 19, 2009
Reply by ●May 19, 20092009-05-19
On May 19, 2:13�pm, "rfnoise" <rfno...@gmail.com> wrote:> Hello All, > > I have a BPSK demodulator that uses a Costa's Loop for suppressed carrier > recovery. That part seems to be working just fine - it's correcting both > frequency and phase. > > For symbol synchronization I am planning on taking a very simplistic > approach: > > Sum up the energy at each sample time, average it, and pick the sample > time with the highest energy content - this will be the sample that > hopefully corresponds to the middle of the symbol. > > Is this a reasonable approach? Is there a reason why I would need to > implement something more complex? > > This seems to be working with my test generator but doesn't seem to work > with the real BPSK signal, where I see an extra zero or one in very > predictable locations. Any idea what might be happening? > > Also, for background, I have 10 samples per symbol available. > > thanks, > > JoeSounds like you are doing what is called the "squaring timing recovery" method for estimating the correct symbol timing instance. This method yields a timing signal that has a lot of self-noise, so you will need a lot of filtering at the output to be able to contend with it. Do you have any filtering at all or are you just making your decision symbol-by-symbol? Let's worry about actually synchronizing after you know that you can generate a reliable symbol timing signal. Julius
Reply by ●May 19, 20092009-05-19
rfnoise wrote:> Hello All, > > I have a BPSK demodulator that uses a Costa's Loop for suppressed carrier^^^^^^^^^^^^ http://en.wikipedia.org/wiki/John_P._Costas> recovery. That part seems to be working just fine - it's correcting both > frequency and phase. > > For symbol synchronization I am planning on taking a very simplistic > approach: > > Sum up the energy at each sample time, average it, and pick the sample > time with the highest energy content - this will be the sample that > hopefully corresponds to the middle of the symbol.Maximums are less pronounced and more difficult to find then the zero crossings. If you are looking for something quick and dirty, check for the zero crossings in the demodulated signal and set the sampling points in 1/2 of the bit duration from there.> Is this a reasonable approach?That works if the SNR is high enough.> Is there a reason why I would need to > implement something more complex?That doesn't work for low SNR. Low = below 10dB or so.> This seems to be working with my test generator but doesn't seem to work > with the real BPSK signal, where I see an extra zero or one in very > predictable locations. Any idea what might be happening? > > Also, for background, I have 10 samples per symbol available.More then enough. Something like 4 samples per bit is sufficient. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●May 19, 20092009-05-19
On May 19, 2:13�pm, "rfnoise" <rfno...@gmail.com> wrote:> > Is this a reasonable approach? Is there a reason why I would need to > implement something more complex?Many protocols have a synchronization sequence you can use for symbol timing. What's your source? Darrell
Reply by ●May 19, 20092009-05-19
>On May 19, 2:13=A0pm, "rfnoise" <rfno...@gmail.com> wrote: > >Sounds like you are doing what is called the "squaring timing >recovery" method for estimating the correct symbol timing instance.Yes. Correct.>This method yields a timing signal that has a lot of self-noise, so >you >will need a lot of filtering at the output to be able to contend with >it. > >Do you have any filtering at all or are you just making your decision >symbol-by-symbol?Yes, I am applying a LP filter per sample. So, in 10 LP filters.>Let's worry about actually synchronizing after you know that you can >generate a reliable symbol timing signal. > >Julius >
Reply by ●May 19, 20092009-05-19
Vladimir,>> For symbol synchronization I am planning on taking a very simplistic >> approach: >> >> Sum up the energy at each sample time, average it, and pick the sample >> time with the highest energy content - this will be the sample that >> hopefully corresponds to the middle of the symbol. > >Maximums are less pronounced and more difficult to find then the zero >crossings. If you are looking for something quick and dirty, check for >the zero crossings in the demodulated signal and set the sampling points>in 1/2 of the bit duration from there.OK, I will give that a try.>> Is this a reasonable approach? > >That works if the SNR is high enough.Signal is about 5dB above noise.> >> Is there a reason why I would need to >> implement something more complex? > >That doesn't work for low SNR. Low = below 10dB or so.Ahh, so, an extra 0 or 1 in the bitstream would a sign of this? I am just trying to make sure that I am solving the correct problem. If I add AWGN to my test signal I get good decodes down to 0 dB - and when noise does cause problems it doesn't show up as a extra 0 or 1 in the bit stream. [snip]> >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.comthanks, Joe
Reply by ●May 19, 20092009-05-19
Darrell,>On May 19, 2:13=A0pm, "rfnoise" <rfno...@gmail.com> wrote: >> >> Is this a reasonable approach? Is there a reason why I would need to >> implement something more complex? > >Many protocols have a synchronization sequence you can use for symbol >timing. What's your source?I have 128 symbols of known unique word for frame synchronization. Are you suggesting use of the this for bit synchronization? The frame length is over 10,000 bits, not sure if synchronization will last that long.>Darrell
Reply by ●May 19, 20092009-05-19
rfnoise wrote:> Darrell, > >> On May 19, 2:13=A0pm, "rfnoise" <rfno...@gmail.com> wrote: >>> Is this a reasonable approach? Is there a reason why I would need to >>> implement something more complex? >> Many protocols have a synchronization sequence you can use for symbol >> timing. What's your source? > > I have 128 symbols of known unique word for frame synchronization. Are you > suggesting use of the this for bit synchronization? The frame length is > over 10,000 bits, not sure if synchronization will last that long.Ouch! Frame synch involves looking for a special sequence and slipping if it isn't found. Bot sync involves looking for transitions and constantly correcting the clock. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●May 19, 20092009-05-19
Jerry,>Jerry wrote: > >Ouch! Frame synch involves looking for a special sequence and slipping >if it isn't found. Bot sync involves looking for transitions and >constantly correcting the clock.Yes, I have frame synchronization all coded - My issue is that I am trying to determine why out of 10,000+ frame (interleaved) is shifted on 5 rows - an extra 0 or 1 is embedded in the bitstream in 5 places (same on every frame). It seems like it could be a symbol sync issue which is why I am asking about that.> >Jerry
Reply by ●May 20, 20092009-05-20
On May 19, 4:03�pm, "rfnoise" <rfno...@gmail.com> wrote:> > I have 128 symbols of known unique word for frame synchronization. Are you > suggesting use of the this for bit synchronization? The frame length is > over 10,000 bits, not sure if synchronization will last that long.I wouldn't worry too much about synchronization "lasting". What you want to do is extract initial parameters for things like phase/ frequency/timing/DC/etc. using the sync pattern, seed your tracking algorithms appropriately, then let it roll on the unknown data. The bigger problem is that if you fail to detect frame sync it is some time before you have another opportunity. If your sync detection is very robust (what's the baud rate?), you might be okay. If not, maybe take a hybrid approach where if you fail to find frame sync you use "bot sync" (thanks for the phrase Jerry). Darrell
