[GPS_Standard] GPSstd_PLL - what's next

[Bob Stewart]

Hello the list,

This is rather long, so if you're not interested in details, this post is probably not for you.

Until now, my code has been focused on trying to get as accurate and stable a frequency as possible.  But, from the beginning, as the name GPSstd_PLL implies, I have been targeting phase lock.  I have code that I am not quite ready to release, but I thought I'd show a couple of plots: one showing the success I'm seeing, and the other a case when the code fails.

First, the success:  http://www.evoria.net/AE6RV/GPSstd_PLL/Plots/Success.png

The plot has a number of debug fields, so let me try to explain what's going on.  First of all, in green is the phase error line.  I've rotated it so that 180 degrees of phase error is sitting more or less at the "0" tic, on the right.  This makes it easier to see the lock to phase.  It rises a bit, which I think is probably drift in my HP 5334B, though I could be wrong.  This shows a 10MHz signal that is held pretty tightly to the phase of the 1PPS signal from my Adafruit Ultimate Breakout GPS Receiver.  But, there are a number of problems, if you look at it.  The biggest problem seems to be that the 1PPS signal suffers from sawtooth.  It's not nearly as bad as that from the Oncore UT+, in that it doesn't move more than 10ns - usually.  However, like the Oncore, it does tend to concentrate to one side or the other from time to time.  But, instead of a 370 degree phase jump, we see something more like an 18 degree (or so) phase jump, and the
 width of the phase scatter (thickness of the green line) decreases.  Since it moves to one side and narrows, the code has to move the frequency of the OCSO there and hold it in a very tight range, in order to keep the phase relatively centered.  This doesn't always work.

Next on the plot is the familiar blue line of the DAC voltage.  Notice that I have done some more tinkering with the binary search.  It now reaches the best solution about as quickly as is possible, without any double-backs, once the DAC stops moving in steps of 0x80.  If you follow the blue line, you will notice that suddenly it gets thick.  This is when I turn it into a PWM (Pulse Width Modulator).  Think of it like this: the OCXO is only tunable in steps.  In the case of the 14-bit DAC that Bert implemented, that works out to one step being equal to the OCXO's tuning range divided by 18384.  So, if 10MHz lies exactly on one of those steps, we are good to go.  But if, as is usually the case, it lies between two of those steps, we have a problem.  We can either accept the frequency error, or we can skip back and forth between the step on either side.  If we choose our timing carefully, we will, on average, get 10MHz.  If we are even more
 careful, we can keep the phase of our 10MHz signal within a very narrow range; which we have done on this plot.

But, there is a problem with this simple PWM.  What happens if, due to heat or crystal aging, the exact 10MHz spot moves to the next pair of steps over?  The answer to that is to move the PWM over so that it skips back and forth between the two steps surrounding our new perfect 10MHz spot, which you can see happening.

Unfortunately, there's a problem keeping the phase locked when the spot lies almost exactly on one of the steps.  In that case, our PWM will have to hunt back and forth between two pairs of steps to keep the phase correct.  You can see that happening throughout the plot, with it getting even more complicated as we add in the sawtooth from the GPS receiver.

In about the middle of the plot we have the red lines.  These lines indicate how long it's been since the most recent DAC update.  When it reaches 28 seconds (found by trial and error) the DAC is moved one more step in the same direction as it's most recent step from our PWM.  If that's not enough, then we lose phase lock; which will be seen in another plot.

At the bottom of the plot is a broken black line.  This is a "debounce" count.  It turns out that since we move the DAC in discrete steps, sometimes there is an overshoot big enough to get some invalid frequency errors.  Again, by trial and error, I am using a value of 6 to debounce the DAC update.  Essentially, after the hand of god moves the DAC to the next step pair, we have to wait until it's well and truly locked before we allow the hand of god to touch the DAC again.

And finally, at the top of the plot are brown lines.  These are proportional to the duty cycle of our PWM.  The lines going upward from the 30 tic (on the right) are the duty cycle for steps in the positive direction.  And conversely, the lines going down are the duty cycle for steps in the negative direction.  Notice that large movements of the duty cycle correspond with changes by the hand of god.  I don't have them directly tied to the movement yet, but I'm giving it some thought.  Getting more and more data out of the two simple inputs we have, and understanding what to do with it, has been a long and arduous task.

Now, the failure: http://www.evoria.net/AE6RV/GPSstd_PLL/Plots/PhaseBork.png


Well, it's not so much a failure, as a limit to our success.  Notice that there are two points where the phase line (green) suddenly jumps.  One is at about 11:18 and the other is at about 12:36.  Notice also, that if you grabbed the whole green line between them and moved it down, would seemingly join with the rest of the green trace, other than the phase skip, represented by the line cycling through 360 degrees.  This sudden movement was just more than my code could account for, and it lost phase lock for one full cycle of phase.  But, on the other hand, the result is no worse than what happens with the best of my frequency-control only code, so I can't really count it as a failure.

I'm not really sure what caused this sudden lurch, but I have my suspicions.  There is a command that you can send the Adafruit to set the Nav Speed Threshold.  This is supposedly a speed below which the Adafruit will not change its location, and thus it's computation of the 1PPS signal's phase.  But, due to fresh satellites appearing on the horizon, combined with multi-path errors, the Adafruit must eventually warp to wherever it's drifted to.  Eventually, it will warp back as it gets a better solution from the satellites, but the damage is done.  I had set my Nav Speed Threshold to 1.8, and I suspect that that's what caused this particular "tearing" of the phase line.  I'm not sure how, or even if I can address this.  I'll eventually have to set it back to 0.0 and see what the result is.


So, anyway, this is where I am with GPSstd_PLL, and it is the future direction of my code.  At this point, I think it will always be at least as accurate, frequency wise, as previously released versions.  There is the cost of phase noise, though, from the new PWM switching the DAC back and forth.  But, don't forget that Bert's least significant 4 bits are the result of dithering the internal PWM.  So, there is phase noise there, in any case - even from the hardware PWM.  Unfortunately, I don't have good enough test equipment to quantify it.  Nor do I have the budget for it. =)


I will try to clean up my code enough to release it before Christmas.  I've gotten most of the junk out of it, but there are comments scattered here and there, as is usual for me.  It will still not be Version 1.0.  Oh, by the way, I have achieved this phase lock mostly by butchering State Machine 2.  At this point, I don't plan to put that back in in its original form.  Like I said, my goal has always been to lock to phase.  But, if someone has a specific reason to get SM2 back, or to just turn off the phase lock PWM, I can accommodate that.

And I'd like to issue a plea for help testing this.  As it is, I can only test my setup.  If you have a good Universal Frequency Counter, like my 5334B, and a GPIB adapter, I'd really appreciate it if you could do some testing for me and give me the results.  I have sample code to run the GPIB, but it's coded for a Prologix Ethernet GPIB adapter running on Linux.

Thanks for reading through this long-winded mess.

Bob - AE6RV