costas loop

Hi everyone,

I have a pair of signals sin/cos whose phase difference is linked to a 
mechanism's position that I need to measure in order to drive it 
following a preset trajectory. Errors from the position will tune the 
driver in order to minimize the deviation from the wanted trajectory.

We decided to lock onto the phase with a costas loop, but the two 
signals might not have the same amplitude due to a multitude of factors 
(relative difference can be assumed slowly varying with respect to the 
frequency of the signals).

The current algorithm normalize the two signals to get rid of the issue, 
but this step requires lots of resources in the FPGA we are using. To 
optimize the resource usage I wanted to propose a different approach.

Considering the two signals:

- A*sin(wt+f)
- B*cos(wt)

In order to feed the phase detectors of the costas loop with equal 
amplitude, we can think of using these signals instead:

- A*B*sin(wt+f)
- B*A*cos(wt)

In this way the two branches are 'balanced'. Now the problem is that the 
plant transfer function depends on the signal amplitude, which is not 
too good, therefore I'd like to avoid it. In order not to use another 
division (like in the normalization) we can 'limit' the effect of the 
amplitude simply dividing by a power of 2 (simple shift).

Does this sound completely nonsense? I've simulated this and it looks 
ok, but I must admit that I do not know if I overlooked something or if 
my simulation is simply misleading my understanding.

Any comment/suggestion is appreciated.

Al


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 17 Mar 2014 10:45:05 GMT, al.basili@gmail.com (alb) wrote:

>Hi everyone,
>
>I have a pair of signals sin/cos whose phase difference is linked to a 
>mechanism's position that I need to measure in order to drive it 
>following a preset trajectory. Errors from the position will tune the 
>driver in order to minimize the deviation from the wanted trajectory.
>
>We decided to lock onto the phase with a costas loop, but the two 
>signals might not have the same amplitude due to a multitude of factors 
>(relative difference can be assumed slowly varying with respect to the 
>frequency of the signals).
>
>The current algorithm normalize the two signals to get rid of the issue, 
>but this step requires lots of resources in the FPGA we are using. To 
>optimize the resource usage I wanted to propose a different approach.
>
>Considering the two signals:
>
>- A*sin(wt+f)
>- B*cos(wt)
>
>In order to feed the phase detectors of the costas loop with equal 
>amplitude, we can think of using these signals instead:
>
>- A*B*sin(wt+f)
>- B*A*cos(wt)
>
>In this way the two branches are 'balanced'. Now the problem is that the 
>plant transfer function depends on the signal amplitude, which is not 
>too good, therefore I'd like to avoid it. In order not to use another 
>division (like in the normalization) we can 'limit' the effect of the 
>amplitude simply dividing by a power of 2 (simple shift).
>
>Does this sound completely nonsense? I've simulated this and it looks 
>ok, but I must admit that I do not know if I overlooked something or if 
>my simulation is simply misleading my understanding.
>
>Any comment/suggestion is appreciated.
>
>Al

Is it possible to just hard-limit each signal and run a timer between
rising edges to determine the phase difference?   A little filtering
on the output of the timer can reduce jitter if tha's a problem.

>
>-- 
>A: Because it messes up the order in which people normally read text.
>Q: Why is top-posting such a bad thing?
>A: Top-posting.
>Q: What is the most annoying thing on usenet and in e-mail?

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

On Mon, 17 Mar 2014 16:08:57 +0000, Eric Jacobsen wrote:

> On 17 Mar 2014 10:45:05 GMT, al.basili@gmail.com (alb) wrote:
> 
>>Hi everyone,
>>
>>I have a pair of signals sin/cos whose phase difference is linked to a
>>mechanism's position that I need to measure in order to drive it
>>following a preset trajectory. Errors from the position will tune the
>>driver in order to minimize the deviation from the wanted trajectory.
>>
>>We decided to lock onto the phase with a costas loop, but the two
>>signals might not have the same amplitude due to a multitude of factors
>>(relative difference can be assumed slowly varying with respect to the
>>frequency of the signals).
>>
>>The current algorithm normalize the two signals to get rid of the issue,
>>but this step requires lots of resources in the FPGA we are using. To
>>optimize the resource usage I wanted to propose a different approach.
>>
>>Considering the two signals:
>>
>>- A*sin(wt+f)
>>- B*cos(wt)
>>
>>In order to feed the phase detectors of the costas loop with equal
>>amplitude, we can think of using these signals instead:
>>
>>- A*B*sin(wt+f)
>>- B*A*cos(wt)
>>
>>In this way the two branches are 'balanced'. Now the problem is that the
>>plant transfer function depends on the signal amplitude, which is not
>>too good, therefore I'd like to avoid it. In order not to use another
>>division (like in the normalization) we can 'limit' the effect of the
>>amplitude simply dividing by a power of 2 (simple shift).
>>
>>Does this sound completely nonsense? I've simulated this and it looks
>>ok, but I must admit that I do not know if I overlooked something or if
>>my simulation is simply misleading my understanding.
>>
>>Any comment/suggestion is appreciated.
>>
>>Al
> 
> Is it possible to just hard-limit each signal and run a timer between
> rising edges to determine the phase difference?   A little filtering on
> the output of the timer can reduce jitter if tha's a problem.

I missed the original post, so I'm mostly responding to the OP here.

I keep trying to fit your problem statement into a framework that matches 
what a Costas loop does, and I keep failing.

What in the world do you think a Costas loop is?

I normally do this sort of thing in software, which is a far better fit 
for it, but here's what I would probably do:

First, I'd name the signals:

x1 = A * sin(w + f)
x2 = B * cos(w)

Then, I'd make my own internal reference at the nominal frequency, in 
both inphase and quadrature.  This can be done with a lookup table with 
surprisingly few elements:

      [ cos (wn) ]
ref = [          ]
      [ sin (wn) ]

Then, for each cycle of the reference frequency (or perhaps multiple 
cycles, depending on my required sampling rates and on the closeness of 
the nominal frequency with the reference), I'd calculate:

y1 = sum ref * x1
y2 = sum ref * x2

(Note that these are vector quantities).

Now that I'm working at a much slower rate, I'd calculate

phase = atan2(y1_1 * y2_1 + y1_2 * y2_2, y1_2 * y2_1 - y1_1 * y2_2)

(Note, this is obvious if you take ref as e^(i * wn) instead of a vector, 
and take y1 and y2 as complex numbers.  But explaining it all takes too 
much time for free advise.)

Note that there's not a loop -- much less a Costas loop -- in sight.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hi Eric,
Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
> On 17 Mar 2014 10:45:05 GMT, al.basili@gmail.com (alb) wrote:
[]
>>I have a pair of signals sin/cos whose phase difference is linked to a 
>>mechanism's position that I need to measure in order to drive it 
>>following a preset trajectory. Errors from the position will tune the 
>>driver in order to minimize the deviation from the wanted trajectory.
[]
> 
> Is it possible to just hard-limit each signal and run a timer between
> rising edges to determine the phase difference?   A little filtering
> on the output of the timer can reduce jitter if tha's a problem.

Uhm, I guess the problem might be the resolution on the phase difference 
since the sampling frequency is anyhow fixed by the ADC, but it's 
definitely worth comparing.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi Tim,
Tim Wescott <tim@seemywebsite.really> wrote:
[]
>>>I have a pair of signals sin/cos whose phase difference is linked to a
>>>mechanism's position that I need to measure in order to drive it
>>>following a preset trajectory. Errors from the position will tune the
>>>driver in order to minimize the deviation from the wanted trajectory.
[]
> I keep trying to fit your problem statement into a framework that matches 
> what a Costas loop does, and I keep failing.
> 
> What in the world do you think a Costas loop is?
> 

quoting Wikipedia: A Costas loop is a phase-locked loop based circuit 
which is used for carrier phase recovery from suppressed-carrier 
modulation signals. (no provocation intended)

honestly we thought that locking on the phase signal would be necessary 
in order to extract the phase. Maybe our implementation is a variant of 
the costas loop, but the main principle remains.

> I normally do this sort of thing in software, which is a far better fit 
> for it, but here's what I would probably do:
> 

we do not have software onboard (I'm not sure if this is unfortunate or 
fortunate!)

> First, I'd name the signals:
> 
> x1 = A * sin(w + f)
> x2 = B * cos(w)
> 
> Then, I'd make my own internal reference at the nominal frequency, in 
> both inphase and quadrature.  This can be done with a lookup table with 
> surprisingly few elements:
> 
>       [ cos (wn) ]
> ref = [          ]
>       [ sin (wn) ]
> 
> Then, for each cycle of the reference frequency (or perhaps multiple 
> cycles, depending on my required sampling rates and on the closeness of 
> the nominal frequency with the reference), I'd calculate:
> 
> y1 = sum ref * x1
> y2 = sum ref * x2
> 
> (Note that these are vector quantities).

I'm assuming the sum is over the samples of my reference frequency, but 
I did not get what is this for.

> Now that I'm working at a much slower rate, I'd calculate
> 
> phase = atan2(y1_1 * y2_1 + y1_2 * y2_2, y1_2 * y2_1 - y1_1 * y2_2)
> 
> (Note, this is obvious if you take ref as e^(i * wn) instead of a vector, 
> and take y1 and y2 as complex numbers.  But explaining it all takes too 
> much time for free advise.)

I believe my background is not supporting me that much. Would you be 
kind enough to point some references in order to understand what you are 
trying to say? I'm not asking for the explanation, but I do want to 
understand it.

> 
> Note that there's not a loop -- much less a Costas loop -- in sight.

Noted indeed, but I did not get how you are able to extract the phase if 
the reference frequency and the nominal frequency are far apart, don't 
you need to lock on the frequency?

On 18 Mar 2014 08:53:21 GMT, al.basili@gmail.com (alb) wrote:

>Hi Tim,
>Tim Wescott <tim@seemywebsite.really> wrote:
>[]
>>>>I have a pair of signals sin/cos whose phase difference is linked to a
>>>>mechanism's position that I need to measure in order to drive it
>>>>following a preset trajectory. Errors from the position will tune the
>>>>driver in order to minimize the deviation from the wanted trajectory.
>[]
>> I keep trying to fit your problem statement into a framework that matches 
>> what a Costas loop does, and I keep failing.
>> 
>> What in the world do you think a Costas loop is?
>> 
>
>quoting Wikipedia: A Costas loop is a phase-locked loop based circuit 
>which is used for carrier phase recovery from suppressed-carrier 
>modulation signals. (no provocation intended)
>
>honestly we thought that locking on the phase signal would be necessary 
>in order to extract the phase. Maybe our implementation is a variant of 
>the costas loop, but the main principle remains.

Now I'm confused.   A PLL removes phase offset.   You're trying to
measure phase offset.   More below...

>> I normally do this sort of thing in software, which is a far better fit 
>> for it, but here's what I would probably do:
>> 
>
>we do not have software onboard (I'm not sure if this is unfortunate or 
>fortunate!)
>
>> First, I'd name the signals:
>> 
>> x1 = A * sin(w + f)
>> x2 = B * cos(w)
>> 
>> Then, I'd make my own internal reference at the nominal frequency, in 
>> both inphase and quadrature.  This can be done with a lookup table with 
>> surprisingly few elements:
>> 
>>       [ cos (wn) ]
>> ref = [          ]
>>       [ sin (wn) ]
>> 
>> Then, for each cycle of the reference frequency (or perhaps multiple 
>> cycles, depending on my required sampling rates and on the closeness of 
>> the nominal frequency with the reference), I'd calculate:
>> 
>> y1 = sum ref * x1
>> y2 = sum ref * x2
>> 
>> (Note that these are vector quantities).
>
>I'm assuming the sum is over the samples of my reference frequency, but 
>I did not get what is this for.
>
>> Now that I'm working at a much slower rate, I'd calculate
>> 
>> phase = atan2(y1_1 * y2_1 + y1_2 * y2_2, y1_2 * y2_1 - y1_1 * y2_2)
>> 
>> (Note, this is obvious if you take ref as e^(i * wn) instead of a vector, 
>> and take y1 and y2 as complex numbers.  But explaining it all takes too 
>> much time for free advise.)
>
>I believe my background is not supporting me that much. Would you be 
>kind enough to point some references in order to understand what you are 
>trying to say? I'm not asking for the explanation, but I do want to 
>understand it.
>
>> 
>> Note that there's not a loop -- much less a Costas loop -- in sight.
>
>Noted indeed, but I did not get how you are able to extract the phase if 
>the reference frequency and the nominal frequency are far apart, don't 
>you need to lock on the frequency?

Now I'm even more confused.   Are you generating one of the two
signals that you're trying to compare?   In your initial post you made
no mention of the frequencies being different, only the phase.   If
there's any difference in the frequencies at all, then the relative
phase won't be stable.

What exactly are you trying to do?   Lock the phase between the two?
Lock the frequency?



Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Hi Eric,
Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
> Now I'm confused.   A PLL removes phase offset.   You're trying to
> measure phase offset.   More below...

I think I was confused as well. The signals have a constant phase 
between them and their frequency is proportional to the speed of the mechanism 
that we need to drive. I completely misunderstood the problem I posted! 
Ouch.

>>Noted indeed, but I did not get how you are able to extract the phase if 
>>the reference frequency and the nominal frequency are far apart, don't 
>>you need to lock on the frequency?
> 
> Now I'm even more confused.   Are you generating one of the two
> signals that you're trying to compare?   In your initial post you made
> no mention of the frequencies being different, only the phase.   If
> there's any difference in the frequencies at all, then the relative
> phase won't be stable.

The signals have a fixed phase among them and a variable frequency which 
depends on the speed of the mechanism. The mechanism scan in one 
direction first, breaks, stops and accelerates to go in the reverse 
direction...therefore the frequency goes from a nominal value when the 
speed is constant to zero and then back again to the nominal value.

> What exactly are you trying to do?   Lock the phase between the two?
> Lock the frequency?

Thanks for asking, it made me ask and now the problem is much more clear 
than what it was. We lock on the frequency. Sorry for the confusion :-/

On Tue, 18 Mar 2014 15:24:32 +0000, alb wrote:

> Hi Eric,
> Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
>> Now I'm confused.   A PLL removes phase offset.   You're trying to
>> measure phase offset.   More below...
> 
> I think I was confused as well. The signals have a constant phase
> between them and their frequency is proportional to the speed of the
> mechanism that we need to drive. I completely misunderstood the problem
> I posted!
> Ouch.

Is this just a garden-variety incremental quadrature encoder, or perhaps 
an encoder with a sinusoid (rather than square wave) output?

In that case then there are some excellent well-established techniques 
for dealing with the signals.

>>>Noted indeed, but I did not get how you are able to extract the phase
>>>if the reference frequency and the nominal frequency are far apart,
>>>don't you need to lock on the frequency?
>> 
>> Now I'm even more confused.   Are you generating one of the two signals
>> that you're trying to compare?   In your initial post you made no
>> mention of the frequencies being different, only the phase.   If
>> there's any difference in the frequencies at all, then the relative
>> phase won't be stable.
> 
> The signals have a fixed phase among them and a variable frequency which
> depends on the speed of the mechanism. The mechanism scan in one
> direction first, breaks, stops and accelerates to go in the reverse
> direction...therefore the frequency goes from a nominal value when the
> speed is constant to zero and then back again to the nominal value.

Normally I try not to pick spell-checker nits, but this one tickled my 
funny bone.  Forgive me.  You mean "brakes".  If you read "break" 
literally, then you need a "repairs itself" right before or right after 
"stops".

>> What exactly are you trying to do?   Lock the phase between the two?
>> Lock the frequency?
> 
> Thanks for asking, it made me ask and now the problem is much more clear
> than what it was. We lock on the frequency. Sorry for the confusion :-/

If it's an encoder then you don't need to lock onto the frequency at all 
-- you can maintain a differential position reading that's as accurate as 
the encoder output.  If the encoder has an index pulse or other way to 
get the absolute position reading in one spot, the encoder + index will 
be an absolute, and not a differential, position.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Hi Tim,
Tim Wescott <tim@seemywebsite.please> wrote:
[]
>> I think I was confused as well. The signals have a constant phase
>> between them and their frequency is proportional to the speed of the
>> mechanism that we need to drive. I completely misunderstood the problem
>> I posted!
>> Ouch.
> 
> Is this just a garden-variety incremental quadrature encoder, or perhaps 
> an encoder with a sinusoid (rather than square wave) output?

Pierre Bonnard once said: The precision of naming takes away from the 
uniqueness of seeing.

> 
> In that case then there are some excellent well-established techniques 
> for dealing with the signals.

And now that I know what to look/ask for, loads of hits are popping up. At 
least now I have a place where to start!

>> The signals have a fixed phase among them and a variable frequency which
>> depends on the speed of the mechanism. The mechanism scan in one
>> direction first, breaks, stops and accelerates to go in the reverse
>> direction...therefore the frequency goes from a nominal value when the
>> speed is constant to zero and then back again to the nominal value.
> 
> Normally I try not to pick spell-checker nits, but this one tickled my 
> funny bone.  Forgive me.  You mean "brakes".  If you read "break" 
> literally, then you need a "repairs itself" right before or right after 
> "stops".

I must admit that was funny! My fingers are too used to 'break' 
instructions ;-). I usually read before posting but that mistake made it 
through (see http://danalookadoo.com/psychology/jumbled-text/).

>> Thanks for asking, it made me ask and now the problem is much more clear
>> than what it was. We lock on the frequency. Sorry for the confusion :-/
> 
> If it's an encoder then you don't need to lock onto the frequency at all 
> -- you can maintain a differential position reading that's as accurate as 
> the encoder output.  If the encoder has an index pulse or other way to 
> get the absolute position reading in one spot, the encoder + index will 
> be an absolute, and not a differential, position.

We have what we call a top-zero sensor which is providing the absolute 
position.

Thanks a lot for the hints. I'll post back after some reading, it will 
certainly be more effective.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Wed, 19 Mar 2014 11:39:50 +0000, alb wrote:

> Hi Tim,
> Tim Wescott <tim@seemywebsite.please> wrote:
> []
>>> I think I was confused as well. The signals have a constant phase
>>> between them and their frequency is proportional to the speed of the
>>> mechanism that we need to drive. I completely misunderstood the
>>> problem I posted!
>>> Ouch.
>> 
>> Is this just a garden-variety incremental quadrature encoder, or
>> perhaps an encoder with a sinusoid (rather than square wave) output?
> 
> Pierre Bonnard once said: The precision of naming takes away from the
> uniqueness of seeing.
> 
> 
>> In that case then there are some excellent well-established techniques
>> for dealing with the signals.
> 
> And now that I know what to look/ask for, loads of hits are popping up.
> At least now I have a place where to start!
> 
>>> The signals have a fixed phase among them and a variable frequency
>>> which depends on the speed of the mechanism. The mechanism scan in one
>>> direction first, breaks, stops and accelerates to go in the reverse
>>> direction...therefore the frequency goes from a nominal value when the
>>> speed is constant to zero and then back again to the nominal value.
>> 
>> Normally I try not to pick spell-checker nits, but this one tickled my
>> funny bone.  Forgive me.  You mean "brakes".  If you read "break"
>> literally, then you need a "repairs itself" right before or right after
>> "stops".
> 
> I must admit that was funny! My fingers are too used to 'break'
> instructions ;-). I usually read before posting but that mistake made it
> through (see http://danalookadoo.com/psychology/jumbled-text/).
> 
>>> Thanks for asking, it made me ask and now the problem is much more
>>> clear than what it was. We lock on the frequency. Sorry for the
>>> confusion :-/
>> 
>> If it's an encoder then you don't need to lock onto the frequency at
>> all -- you can maintain a differential position reading that's as
>> accurate as the encoder output.  If the encoder has an index pulse or
>> other way to get the absolute position reading in one spot, the encoder
>> + index will be an absolute, and not a differential, position.
> 
> We have what we call a top-zero sensor which is providing the absolute
> position.
> 
> Thanks a lot for the hints. I'll post back after some reading, it will
> certainly be more effective.

If you do, indeed, have a quadrature incremental encoder, then you'll 
find a lot of different ways of decoding it.  Each one has the quality 
that the person presenting it thinks it's just great, but only a few have 
the qualities of being compact and robust.

Avoid the ones that say "use channel A as a direction and channel B as a 
clock", or some variation -- those all suffer from the problem that 
jitter on one line (the "clock" line) will translate to erroneous 
motion.  They work well if the mechanism is always moving in one 
direction, but generate some pretty severe and head-scratching errors if 
the mechanism spends a lot of time stopped or creeping slowly.

The thing to remember about these encoders is that each transition of 
either line denotes a motion in one direction or another, and as long as 
you capture no more than one transition, the prior state of the encoder 
plus the current state of the encoder uniquely determines whether a 
transition has happened and it's direction.

The way that I do these in software is to sample fast enough that I'm 
guaranteed to capture every real transition (jitter doesn't cause severe 
problems with this method).  I take the captured encoder state and turn 
it into straight binary (00, 01, 10, 11), I compare it to the bottom two 
bits of a "position" register, and I increment or decrement the register 
as necessary to reconcile things.

I suspect that in an FPGA it'd be far more compact to just concatenate 
the "prior" and "current" readings into a four-bit word and extract the 
actions (increment, decrement, do nothing, or pop a fault).  This would 
use one or to LUTs, as opposed to the adders and whatnot that the 
software version uses (but which come for free in a microprocessor).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com