Low SNR BPSK clock synch

All,

I'm curious about practical implementations of very low SNR clock
synchronization for non-burst coherent BPSK. I have been doing some
work in this area, and have found that a nonlinearity, narrow BPF, and
2nd order transition tracking PLL works quite well to 20% SER and
beyond. Some of my colleagues don't believe it, pointing to papers that
claim MAP detectors fail well before that point. They claim that data
aided techniques using pilot symbols are the way to go.

Any comments are welcome. 

John

Geez, how low do you need to go?   Are you using some kind of
seriously low code rates or something?

Just using a second-order timing recovery loop with a well-known
timing phase detector and a reasonably narrow loop bandwidth will
track timing well below 0dB SNR.    Satellite systems have been doing
this for years.   I don't know what the deep space guys do, but it
might be insightful as well.

Using pilot symbols helps since it removes ambiguity, but it requires
adding the overhead for the pilots and then requires obtaining synch
with the pilots (i.e., locating them).   Both very doable if your
system allows such flexibility.



On 4 Mar 2005 18:01:35 -0800, "john" <johns@xetron.com> wrote:

>All,
>
>I'm curious about practical implementations of very low SNR clock
>synchronization for non-burst coherent BPSK. I have been doing some
>work in this area, and have found that a nonlinearity, narrow BPF, and
>2nd order transition tracking PLL works quite well to 20% SER and
>beyond. Some of my colleagues don't believe it, pointing to papers that
>claim MAP detectors fail well before that point. They claim that data
>aided techniques using pilot symbols are the way to go.
>
>Any comments are welcome. 
>
>John
>

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org

I can tolerate bit errors in this application (do not need perfect data
recovery), but loss of synch raises havoc. There is no coding
whatsoever.

Thanks,

John

Eric Jacobsen wrote:
> Geez, how low do you need to go?   Are you using some kind of
> seriously low code rates or something?
>
> Just using a second-order timing recovery loop with a well-known
> timing phase detector and a reasonably narrow loop bandwidth will
> track timing well below 0dB SNR.    Satellite systems have been doing
> this for years.   I don't know what the deep space guys do, but it
> might be insightful as well.
>
> Using pilot symbols helps since it removes ambiguity, but it requires
> adding the overhead for the pilots and then requires obtaining synch
> with the pilots (i.e., locating them).   Both very doable if your
> system allows such flexibility.
>
>
>
> On 4 Mar 2005 18:01:35 -0800, "john" <johns@xetron.com> wrote:
>
> >All,
> >
> >I'm curious about practical implementations of very low SNR clock
> >synchronization for non-burst coherent BPSK. I have been doing some
> >work in this area, and have found that a nonlinearity, narrow BPF,
and
> >2nd order transition tracking PLL works quite well to 20% SER and
> >beyond. Some of my colleagues don't believe it, pointing to papers
that
> >claim MAP detectors fail well before that point. They claim that
data
> >aided techniques using pilot symbols are the way to go.
> >
> >Any comments are welcome.
> >
> >John
> >
>
> Eric Jacobsen
> Minister of Algorithms, Intel Corp.
> My opinions may not be Intel's opinions.
> http://www.ericjacobsen.org

With no coding you won't be operating at very low SNRs in a relative
sense to coded systems.   A second-order tracking loop works great to
obtain and maintain timing synchronization even for systems coded at
low rates operating near threshold, so it should be relatively easy to
get such a system to work for your application.

This seems to be what you described although the nonlinearity followed
by BPF can be a fairly noisy phase detector I can see that it might
work well for your case.   There are better detectors in the
literature that operate reliably to far lower SNRs.

I don't know why your colleagues would think this wouldn't work, to my
knowledge it's how most low SNR continuous-stream demodulators are
implemented.

Cheers,

Eric

On 5 Mar 2005 12:13:47 -0800, "john" <johns@xetron.com> wrote:

>I can tolerate bit errors in this application (do not need perfect data
>recovery), but loss of synch raises havoc. There is no coding
>whatsoever.
>
>Thanks,
>
>John
>
>Eric Jacobsen wrote:
>> Geez, how low do you need to go?   Are you using some kind of
>> seriously low code rates or something?
>>
>> Just using a second-order timing recovery loop with a well-known
>> timing phase detector and a reasonably narrow loop bandwidth will
>> track timing well below 0dB SNR.    Satellite systems have been doing
>> this for years.   I don't know what the deep space guys do, but it
>> might be insightful as well.
>>
>> Using pilot symbols helps since it removes ambiguity, but it requires
>> adding the overhead for the pilots and then requires obtaining synch
>> with the pilots (i.e., locating them).   Both very doable if your
>> system allows such flexibility.
>>
>>
>>
>> On 4 Mar 2005 18:01:35 -0800, "john" <johns@xetron.com> wrote:
>>
>> >All,
>> >
>> >I'm curious about practical implementations of very low SNR clock
>> >synchronization for non-burst coherent BPSK. I have been doing some
>> >work in this area, and have found that a nonlinearity, narrow BPF,
>and
>> >2nd order transition tracking PLL works quite well to 20% SER and
>> >beyond. Some of my colleagues don't believe it, pointing to papers
>that
>> >claim MAP detectors fail well before that point. They claim that
>data
>> >aided techniques using pilot symbols are the way to go.
>> >
>> >Any comments are welcome.
>> >
>> >John
>> >
>>
>> Eric Jacobsen
>> Minister of Algorithms, Intel Corp.
>> My opinions may not be Intel's opinions.
>> http://www.ericjacobsen.org
>

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org