## Advice on digital phase locked loop with square wave input wanted

Started by 7 years ago7 replieslatest reply 7 years ago864 views

I have the interesting project of desigining and implementing a digital phase locked loop in a micro-controller. The input is a square wave for which the absolute time of the leading edge is taken in hardware and fed into a re-circulating buffer. This input square wave comes from a remote source that is asynchronous to the mico-controller and may vary +/- 10 % from the idea value. A filtered local version of the input is required to be generated by the micro-controller.

I'm having a look at Neil Robinson's two part tutorial on Digital PLLs and Reza Ameli's Discrete Time PLLs, Part 1:Basics I found in DSPrelated's blogs. However these two tutorials seem to deal with loops whose input is a sine wave being sampled manys times fater than its frequency. In my situation the input square wave is not regularly sampled but each leading edge is time stamped by a timer in the micro-controller. I basically need to calculate a corresponding local stream of time stamps with reduced jitter (calculations can be performed at higher resolution than the time stamps).

I need to track the incoming square wave to within 1 or 2 % and at the same time filter the incoming square wave because jitter on the leading edge is expected. The period of the next but one local square wave from the DPLL then needs to be calculated so a micro-controller's timer can be set up ahead of time to generate the local square wave. Calculations will be performed approx 1/2 way between leading edges of the locally generated square wave.

If anyone could refer me to any other tutorials, papers or books that deal with this kind of DPLL I'd be most grateful, or of course any thoughts directly in this forum thread.

Regards,

John

#PLL

[ - ]

So, in one place you say that the input square wave will vary by up to 10% of the expected value (10% of what?), and someplace else you say you need to track it to within 1% to 2%.  These directly contradict.

Putting that aside, I've done similar things.  Ultimately, you want to capture the time of the incoming edge vs. the edge time of your square wave, and you want to servo your square wave period such that the average error is zero.

Conceptually it's easy: $$n = k_p e_t + k_i \sum e_t$$ where $$n$$ is the commanded period in clock ticks, $$e_t$$ is the error in clock ticks, and $$k_p$$ and $$k_i$$ are the proportional and integral gains, respectively.

In practice, you'll end up snarled in all the details of tracking the edge timing accurately, and, if you don't want to do the PI loop tuning by the seat of your pants, in figuring them out from first principles.

[ - ]

Thanks for the reply. Curious to know where you got the contradiction from that you mention in the first paragraph. To expand the projects context. The incoming squarewave should be at 1 kHz but in fault conditions we will accept an error of up to +- 10 %. ie 900 Hz to 1.1 kHz. Whatever the input freq it is important that our locally generated squarewave is locked to the incoming one exactly in frequency and its phase to within 2 % of its period (which I did not explain well). Ideally we want 0 deg. phase error. ie with 1 kHz incoming squarewave the timing error of the locally generated squarewave must be better than +- 20 us (~ +- 7 deg.).

Thanks for the "Conceptually it's easy: n=kpet+kiet". I'll have a go at implementing it during the next few days.

[ - ]

I did not realize that the $$\pm$$10% was a fallback from a desired $$\pm$$2%.  That's what set off the alarm bells.

Without having any information about how rapidly the actual signal varies, how quickly you need to acquire lock, how much noise there is in the transmission of the reference and it's dynamic characteristics, and how much (and how rapidly) your local reference clock varies there's absolutely no way to tell beforehand if you'll meet your goals.  Without doing the math on it you're pretty much limited to b'guess and b'gosh -- which is great when you luck out and the stars align.

[ - ]

Hi John,

The analysis in my PLL tutorial still applies -- however, to use that approach you would need to calculate the gain Kp of the time-stamp based phase detector.  I guess there is inherent jitter in this phase detection method, but maybe it is not a problem for your purposes.

regards,

Neil

[ - ]

Hey Neil:

I've done this sort of thing before.  As long as the capturing counter's clock tick is small enough it all works.  You can treat it as quantization noise, and use all the established analysis tools as if you were capturing the phase with a magical phase ADC.

[ - ]

Yeah,

I once implemented a TDC phase detector who's input was just an external clock that was captured asynchronously as a single-bit signal.  I forget how much oversampling I had, but I was surprised how well the PLL worked.

[ - ]