How does a PLL work?

Exactly. The VCO phase accelerates in the first part of the cycle and decelerates in the second (for the 2*f ripples present at the output of the simplest multiplier-based PD). This distorts the VCO cosine and turns it into something resembling sawtooth waveform, but the phase/frequency lock is firmly held: the average phase distortion over a cycle is 0. There are no uncertainities.

I'd like it to be constant and 0. And it is what happens, at least for a sufficiently practical value of 0... ;-)

In the case of this first-order filter the phase offset is less than about 3 degrees (inferred from quick visual inspection, not atan2) for 55Hz (twice more than the norm allows), which I find amazing relatively to the simplicity of the software solution. No complex filtering, just a single block of exponential smoothing with its mediocre 6dB slope. This phase error can be arbitrarily reduced by amplification of the error voltage, but at the cost of serious increase of distortion, so in practice it is just a curiosity.

Best regards, Piotr

You must distinguish between instantaneous phase and average phase. Here's a picture for you, depicting the last cycles of a heavily overdriven VCO trying to tune to 55Hz:

As you can see, the instantaneous phase went totally crazy, but the phase/frequency lock still maintained (relatively to the blue curve).

Best regards, Piotr

wrong?

The problem is using a PD like that in an unfiltered first-order loop. You'll have a gigantic deadband that the loop will hunt around in. Since you're using software, why is it hard to add a few more bits and use a proper digital filter?

Cheers

Phil Hobbs

There can be small outputs - depending upon the timing of the reference and the VCO the time difference can result in very narrow pulses - they are not quantized unit charges. Either clock input can terminate the pulse.

As Phil has said this type of PFD suffers from a dead zone when both clocks are close to synchronism that gives unstable operation.

kevin

Ok, fair 'nuff, if in one's design one's comfortable with "it's locked at something" and a distorted VCO waveform. OP gave the impression that he was comfortable with that, and as I understand it when he attempted to get it to lock a free-running oscillator with a natural frequency significantly different than the reference at a specific relative phase via a first-order PLL discovered you might need an infinite delay line to do so. AFAIK that's not unexpected, and the math doesn't claim otherwise.

Can you tell me what signals are represented by what colors in the diagram? I think I know but would be good to be sure...

I've never used a first-order loop myself, partly because BITD I got chucke d into the deep end of the pool--I was lucky enough to be given the job of designing 2/3 of the frequency-control electronics for the world's first ci vilian DBS system, despite having only a hobby electronics background to go with an astronomy and physics bachelor's degree. I'd heard about PLLs but had never seen one to know what it was.

Fortunately my supervisor (one Josef Fikart, may his tribe increase) lent m e a copy of Gardner, so I came up to speed acceptably quickly and got the j ob done before I had to leave for grad school. I'm grateful that they were willing to take a chance on me.

Cheers

Phil Hobbs

Precisely because there are not many bits left. This is a very weird chip with seriously too few bytes per MIPS. It can do 8e7 MACs per second, but has only 256 24-bit storage cells, 128 code locations and 32 labels (jump targets). And it needs to do the following:

1. For 8 independent ADC data streams, 100ksps each, shift every sample by a channel-specific offset.
2. Check if the result is within a per-channel safety range, if not, engage an emergency shutdown sequence.
3. Decimate each stream by 64 with a decent amount of antialias filtering, which boils down to a cascade of 3 4th order CIC filters per channel.
4. Phase-lock to one of these channels and generate f_mains*1024 using an NCO propelling a resonant filter sine wave oscillator.
5. Take another data stream at 310ksps, perform quadrature mixing, do the same amount of filtering and decimation on the resulting I/Q channels as in the case of the abovementioned monitoring channels.

Only the points 1-3 require at least 224 storage cells if implemented naively, point 5 adds another 44 cels, exceeding the limit of 256. I had to be very creative to fit it in the available memory space. I hadn't had enough free cells to store the coefficients of a biquad, but then realized that the PLL can go at high speed, which freed 4 cells occupied by the final comb section, so now it *might* be doable.

Best regards, Piotr

On a sunny day (Mon, 25 Sep 2017 17:16:11 -0400) it happened Phil Hobbs wrote in :

I dunno how many of those PLL or control loops I designed an build over the years. Many projects had one or more.

The OP was talking about software.. last one I did was a control system for altitude for my drone, it drives a 32 position DAC that can be tri-stated to control the 'up / down' throttle. It is just a few lines of asm, and I wrote it first time right. In PIC 18 asm:

; if abs(requested_altitude_decimeters_h:requested_altitude_decimeters_l to current_altitude_decimeters_h:current_altitude_decimeters_l ) then goto main_read_sector clrf REGA3 clrf REGA2 movff requested_altitude_decimeters_h, REGA1 movff requested_altitude_decimeters_l, REGA0 ; REGA3:REGA0 = requested_altitude_decimeters_h:requested_altitude_decimeters_l

clrf REGB3 clrf REGB2 ; signal to interrupt routine not to change these bytes one at the time bsf WAIT_UPDATING_ALTITUDE_FLAG movff current_altitude_decimeters_h, REGB1 movff current_altitude_decimeters_l, REGB0 bcf WAIT_UPDATING_ALTITUDE_FLAG ; REGB3:REGB0 = current_altitude_decimeters_h:current_altitude_decimeters_l

call subtract ; 32 bit subtract REGA - REGB -> REGA, return carry set if overflow, test bit 7 REGA3 for sign flag ; REGA3:REGA0 = requested_altitude_decimeters_h:requested_altitude_decimeters_l - current_altitude_decimeters_h:current_altitude_decimeters_l = correction factor ; this is positive if too low, then go up ; this is negative if too high, then go down

; remember sign bit in UP_FLAG

main_positive_alitude: bsf UP_FLAG btfsc REGA3, 7 bcf UP_FLAG

; if negative altitude things reverse, yes GPS gives negative altitude sometimes btfss NEGATIVE_ALTITUDE_FLAG bra main_positive_altitude ; how to handle GPS negative altitude, well what do you say, we go into hold tristate DAC out pin 19. and hold position sector movlw D'16' movwf VREFCON2 ; DAC out pin 19 tristate, HOLD bcf VREFCON1, DAC1OE bra main_loop main_positive_altitude:

; get ABS difference in REGA3:REGA0 call absa ; checks sign of REGA and convert negative to positive ; REGA3:REGA0 = abs(requested_altitude_decimeters_h:requested_altitude_decimeters_l - current_altitude_decimeters_h:current_altitude_decimeters_l)

movff REGA0, pa_error

; check if altitude error < 1.5 m clrf REGB3 clrf REGB2 clrf REGB1 movlw D'15' ; 15 dm, 1.5 m movwf REGB0 ; REGB3:REGB0 = 15

call subtract ; 32 bit subtract REGA - REGB -> REGA, return carry set if overflow, test bit 7 REGA3 for sign flag ; REGA3:REGA0 = abs(requested_altitude_decimeters_h:requested_altitude_decimeters_l - current_altitude_decimeters_h:current_altitude_decimeters_l) - 15

; REGA is SIGNED!

; test if in proportional range ; this is negative for abs altitude error < 15 btfss REGA3, 7 bra altitude_error_out_of_proportional_range

; WAS TEST ; movff pa_error, ttemp ; call tx_crlf ; movfw ttemp ; call print_w_ascii_dec ; movlw ' ' ; call tx_w ; movlw '1' ; btfss UP_FLAG ; movlw '0' ; call tx_w ; call tx_crlf ; movff ttemp, REGA0

; To create a proportional band ; if the error is smaller than 15 ; if going up ; add the difference to the DAC + 16 (makes range 16 to 31) ; else ; sutract the difference from the DAC + 16 (makes range 16 to 1) ; else ; if going up ; set DAC to maximum (= 0)

; note now always DAC out pin 19 enabled!!, throttle on remote control can still override due to series resistors.

; test if up or down required btfss UP_FLAG bra proportional_down

; proportional up ; add REGA0 (for sure < 16) to DAC 16 movlw D'16' addwf pa_error movff pa_error, VREFCON2 ; DAC to pin 19 bsf VREFCON1, DAC1OE ; do not wait till altitude reached, close enough, 1.6 meter either way, correct while moving to next sector / point bra main_test_end_of_data ; bra main_loop

proportional_down: ; subract REGA0 (for sure < 16) from DAC 16 movff pa_error, WREG sublw D'16' movwf VREFCON2 ; DAC to pin 19 bsf VREFCON1, DAC1OE ; do not wait till altitude reached, close enough, 1.6 meter either way, correct while moving to next sector / point bra main_test_end_of_data ; bra main_loop

altitude_error_out_of_proportional_range: ; test if need to go up or down ; flashing red and green indicates trying to get to specified altitude btg GREEN_LED

btfss UP_FLAG bra max_down ; max up ; set DAC to DAC_MAX_RANGE movlw DAC_MAX_RANGE movwf VREFCON2 ; DAC to pin 19 bsf VREFCON1, DAC1OE ; wait till altitude reached bra main_loop

max_down: ; set DAC to DAC_MIN_RANGE movlw DAC_MIN_RANGE movwf VREFCON2 ; DAC to pin 19 bsf VREFCON1, DAC1OE ; wait till altitude reached bra main_loop

You can see it flying an altitude controlled pattern here:

The smaller you make the proportional band the higher the gain in fact. The 'phase' is the altitude, How many times per second the code is executed is also important.

It is a bit 'fingerspitzengefuhl'.

It is not hard, I think Tim had a nice writeup here a while back about contol loops.

Now do not tell me it does not work ;-)

Good point!

Best regards, Piotr

Green: input, blue: VCO sine, orange: VCO cosine, red: the VCO control. The phase detector multiplies the input with -cosine in order to lock it to the sine waveform.

Best regards, Piotr

You can brute force the entire state space of VCO gains, loop filter coefficients, etc. in a few hours? I wouldn't have thought that possible, but hey PCs have gotten a lot faster lately...

Now you tell us, 50+ posts later.

With that sort of constraint, I'd probably injection lock it to make f_mains*2 and use a Tinylogic flipflop to get 50% duty cycle.

Cheers

Phil Hobbs

I think what confuses folks is analyzing something where phase is the variable instead of a voltage or a current. I know it certainly confused me some 50 years ago when I first confronted it.

I wrote this up for a client 14 years ago...

To get really down and dirty I would suggest, as many here have already opined, buy Gardner's book...

"Phaselock Techniques" 2nd Edition, 1979 Floyd M. Gardner ISBN 0-471-04294-3

I also have books by Wolaver, Best, Blanchard, and Brennan, but Gardner's is definitely the clearest. ...Jim Thompson

What's "pi*R_e" in this context?

Sorry. Couldn't find the original drawing, but Re is the resistor in the current mirror that determines the _peak_ current in the charge pump... the _width_ of that pulse is the phase error. ...Jim Thompson

I bought a copy of Gardner's book yesterday. 2nd ed. ~$16.

George H.

The question was not about how to create a PLL given the constraints, I have already had a working one, to my surprise much better than I expected. The not mentioned previously immunity to noise is just shocking. My problem was the divergence of the real design and the available PLL theory materials.

You once told me to go and experiment with PLLs, as there is a lot of fun. There is, indeed. :-)

There are 192 macrocells available, no need to add any external part. And it is my main objective: a single chip solution. The problem would have been trivial on a decent DSP or an FPGA, but they require multiple supporting chips (RAM/ROM/ADC/opamps) and hence are not an option. Even Zynq is not close enough, so PSOC5LP is the only game in town, despite the pile of its obvious downsides.

As always, thank you all for your input, I've learnt a lot.

Best regards, Piotr

Yes, the chip is only 24 bits (signed), which leaves about 8 million useful possibilities per dimension, as the negative ones usually don't make sense or are just manifestations of some symmetries. Some other parameters, like the VCO gain you mention, are tightly constrained by e.g. the requirement of the resonant filter stability. It leaves just several hundreds options, not millions. As always, the trick is not to simulate the entire state space, but to cut early the dead ends with a a bunch of good heuristics, in turn driven by numeric experiments. If the problem is still too big, there are probabilistics methods like the well-known Monte Carlo algorithms which allowed the bright guys to devise a working nuclear device using a computer comparable to a Cassio pocket programmable calculator.

I am a computer scientist by breed and profession, so I am used to practical applications of these techniques, because it is the way I earn money. Electronics is just my spare time activity.

And they come in hundreds. It is a quite typical habit in many companies to let the secretaries etc. boot Linux on their computer when they leave, so you get a powerful ad hoc computing cluster for the entire night. At least several 200MW power generators were optimized that way. :-)

But it is the extreme, professional end of the spectrum, the VCO state space simulation takes less than two minutes on a single thread. No need to go parallel, I can wait a night or two. Moreover, a local optimum is fine, don't need to undertake any heroic attempts to beat it by another epsilon.

Best regards, Piotr