LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

phase locked loop confused by wrap around

Solved!
Go to solution

Hi all,

 

So I'm writing my own Phase-locked loop VI (software implementation). I'll eventually move to implementing it in an FPGA system but I'm using this software simulation to help my

understanding of the problem. I have a fair amount of controls experience but PLLs and LIAs are new to me. I've noticed not a lot of extremely practical postings on this subject and I hope to help the community with this thread by having a real solution posted here, VIs and all.

 

My attached VI has instructions to observe my problem. But I'll explain it briefly here because this may be a theoretical problem which others may understand or advise on. My PLL with a PID multiplies the two sinusoids, the "LO" and the signal to track, by each other to obtain a demodulated DC component. When the sinusoids are in phase this DC component is positive. When they are out of phase the DC component goes lower.

 

My control system will appropriately track "increasing" phase (i.e. if I disturb the non-LO signals phase to larger numbers) the system will follow. However, if I try to work "down" in phase (decreasing) the system gets confused and "wraps" around positive. Basically, the PID thinks that it should increase the phase to fix this problem when it should actually decrease.

 

PLLs must solve this generally in some way but it does seem a bit like a fundamental issue - the control action gets reversed when leading the reference vs. lagging the reference clock. I haven't seen documentation that uses any kind of non-linear "switching" tricks to help inform the PID which direction to pull.

 

 

Any input or references or links to other code examples would be great.

 

 

Attached is my VI along with a modified PID vi (credit here: http://sites.google.com/site/auraliusproject/pid-controller-with-labview-8-5). I modified the PID VI to include anti-windup limits.

 

PLL_Test2.vi is the top level and CustomPID.vi is used by it in one location. Instructions on the front panel can show you the problem. I'm avoiding using NI packages for this for A) my own learning and B) the benefit of those without those packages. If someone has the NI PLL solutions can could share with me the "key" I'm missing here - that'd be great too.

 

Download All
0 Kudos
Message 1 of 4
(2,871 Views)

Couldn't find an edit button so I replied ...sorry Moderator.

 

 

A clarification - If I remove any upper limit for my phase control then the system will function as intended. The PID controller isn't aware that reducing its control phase would result in a "shorter" distance to traverse to meet a steady state condition. Instead, with no limit to the phase control the system simply tracks ahead inphase until it reaches a steady point. This is analogous to crossing the room by walking backwards around the earth. You'll get there but it was an inefficient route.

 

In control system language (which I'm more familiar with) an unlimited control variable wouldn't occur because some actuator would saturate. Put in analog IC terms - if you were using a VCO with an input range of 0 to 5V then "my" system would get stuck at 5Vs trying to exceed it because a stable solution was at 7.5V. My goal is to help my PID understand that 2.5V is a "better" solution than 7.5V.

 

This is why I called the title of this post "wrap-around." So - rephrasing the question - Does anyone know how VCO (voltage controlled oscillators) in analog PLLs avoid saturating?

0 Kudos
Message 2 of 4
(2,846 Views)
Solution
Accepted by topic author AlexDubya

Aha! I found a solution! For future people looking for the answer - I highly recommend THIS link as a set of files that will get you 90% of the way there

 

https://decibel.ni.com/content/docs/DOC-1121

 

For people still reading - the difference is see in my attached JPG. The top example (mine) uses a multiply followed by a low pass filter. The problem is that that filter is non-monotonic with changing phase (i.e. that filter's DC output is maximum when phase is matched but decreases with both leading and lagging phase). The NI solution (bottom) is monotonic with phase (that is, phase difference between the LO and the input).

 

I can tell the NI solution is doing some complex (as in non-real numbers) math to extract the phase information. It looks a lot like in-phase & quadtrature extraction and maybe thats important. The key question I have going forward is - what does a blessed Hilbert Transform help me with ? What is its function? Reading the help - I do get a little buried in the Math of it.

 

 

-Thanks

 

 

ExampleCode.jpg

Download All
Message 3 of 4
(2,835 Views)

@AlexDubya wrote:

I can tell the NI solution is doing some complex (as in non-real numbers) math to extract the phase information. It looks a lot like in-phase & quadtrature extraction and maybe thats important. The key question I have going forward is - what does a blessed Hilbert Transform help me with ? What is its function? Reading the help - I do get a little buried in the Math of it.


That blessed Hilbert transform is there to give you two signals with a Pi/2 phase difference between them, I&Q if you like.  The dc estimate functions then provide the extraction, just remember that the average of sin^2 or cos^2 is 1/2 while the average of sin*cos is 0.  So you are extracting cos(phi) and sin(phi), where phi is the phase difference between the input signal and the LO.  The multiplication by two is gratuitous, and the complex functions are just a roundabout way to implement the atan2 function.

 

Despite its deep-seated roots in causality and analytic functions, the Hilbert tranform in this application can be thought of as doing a few simple operations:

 

H{sin(t)} = -cos(t)

H{cos(t)} = sin(t)

H{H{f(t)}} = -f(t)

 

Message 4 of 4
(2,807 Views)