FPGA Central

Hi,

I have setup a simulation of an interpolation-based timing recovery
loop with Gardner's 2 s/s error detector. The loop seems to work fine,
but I am stuck with this question:

Out of the two samples produced from the interpolator, how do we know
which one is the correct one ? Basically, the TED, which is given by:

e = (y(n) - y(n-2))*y(n-1)

would produce zero error on both the sample points within a symbol
(under locked condition). Do we need to use any outside information
(such as sync/FEC lock) to determine the correct symbol location ?

Thanks,
Vijay.

On May 5, 5:31 pm, BERT <callm...@gmail.com> wrote:
> Hi,
>
> I have setup a simulation of an interpolation-based timing recovery
> loop with Gardner's 2 s/s error detector. The loop seems to work fine,
> but I am stuck with this question:
>
> Out of the two samples produced from the interpolator, how do we know
> which one is the correct one ? Basically, the TED, which is given by:
>
> e = (y(n) - y(n-2))*y(n-1)
>
> would produce zero error on both the sample points within a symbol
> (under locked condition). Do we need to use any outside information
> (such as sync/FEC lock) to determine the correct symbol location ?
>
> Thanks,
> Vijay.

OK. I just found a bug in my implementation. The TED operates every T
seconds instead of T/2 seconds (T = symbol rate). I noticed that if
the TED operates every T/2 seconds, the error output oscillates
between positive and negative values.

But, the original ambiguity still remains. If we sample exactly at the
zero crossings, then the TED would still produce a zero output. How to
resolve this ambiguity ?

Thanks,
Vijay.

BERT wrote:
> On May 5, 5:31 pm, BERT <callm...@gmail.com> wrote:
>> Hi,
>>
>> I have setup a simulation of an interpolation-based timing recovery
>> loop with Gardner's 2 s/s error detector. The loop seems to work fine,
>> but I am stuck with this question:
>>
>> Out of the two samples produced from the interpolator, how do we know
>> which one is the correct one ? Basically, the TED, which is given by:
>>
>> e = (y(n) - y(n-2))*y(n-1)
>>
>> would produce zero error on both the sample points within a symbol
>> (under locked condition). Do we need to use any outside information
>> (such as sync/FEC lock) to determine the correct symbol location ?
>>
>> Thanks,
>> Vijay.
>
> OK. I just found a bug in my implementation. The TED operates every T
> seconds instead of T/2 seconds (T = symbol rate). I noticed that if
> the TED operates every T/2 seconds, the error output oscillates
> between positive and negative values.
>
> But, the original ambiguity still remains. If we sample exactly at the
> zero crossings, then the TED would still produce a zero output. How to
> resolve this ambiguity ?

In order to resolve frequency F, you need to sample *faster* that 2F.

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

BERT wrote:
> On May 5, 5:31 pm, BERT <callm...@gmail.com> wrote:
>> Hi,
>>
>> I have setup a simulation of an interpolation-based timing recovery
>> loop with Gardner's 2 s/s error detector. The loop seems to work fine,
>> but I am stuck with this question:
>>
>> Out of the two samples produced from the interpolator, how do we know
>> which one is the correct one ? Basically, the TED, which is given by:
>>
>> e = (y(n) - y(n-2))*y(n-1)
>>
>> would produce zero error on both the sample points within a symbol
>> (under locked condition). Do we need to use any outside information
>> (such as sync/FEC lock) to determine the correct symbol location ?
>>
>> Thanks,
>> Vijay.
>
> OK. I just found a bug in my implementation. The TED operates every T
> seconds instead of T/2 seconds (T = symbol rate). I noticed that if
> the TED operates every T/2 seconds, the error output oscillates
> between positive and negative values.
>
> But, the original ambiguity still remains. If we sample exactly at the
> zero crossings, then the TED would still produce a zero output. How to
> resolve this ambiguity ?

You have three samples, spaced by half a symbol. You run this error
expression

e = (y(n) - y(n-2))*y(n-1)

Assuming the signal is PSK, you will get an "e" that is positive for
advance, negative for retard, and zero when spot on. The actual size of
"e" doesn't say a whole lot - only its sign conveys much meaning. You
generally need to filter "e" somewhat, do damp out noise effects. When
the filtered "e" settles around zero the y(n-1) sample should be mid way
between symbols, and y(n) and y(n-2) bang in the centre of symbols.

For QAM this will also work, as long as you filter "e" pretty hard, and
you have sufficient excess bandwidth in the signal. This isn't obvious,
as QAM transitions don't generally go through zero between symbols.
However, it statistically works out, so with heavy damping of "e" it
forms a usable metric for symbol timing error.

Regards,
Steve

>
> In order to resolve frequency F, you need to sample *faster* that 2F.
>
> Jerry

I agree. But, the Gardner TED is almost ubiquitously used, and it
seems to work fine ... So, I am wondering if I am missing something
here. Even my MATLAB simulations always converge on the correct
sampling instants and never converge on the zero-crossing points (even
with no additive noise). I will experiment with this a little bit
more ...

> Assuming the signal is PSK, you will get an "e" that is positive for
> advance, negative for retard, and zero when spot on. The actual size of
> "e" doesn't say a whole lot - only its sign conveys much meaning. You
> generally need to filter "e" somewhat, do damp out noise effects. When
> the filtered "e" settles around zero the y(n-1) sample should be mid way
> between symbols, and y(n) and y(n-2) bang in the centre of symbols.
>

Good point about "e". So, is it prudent to implement a "decision-
directed" approach to computing the error, where y(n) and y(n-2) are
now quantized to +/-1 (let's assume BPSK/QPSK) ? So, in the presence
of noise, it is impossible to converge on the ambiguous sampling
point, i.e., exactly at the zero-crossings (because it will produce a
random component that can filtered out by the loop filter).

On May 6, 12:17 pm, BERT <callm...@gmail.com> wrote:

>
> Good point about "e". So, is it prudent to implement a "decision-
> directed" approach to computing the error, where y(n) and y(n-2) are
> now quantized to +/-1 (let's assume BPSK/QPSK) ? So, in the presence
> of noise, it is impossible to converge on the ambiguous sampling
> point, i.e., exactly at the zero-crossings (because it will produce a
> random component that can filtered out by the loop filter).

By now you realize that the problem is solved in two steps:
1. How to extract a "error signal"
2. What to do with that "error signal", i.e. filtering.

For the first one, typically one considers the "S-curve", that is,
the map between actual error and estimated error.

Usually it's defined as the expected value of the timing error
detector for a given actual timing error, assuming unit amplitude.

For the second one, given the S-curve it's possible to do a
linearization of the problem, and use your usual analysis of
feedback filters.

So given the above, do you think that it's possible to get to
the ideal sampling instance?

Julius

On May 8, 12:42 am, julius <juli...@gmail.com> wrote:
> On May 6, 12:17 pm, BERT <callm...@gmail.com> wrote:
>
>
>
> > Good point about "e". So, is it prudent to implement a "decision-
> > directed" approach to computing the error, where y(n) and y(n-2) are
> > now quantized to +/-1 (let's assume BPSK/QPSK) ? So, in the presence
> > of noise, it is impossible to converge on the ambiguous sampling
> > point, i.e., exactly at the zero-crossings (because it will produce a
> > random component that can filtered out by the loop filter).
>
> By now you realize that the problem is solved in two steps:
> 1. How to extract a "error signal"
> 2. What to do with that "error signal", i.e. filtering.
>
> For the first one, typically one considers the "S-curve", that is,
> the map between actual error and estimated error.
>
> Usually it's defined as the expected value of the timing error
> detector for a given actual timing error, assuming unit amplitude.
>
> For the second one, given the S-curve it's possible to do a
> linearization of the problem, and use your usual analysis of
> feedback filters.
>
> So given the above, do you think that it's possible to get to
> the ideal sampling instance?
>
> Julius

Thanks for your response Julius. I have never heard of S-curves
before, but I think I understand your point. The "S-curve" plot for
the zero-crossing point would have a slope that is reverse from that
of the point where the matched filter output is maximum. Hence, if we
match the loop to track the ideal sampling point, this would make the
other sampling point kind of "unstable" - i.e., it is still possible
to stay locked at that point, but any small amount of noise/
interference would force it out of the locked state because of
positive feedback. So, did I get anywhere near the right explanation ?

On May 8, 4:09 pm, BERT <callm...@gmail.com> wrote:

> Thanks for your response Julius. I have never heard of S-curves
> before, but I think I understand your point. The "S-curve" plot for
> the zero-crossing point would have a slope that is reverse from that
> of the point where the matched filter output is maximum. Hence, if we
> match the loop to track the ideal sampling point, this would make the
> other sampling point kind of "unstable" - i.e., it is still possible
> to stay locked at that point, but any small amount of noise/
> interference would force it out of the locked state because of
> positive feedback. So, did I get anywhere near the right explanation ?

I think you're jumping a little bit ahead of yourself here!
The S-curve is simply a way to see how the actual timing error
maps to the output of a timing error detector/estimator.
Hopefully it at least tells you whether you need to delay
or advance your sampling instance.

So what you said about zero-crossing etc may be true for
certain timing error detectors, but is not necessarily a desirable
property. Think of what the ideal S-curve would look like:
I think I would want it to be a straight line through the origin,
so that my timing error detector will tell me exactly how
far I am from my ideal sampling time, at least subject to
a gain factor). In my opinion it is not so much the slope of
the S-curve as the actual value itself. Of course, no such
S-curve exists because the effect of delay on the observation
is not linear in general.

>From there one can assume small error and approximate the
S-curve as a line crossing the origin, with a given slope
that is usually called the "gain" of the timing error detector.

Now we have a linearized model, which is basically an IIR
filter. Then everything that you know about filters apply here:
notions of bandwidth, gain, stability, etc. Then from here you
can deduce whether it is possible to get what you want in
your previous question.

The above is pretty much the way that we can obtain a
rather simplified but insightful analysis of the performance of
timing synchronization systems. Of course, there's a whole
array of research work in coming up with more accurate
approximations by taking advantage of the structure of the
modulation scheme, etc.

Hope that helps.
Julius

On May 8, 4:42 pm, julius <juli...@gmail.com> wrote:

> Now we have a linearized model, which is basically an IIR
> filter. Then everything that you know about filters apply here:
> notions of bandwidth, gain, stability, etc. Then from here you
> can deduce whether it is possible to get what you want in
> your previous question.

Instead of IIR filter I should have used the term "linear
feedback control system", i.e. PID controllers.

Julius

On May 8, 5:42 pm, julius <juli...@gmail.com> wrote:
> On May 8, 4:09 pm, BERT <callm...@gmail.com> wrote:
>
> > Thanks for your response Julius. I have never heard of S-curves
> > before, but I think I understand your point. The "S-curve" plot for
> > the zero-crossing point would have a slope that is reverse from that
> > of the point where the matched filter output is maximum. Hence, if we
> > match the loop to track the ideal sampling point, this would make the
> > other sampling point kind of "unstable" - i.e., it is still possible
> > to stay locked at that point, but any small amount of noise/
> > interference would force it out of the locked state because of
> > positive feedback. So, did I get anywhere near the right explanation ?
>
> I think you're jumping a little bit ahead of yourself here!
> The S-curve is simply a way to see how the actual timing error
> maps to the output of a timing error detector/estimator.
> Hopefully it at least tells you whether you need to delay
> or advance your sampling instance.
>
> So what you said about zero-crossing etc may be true for
> certain timing error detectors, but is not necessarily a desirable
> property. Think of what the ideal S-curve would look like:
> I think I would want it to be a straight line through the origin,
> so that my timing error detector will tell me exactly how
> far I am from my ideal sampling time, at least subject to
> a gain factor). In my opinion it is not so much the slope of
> the S-curve as the actual value itself. Of course, no such
> S-curve exists because the effect of delay on the observation
> is not linear in general.
>
> >From there one can assume small error and approximate the
>
> S-curve as a line crossing the origin, with a given slope
> that is usually called the "gain" of the timing error detector.
>
> Now we have a linearized model, which is basically an IIR
> filter. Then everything that you know about filters apply here:
> notions of bandwidth, gain, stability, etc. Then from here you
> can deduce whether it is possible to get what you want in
> your previous question.
>
> The above is pretty much the way that we can obtain a
> rather simplified but insightful analysis of the performance of
> timing synchronization systems. Of course, there's a whole
> array of research work in coming up with more accurate
> approximations by taking advantage of the structure of the
> modulation scheme, etc.
>
> Hope that helps.
> Julius

Thanks Julius. Very interesting stuff !

I picked up this book yesterday from the library: "Digital
Communications Receivers", by H. Meyr et. al., - and it had a good
explanation how to generate a model of a timing loop that is similar
to the ones conventionally used for PLLs. I especially liked the way
he models the random nature of the input data stream as an "additive
noise" into the loop and derives the noise PSD for different TEDs ...
Interesting, indeed.

On May 9, 6:51 am, BERT <callm...@gmail.com> wrote:

> Thanks Julius. Very interesting stuff !
>
> I picked up this book yesterday from the library: "Digital
> Communications Receivers", by H. Meyr et. al., - and it had a good
> explanation how to generate a model of a timing loop that is similar
> to the ones conventionally used for PLLs. I especially liked the way
> he models the random nature of the input data stream as an "additive
> noise" into the loop and derives the noise PSD for different TEDs ...
> Interesting, indeed.

I'm glad to hear that you are really getting your feet wet in this
subject area! It is becoming an unappreciated art.

The Meyr book is excellent, and he is my hero for going all the
way from physics to stochastic processes to circuits.

Another one that I really enjoy is d'Andrea and Mengali's book,
which tends to explain things from an estimation theory (maximum
likelihood) perspective.

It's also interesting how the availability of high-speed, high-rate
quantizers and circuitry has changed the way people do timing
recovery these days, compared to when that book was written.
You can also compare between the first and second books on
the subject, written by Meyr and his colleagues.

Very few people understand the subject well, but every comm
system requires synchronization.

Hint, hint, for those who were complaining about job opportunities.

Julius

On 9 May 2007 05:01:23 -0700, julius <[email protected]> wrote:

>On May 9, 6:51 am, BERT <callm...@gmail.com> wrote:
>
>> Thanks Julius. Very interesting stuff !
>>
>> I picked up this book yesterday from the library: "Digital
>> Communications Receivers", by H. Meyr et. al., - and it had a good
>> explanation how to generate a model of a timing loop that is similar
>> to the ones conventionally used for PLLs. I especially liked the way
>> he models the random nature of the input data stream as an "additive
>> noise" into the loop and derives the noise PSD for different TEDs ...
>> Interesting, indeed.
>
>I'm glad to hear that you are really getting your feet wet in this
>subject area! It is becoming an unappreciated art.
>
>The Meyr book is excellent, and he is my hero for going all the
>way from physics to stochastic processes to circuits.
>
>Another one that I really enjoy is d'Andrea and Mengali's book,
>which tends to explain things from an estimation theory (maximum
>likelihood) perspective.
>
>It's also interesting how the availability of high-speed, high-rate
>quantizers and circuitry has changed the way people do timing
>recovery these days, compared to when that book was written.
>You can also compare between the first and second books on
>the subject, written by Meyr and his colleagues.
>
>Very few people understand the subject well, but every comm
>system requires synchronization.
>
>Hint, hint, for those who were complaining about job opportunities.
>
>Julius

Careful, I still need job security...

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

On May 9, 2:15 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:

> Careful, I still need job security...
>

Eric, it will be a long while before anybody can mount a serious
competition
to your magic!

Julius

>
> Very few people understand the subject well, but every comm
> system requires synchronization.
>

Well, except for the one where my wife reminds me of some chore or
home project I've been procrastinating on and I mumble "I'll get right
on that, thanks for reminding me" without really listening to what it
is.

Seriously, though. The combination of powerful FEC (Turbo, LDPC) and
burst-oriented comms creates a major synchronization challenge, and
the solutions are almost never "cookbook" in nature like an FEC
decoder.

John