Dear all,
After taking your advice on looking into application notes etc for PLL I
think i finally understood the theory behind a PLL and I think I can write
an algorithm now. I just wanted to share what I learned and if there is any
mistake in my understanding then please correct me. I will start writing
the algorithm as soon as I finish this post.
Looking into Motorola 4046's app note and a book on control system by
Raymond Jacquot the following is what I found.
H(s) = K.((tau2.s+1)/tau1.s)(1/s)
----------------------------
1 + K((tau2.s+1)/tau2.s)(1/s)
is the closed loop transfer function of the type-2 PLL. Upon doing a
bilinear transformation I get the transfer function in Z domain as
H(z) = K.(c1+c2)z^-1 - K.c1.z^-2
--------------------------
1 + (K.(c1+c2)-2).z^-1 + (1 - K.c1).z^-2
which, ultimately gives the following equation in discrete time domain
y[n]= (2-K.(c1+c2)).y[n-2]+ (K.c1-1).y[n-2]+ K.(c1+c2).x[n-1]- k.c1.x[n-2]
where, y[m] is the phase of the signal from the NCO at t=m and x[m] is the
phase of the input signal.
I can find c1 and c2 by using tau1, tau2, noise bandwidth of the loop, gain
K, damping ratio (zeta) and control system design methods such as root
locus.
The potential problem that I see with the above equation is the initial
values for x and y. I will put some more thought here.
Is this how it is done? I will now code it in C++ and find out if I am
doing it right.
Thanks,
Mir
Software PLL - the math that i did looks too simple to be true - please confrim
Started by ●February 7, 2011
Reply by ●February 7, 20112011-02-07
On 02/07/2011 01:35 PM, mir_aculous wrote:> Dear all, > After taking your advice on looking into application notes etc for PLL I > think i finally understood the theory behind a PLL and I think I can write > an algorithm now. I just wanted to share what I learned and if there is any > mistake in my understanding then please correct me. I will start writing > the algorithm as soon as I finish this post. > > Looking into Motorola 4046's app note and a book on control system by > Raymond Jacquot the following is what I found. > > H(s) = K.((tau2.s+1)/tau1.s)(1/s) > ---------------------------- > 1 + K((tau2.s+1)/tau2.s)(1/s) > is the closed loop transfer function of the type-2 PLL. Upon doing a > bilinear transformation I get the transfer function in Z domain as > > H(z) = K.(c1+c2)z^-1 - K.c1.z^-2 > -------------------------- > 1 + (K.(c1+c2)-2).z^-1 + (1 - K.c1).z^-2 > > which, ultimately gives the following equation in discrete time domain > > y[n]= (2-K.(c1+c2)).y[n-2]+ (K.c1-1).y[n-2]+ K.(c1+c2).x[n-1]- k.c1.x[n-2] > > where, y[m] is the phase of the signal from the NCO at t=m and x[m] is the > phase of the input signal. > > I can find c1 and c2 by using tau1, tau2, noise bandwidth of the loop, gain > K, damping ratio (zeta) and control system design methods such as root > locus. > > The potential problem that I see with the above equation is the initial > values for x and y. I will put some more thought here. > > Is this how it is done? I will now code it in C++ and find out if I am > doing it right.You need to know the oscillator gain and the phase detector gain. Oscillator gain is usually easy, because an NCO doesn't even have component variation to mess you up. Phase detector characteristics are more problematic if you're trying to lock to data -- if you're trying to lock to transitions in the data then the phase detector gain and delay depends on the average number of transitions in the data and the average delay between transitions. You need to take this variation into account in your design. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 7, 20112011-02-07
On Feb 7, 5:24�pm, Tim Wescott <t...@seemywebsite.com> wrote:> On 02/07/2011 01:35 PM, mir_aculous wrote: > > You need to know the oscillator gain and the phase detector gain. > Oscillator gain is usually easy, because an NCO doesn't even have > component variation to mess you up.rather than try to adapt a CD4016 or CD4046 PLL analog PLL to a discrete-time software PLL, i would suggest modeling it (the NCO, phase discriminator, and the PID controller) directly. since the input to the NCO directly controls frequency, you need to model (and it's simple, just an integrator) the transfer function from frequency to phase, since it's (usually) the phase difference that comes outa the phase discriminator. the integrator that is inherent to the NCO usually obviates the need for the "P" in the PID controller.> �Phase detector characteristics are > more problematic if you're trying to lock to data -- if you're trying to > lock to transitions in the data then the phase detector gain and delay > depends on the average number of transitions in the data and the average > delay between transitions. �another way to mathematically model a phase discriminator is to look at it as the LPFed output of a multiplier between the two waveforms that are virtually the same frequency. when the PLL is "locked", that means the two waveforms will be 90 degrees outa phase. of course, when they get more and more out of phase, there is a non- linearity in the phase discriminator, if you do it this way. if you need your oscillator output to be in the same phase as the input, then use the same phase going into the NCO for two quadrature (that is 90 degrees outa phase with each other) table lookups. r b-j
Reply by ●February 7, 20112011-02-07
On 02/07/2011 02:44 PM, robert bristow-johnson wrote:> On Feb 7, 5:24 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 02/07/2011 01:35 PM, mir_aculous wrote: >> >> You need to know the oscillator gain and the phase detector gain. >> Oscillator gain is usually easy, because an NCO doesn't even have >> component variation to mess you up. > > rather than try to adapt a CD4016 or CD4046 PLL analog PLL to a > discrete-time software PLL, i would suggest modeling it (the NCO, > phase discriminator, and the PID controller) directly.Good point, and one I missed.> since the input to the NCO directly controls frequency, you need to > model (and it's simple, just an integrator) the transfer function from > frequency to phase, since it's (usually) the phase difference that > comes outa the phase discriminator. the integrator that is inherent > to the NCO usually obviates the need for the "P" in the PID > controller.Eh? Most phase-locked loops that I do use a PI controller. One rarely needs differential, but one occasionally needs an extra low-pass filter if you really want to clean up jitter.>> Phase detector characteristics are >> more problematic if you're trying to lock to data -- if you're trying to >> lock to transitions in the data then the phase detector gain and delay >> depends on the average number of transitions in the data and the average >> delay between transitions. > > another way to mathematically model a phase discriminator is to look > at it as the LPFed output of a multiplier between the two waveforms > that are virtually the same frequency. when the PLL is "locked", that > means the two waveforms will be 90 degrees outa phase. > > of course, when they get more and more out of phase, there is a non- > linearity in the phase discriminator, if you do it this way. > > if you need your oscillator output to be in the same phase as the > input, then use the same phase going into the NCO for two quadrature > (that is 90 degrees outa phase with each other) table lookups.That depends on the phase detector. If you're locking to edges (which is fairly easy to do with the right counter resources) then you can make your phase detector act pretty much like a regular old phase/frequency detector. If you're locking to data, then you're locking to data and limited by the data stream -- and that's not going to be like locking to a sinusoid. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 7, 20112011-02-07
On Feb 7, 8:39�pm, Tim Wescott <t...@seemywebsite.com> wrote:> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: > > > > since the input to the NCO directly controls frequency, you need to > > model (and it's simple, just an integrator) the transfer function from > > frequency to phase, since it's (usually) the phase difference that > > comes outa the phase discriminator. �the integrator that is inherent > > to the NCO usually obviates the need for the "P" in the PID > > controller. > > Eh? �Most phase-locked loops that I do use a PI controller.ooops. i meant that in the actual guts of the controller, you would lose the "I", because of the inherent I in the NCO (if what comes outa the phase discriminator is the difference of phase, not the difference of frequency).> �One rarely > needs differential, but one occasionally needs an extra low-pass filter > if you really want to clean up jitter. >what i meant was this identity: sin(w0+phi)*cos(w0) = 0.5*sin(phi) + 0.5*sin(2*w0+phi) because the integrator might take care of it, you might not need the LPF, but we want the sin(phi) term to survive as it is pretty close to phi and measures our phase difference.> > another way to mathematically model a phase discriminator is to look > > at it as the LPFed output of a multiplier between the two waveforms > > that are virtually the same frequency. �when the PLL is "locked", that > > means the two waveforms will be 90 degrees outa phase. > > > of course, when they get more and more out of phase, there is a non- > > linearity in the phase discriminator, if you do it this way. > > > if you need your oscillator output to be in the same phase as the > > input, then use the same phase going into the NCO for two quadrature > > (that is 90 degrees outa phase with each other) table lookups. > > That depends on the phase detector. �If you're locking to edges (which > is fairly easy to do with the right counter resources) then you can make > your phase detector act pretty much like a regular old phase/frequency > detector. �If you're locking to data, then you're locking to data and > limited by the data stream -- and that's not going to be like locking to > a sinusoid.agreed. but multiplying two square waves together (and LPFing) can get that same phi term that goes to zero when the two are 90 degrees outa phase. i seem to remember seeing an old design (i wonder if it *was* a 4016 or similar) where the phase discriminator was essentially an XOR gate. it's sorta similar. r b-j
Reply by ●February 8, 20112011-02-08
>On Feb 7, 8:39=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: >> >> >> > since the input to the NCO directly controls frequency, you need to >> > model (and it's simple, just an integrator) the transfer functionfrom>> > frequency to phase, since it's (usually) the phase difference that >> > comes outa the phase discriminator. =A0the integrator that isinherent>> > to the NCO usually obviates the need for the "P" in the PID >> > controller. >> >> Eh? =A0Most phase-locked loops that I do use a PI controller. > >ooops. i meant that in the actual guts of the controller, you would >lose the "I", because of the inherent I in the NCO (if what comes outa >the phase discriminator is the difference of phase, not the difference >of frequency). > >> =A0One rarely >> needs differential, but one occasionally needs an extra low-pass filter >> if you really want to clean up jitter. >> > >what i meant was this identity: > > > sin(w0+phi)*cos(w0) =3D 0.5*sin(phi) + 0.5*sin(2*w0+phi) > >because the integrator might take care of it, you might not need the >LPF, but we want the sin(phi) term to survive as it is pretty close to >phi and measures our phase difference. > >> > another way to mathematically model a phase discriminator is to look >> > at it as the LPFed output of a multiplier between the two waveforms >> > that are virtually the same frequency. =A0when the PLL is "locked",tha=>t >> > means the two waveforms will be 90 degrees outa phase. >> >> > of course, when they get more and more out of phase, there is a non- >> > linearity in the phase discriminator, if you do it this way. >> >> > if you need your oscillator output to be in the same phase as the >> > input, then use the same phase going into the NCO for two quadrature >> > (that is 90 degrees outa phase with each other) table lookups. >> >> That depends on the phase detector. =A0If you're locking to edges(which>> is fairly easy to do with the right counter resources) then you canmake>> your phase detector act pretty much like a regular old phase/frequency >> detector. =A0If you're locking to data, then you're locking to data and >> limited by the data stream -- and that's not going to be like lockingto>> a sinusoid. > >agreed. but multiplying two square waves together (and LPFing) can >get that same phi term that goes to zero when the two are 90 degrees >outa phase. i seem to remember seeing an old design (i wonder if it >*was* a 4016 or similar) where the phase discriminator was essentially >an XOR gate. it's sorta similar. > >r b-j > > >Before, I get confused further about the implementation process, I want to tell you all that my ultimate goal is to track the carrier and the code in a direct sequence spread spectrum signal. First, I want to implement the basic PLL where I can input a signal such as an FM signal and try to lock on to the carrier. If that works then I can move on towards my goal of locking on to the carrier of a DSSS signal and then doing clock/code tracking by implementing a code tracking loop as given in many gps related books. But first, the basic loop to track a sinusoid.> since the input to the NCO directly controls frequency, you need to > model (and it's simple, just an integrator) the transfer function from > frequency to phase, since it's (usually) the phase difference that > comes outa the phase discriminator. the integrator that is inherent > to the NCO usually obviates the need for the "P" in the PID > controller.r-b-j, can you explain a little more about the direct implementation that you are talking about. This is what I understand so far. phase_error = LPF ( input sample * VCO sample ), which makes sense as it ultimately splits down to a phase term and another high frequency term which is low pass filtered. So, once I have this phase term what do I do next? Can you put it down in a mathematical equation as it's easier to understand that way. thanks, Mir
Reply by ●February 8, 20112011-02-08
>On Feb 7, 8:39�pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: >> >> >> > since the input to the NCO directly controls frequency, you need to >> > model (and it's simple, just an integrator) the transfer functionfrom>> > frequency to phase, since it's (usually) the phase difference that >> > comes outa the phase discriminator. �the integrator that isinherent>> > to the NCO usually obviates the need for the "P" in the PID >> > controller. >> >> Eh? �Most phase-locked loops that I do use a PI controller. > >ooops. i meant that in the actual guts of the controller, you would >lose the "I", because of the inherent I in the NCO (if what comes outa >the phase discriminator is the difference of phase, not the difference >of frequency). > >> �One rarely >> needs differential, but one occasionally needs an extra low-pass filter >> if you really want to clean up jitter. >> > >what i meant was this identity: > > > sin(w0+phi)*cos(w0) = 0.5*sin(phi) + 0.5*sin(2*w0+phi) > >because the integrator might take care of it, you might not need the >LPF, but we want the sin(phi) term to survive as it is pretty close to >phi and measures our phase difference. > >> > another way to mathematically model a phase discriminator is to look >> > at it as the LPFed output of a multiplier between the two waveforms >> > that are virtually the same frequency. �when the PLL is "locked",tha>t>> > means the two waveforms will be 90 degrees outa phase. >> >> > of course, when they get more and more out of phase, there is a non- >> > linearity in the phase discriminator, if you do it this way. >> >> > if you need your oscillator output to be in the same phase as the >> > input, then use the same phase going into the NCO for two quadrature >> > (that is 90 degrees outa phase with each other) table lookups. >> >> That depends on the phase detector. �If you're locking to edges(which>> is fairly easy to do with the right counter resources) then you canmake>> your phase detector act pretty much like a regular old phase/frequency >> detector. �If you're locking to data, then you're locking to data and >> limited by the data stream -- and that's not going to be like lockingto>> a sinusoid. > >agreed. but multiplying two square waves together (and LPFing) can >get that same phi term that goes to zero when the two are 90 degrees >outa phase. i seem to remember seeing an old design (i wonder if it >*was* a 4016 or similar) where the phase discriminator was essentially >an XOR gate. it's sorta similar. > >r b-j > > >Before, I get confused further about the implementation process, I want to tell you all that my ultimate goal is to track the carrier and the code in a direct sequence spread spectrum signal. First, I want to implement the basic PLL where I can input a signal such as an FM signal and try to lock on to the carrier. If that works then I can move on towards my goal of locking on to the carrier of a DSSS signal and then doing clock/code tracking by implementing a code tracking loop as given in many gps related books. But first, the basic loop to track a sinusoid.> since the input to the NCO directly controls frequency, you need to > model (and it's simple, just an integrator) the transfer function from > frequency to phase, since it's (usually) the phase difference that > comes outa the phase discriminator. the integrator that is inherent > to the NCO usually obviates the need for the "P" in the PID > controller.r-b-j, can you explain a little more about the direct implementation that you are talking about. This is what I understand so far. phase_error = LPF ( input sample * VCO sample ), which makes sense as it ultimately splits down to a phase term and another high frequency term which is low pass filtered. So, once I have this phase term what do I do next? Can you put it down in a mathematical equation as it's easier to understand that way. thanks, Mir
Reply by ●February 8, 20112011-02-08
On 02/07/2011 05:52 PM, robert bristow-johnson wrote:> On Feb 7, 8:39 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: >> >> >>> since the input to the NCO directly controls frequency, you need to >>> model (and it's simple, just an integrator) the transfer function from >>> frequency to phase, since it's (usually) the phase difference that >>> comes outa the phase discriminator. the integrator that is inherent >>> to the NCO usually obviates the need for the "P" in the PID >>> controller. >> >> Eh? Most phase-locked loops that I do use a PI controller. > > ooops. i meant that in the actual guts of the controller, you would > lose the "I", because of the inherent I in the NCO (if what comes outa > the phase discriminator is the difference of phase, not the difference > of frequency). > >> One rarely >> needs differential, but one occasionally needs an extra low-pass filter >> if you really want to clean up jitter. >> > > what i meant was this identity: > > > sin(w0+phi)*cos(w0) = 0.5*sin(phi) + 0.5*sin(2*w0+phi) > > because the integrator might take care of it, you might not need the > LPF, but we want the sin(phi) term to survive as it is pretty close to > phi and measures our phase difference. > >>> another way to mathematically model a phase discriminator is to look >>> at it as the LPFed output of a multiplier between the two waveforms >>> that are virtually the same frequency. when the PLL is "locked", that >>> means the two waveforms will be 90 degrees outa phase. >> >>> of course, when they get more and more out of phase, there is a non- >>> linearity in the phase discriminator, if you do it this way. >> >>> if you need your oscillator output to be in the same phase as the >>> input, then use the same phase going into the NCO for two quadrature >>> (that is 90 degrees outa phase with each other) table lookups. >> >> That depends on the phase detector. If you're locking to edges (which >> is fairly easy to do with the right counter resources) then you can make >> your phase detector act pretty much like a regular old phase/frequency >> detector. If you're locking to data, then you're locking to data and >> limited by the data stream -- and that's not going to be like locking to >> a sinusoid. > > agreed. but multiplying two square waves together (and LPFing) can > get that same phi term that goes to zero when the two are 90 degrees > outa phase. i seem to remember seeing an old design (i wonder if it > *was* a 4016 or similar) where the phase discriminator was essentially > an XOR gate. it's sorta similar.Robert, there's a heck of a lot more different types of phase detectors than just multiplying the two waveforms together. Each one has its own impact on how the loop behaves, some making it easier to design the loop, some harder. So far you seem stuck on the "phase detector multiplies signals" concept, and can't seem to move beyond it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 8, 20112011-02-08
On 02/07/2011 05:52 PM, robert bristow-johnson wrote:> On Feb 7, 8:39 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: >> >> >>> since the input to the NCO directly controls frequency, you need to >>> model (and it's simple, just an integrator) the transfer function from >>> frequency to phase, since it's (usually) the phase difference that >>> comes outa the phase discriminator. the integrator that is inherent >>> to the NCO usually obviates the need for the "P" in the PID >>> controller. >> >> Eh? Most phase-locked loops that I do use a PI controller. > > ooops. i meant that in the actual guts of the controller, you would > lose the "I", because of the inherent I in the NCO (if what comes outa > the phase discriminator is the difference of phase, not the difference > of frequency). > >> One rarely >> needs differential, but one occasionally needs an extra low-pass filter >> if you really want to clean up jitter. >> > > what i meant was this identity: > > > sin(w0+phi)*cos(w0) = 0.5*sin(phi) + 0.5*sin(2*w0+phi) > > because the integrator might take care of it, you might not need the > LPF, but we want the sin(phi) term to survive as it is pretty close to > phi and measures our phase difference. > >>> another way to mathematically model a phase discriminator is to look >>> at it as the LPFed output of a multiplier between the two waveforms >>> that are virtually the same frequency. when the PLL is "locked", that >>> means the two waveforms will be 90 degrees outa phase. >> >>> of course, when they get more and more out of phase, there is a non- >>> linearity in the phase discriminator, if you do it this way. >> >>> if you need your oscillator output to be in the same phase as the >>> input, then use the same phase going into the NCO for two quadrature >>> (that is 90 degrees outa phase with each other) table lookups. >> >> That depends on the phase detector. If you're locking to edges (which >> is fairly easy to do with the right counter resources) then you can make >> your phase detector act pretty much like a regular old phase/frequency >> detector. If you're locking to data, then you're locking to data and >> limited by the data stream -- and that's not going to be like locking to >> a sinusoid. > > agreed. but multiplying two square waves together (and LPFing) can > get that same phi term that goes to zero when the two are 90 degrees > outa phase. i seem to remember seeing an old design (i wonder if it > *was* a 4016 or similar) where the phase discriminator was essentially > an XOR gate. it's sorta similar.Robert, there's a heck of a lot more different types of phase detectors than just multiplying the two waveforms together. Each one has its own impact on how the loop behaves, some making it easier to design the loop, some harder. So far you seem stuck on the "phase detector multiplies signals" concept, and can't seem to move beyond it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 8, 20112011-02-08
On 02/07/2011 09:50 PM, mir_aculous wrote:>> On Feb 7, 8:39=A0pm, Tim Wescott<t...@seemywebsite.com> wrote: >>> On 02/07/2011 02:44 PM, robert bristow-johnson wrote: >>> >>> >>>> since the input to the NCO directly controls frequency, you need to >>>> model (and it's simple, just an integrator) the transfer function > from >>>> frequency to phase, since it's (usually) the phase difference that >>>> comes outa the phase discriminator. =A0the integrator that is > inherent >>>> to the NCO usually obviates the need for the "P" in the PID >>>> controller. >>> >>> Eh? =A0Most phase-locked loops that I do use a PI controller. >> >> ooops. i meant that in the actual guts of the controller, you would >> lose the "I", because of the inherent I in the NCO (if what comes outa >> the phase discriminator is the difference of phase, not the difference >> of frequency). >> >>> =A0One rarely >>> needs differential, but one occasionally needs an extra low-pass filter >>> if you really want to clean up jitter. >>> >> >> what i meant was this identity: >> >> >> sin(w0+phi)*cos(w0) =3D 0.5*sin(phi) + 0.5*sin(2*w0+phi) >> >> because the integrator might take care of it, you might not need the >> LPF, but we want the sin(phi) term to survive as it is pretty close to >> phi and measures our phase difference. >> >>>> another way to mathematically model a phase discriminator is to look >>>> at it as the LPFed output of a multiplier between the two waveforms >>>> that are virtually the same frequency. =A0when the PLL is "locked", > tha= >> t >>>> means the two waveforms will be 90 degrees outa phase. >>> >>>> of course, when they get more and more out of phase, there is a non- >>>> linearity in the phase discriminator, if you do it this way. >>> >>>> if you need your oscillator output to be in the same phase as the >>>> input, then use the same phase going into the NCO for two quadrature >>>> (that is 90 degrees outa phase with each other) table lookups. >>> >>> That depends on the phase detector. =A0If you're locking to edges > (which >>> is fairly easy to do with the right counter resources) then you can > make >>> your phase detector act pretty much like a regular old phase/frequency >>> detector. =A0If you're locking to data, then you're locking to data and >>> limited by the data stream -- and that's not going to be like locking > to >>> a sinusoid. >> >> agreed. but multiplying two square waves together (and LPFing) can >> get that same phi term that goes to zero when the two are 90 degrees >> outa phase. i seem to remember seeing an old design (i wonder if it >> *was* a 4016 or similar) where the phase discriminator was essentially >> an XOR gate. it's sorta similar. >> >> r b-j >> >> >> > > Before, I get confused further about the implementation process, I want to > tell you all that my ultimate goal is to track the carrier and the code in > a direct sequence spread spectrum signal. > > First, I want to implement the basic PLL where I can input a signal such as > an FM signal and try to lock on to the carrier. If that works then I can > move on towards my goal of locking on to the carrier of a DSSS signal and > then doing clock/code tracking by implementing a code tracking loop as > given in many gps related books. But first, the basic loop to track a > sinusoid. > >> since the input to the NCO directly controls frequency, you need to >> model (and it's simple, just an integrator) the transfer function from >> frequency to phase, since it's (usually) the phase difference that >> comes outa the phase discriminator. the integrator that is inherent >> to the NCO usually obviates the need for the "P" in the PID >> controller. > > r-b-j, can you explain a little more about the direct implementation that > you are talking about. This is what I understand so far. > > phase_error = LPF ( input sample * VCO sample ), which makes sense as it > ultimately splits down to a phase term and another high frequency term > which is low pass filtered. So, once I have this phase term what do I do > next?Robert is giving you a very limited view of phase detectors. Some do, indeed, multiply the incoming signals (either as sinusoids, or as square waves, in which case you find that an XOR gate acts the same as a multiplication). Some compare edges (search on "three state phase detector" or "phase-frequency detector"). Some PLL's are extracting clock from data, and there are various ways to do that (search on "data driven PLL" or "Costas loop"). In the case of DSSS, you run at least three correlators, an 'early' one, an 'on time' one, and a 'late' one. You compare the relative magnitudes of the outputs of the early and late correlators and use that to correct the loop.> Can you put it down in a mathematical equation as it's easier to understand > that way.You describe the behavior in terms of a difference equation, then you take the z transform of the difference equation. If, for instance, you have a phase-increment NCO, then at each iteration of your clock you find that your NCO phase goes p_O(n) = p_O(n-1) + p_i(n) where p_O is the oscillator phase, and p_i is the commanded phase from the loop filter. Taking the z transform of this you get P_O = P_O * z^-1 + P_i or z P_O = P_O + z P_i or P_O z --- = ----- P_i z - 1 You model the phase detector by a similar process (and find that it's just a gain, or a system that can be linearized to get a gain when the loop is locked), then you make a loop filter that will get you your desired loop performance. See http://www.wescottdesign.com/articles/zTransform/z-transforms.html and http://www.wescottdesign.com/actfes/actfes.html. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
