Symbol Synchronization for BPSK

Darrell wrote:

   ...

>   If not, maybe
> take a hybrid approach where if you fail to find frame sync you use
> "bot sync" (thanks for the phrase Jerry).

I like both your humor and the attribution. I meant, of course, "bit 
sync". If you've seen one vowel, you've seen them all.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Darrell,

Thanks for the clarification. Based on Vladamir's suggestion I did try
zero crossing for bit synchro. It resulted in the same performance as
current method with my lab signal. It did worse with the real signal -
which leads me to believe that there is some inter-symbol phase jitter that
my loop must not be able to track (not present in my test signal). 

The baud rate is 1200 symbols/sec. The frame data (except UW) was
transmitted using first a scrambler and then 1/2 rate conventional coded.
So there should be plenty of transitions for bit synchronization.

As it stands now, I get perfect decode with my lab signal, which includes
frequency variation (including rate) and AWGN but not independent phase
jitter. The real signal is apparently more challenging in that it may
contain some phase jitter that either impacts my costa loop or bit
synchronization. The symptom appears as an extra one or zero in the bit
stream in several predictable locations - that is, the disruptions are
always in the same exact place. 

thanks,

Joe

>Darrell wrote:
>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

On May 20, 10:59&#4294967295;am, "rfnoise" <rfno...@gmail.com> wrote:
> Darrell,
>
> Thanks for the clarification. Based on Vladamir's suggestion I did try
> zero crossing for bit synchro. It resulted in the same performance as
> current method with my lab signal. It did worse with the real signal -
> which leads me to believe that there is some inter-symbol phase jitter that
> my loop must not be able to track (not present in my test signal).
>
> The baud rate is 1200 symbols/sec. The frame data (except UW) was
> transmitted using first a scrambler and then 1/2 rate conventional coded.
> So there should be plenty of transitions for bit synchronization.
>
> As it stands now, I get perfect decode with my lab signal, which includes
> frequency variation (including rate) and AWGN but not independent phase
> jitter. The real signal is apparently more challenging in that it may
> contain some phase jitter that either impacts my costa loop or bit
> synchronization. The symptom appears as an extra one or zero in the bit
> stream in several predictable locations - that is, the disruptions are
> always in the same exact place.
>
> thanks,
>
> Joe
>

Extra or missing bits can be explained by an offset in the transmit
and receive clocks. Your bitsync must be designed to handle the offset
over the packet duration. A typical solution would involve a second
order PLL.

You might consider performing a fine-grained resampling of your "lab
signal" to mimic the expected PPM difference between the real
transmitter and receiver clocks. That might shed some light on the
problem.

John

I don't have much experience with bit syncing, but generally if you
don't correct for reference mismatch between the transmitter and
reciever there is a period of time where you are sampling well off the
symbol center (in the middle of which you'll be sampling between
symbols) and you get multiple of bit errors (as well as one extra or
one fewer bit).  So if you just see one extra ones or zero inserted
into your recovered data, but all the other bits are right thats a
puzzler (to me at least).

Anyway, you can find an olide (but goodie) clock recovery algorithm in
E.A. Lee and D.G. Messerschmitt, Digital Communication, Kluwer, 1988,
pp571-574.  I'm guessing that's what John has in mind by a second
order PLL, if you don't have a reference for it google "clock recovery
stochastic gradient" and things should pop up.

Darrell

Thanks for all the feedback. I think I need to look at non-data aided
techniques. The UW that I have for frame sync cannot be used for symbol
sync because it is spread out over the entire frame (interleaved). 

It would seem like a practical approach would be to implement a simple
early/late gate loop. I am researching this area now.

thanks,

Joe