[GPS_Standard] GPSstd_PLL New Version

[Bob Stewart]

I've put a new version on my website at "http://www.evoria.net/AE6RV/GPSstd_PLL/".  Look in the "Experimental" directory.  

First off, I have added a long needed Copyright statement to the code.  This is to protect Bert, Me, and you, the user.  It is there to ensure that you will continue to have access to the source code.  I have decided to use the Lesser GPL, as that seems to best reflect Bert's stated intent that everyone have access to the software for whatever use they might get from it.

Secondly, why Experimental?  Well, because it's a rewrite of the decision code into what is called a State Machine, and it's the first SM I've ever written.  The previous version had three stages.  The first stage was the warmup period.  This was followed by a period of time in Unlocked state, and then a transition to Locked state when 96 seconds had elapsed since the previous update to the DAC.  It worked well enough and locked pretty quickly, but when it reached what I will call "best solution", its stability was greatly influenced by the sawtooth error in the timing receiver.  So, I added a fourth stage, which hopefully eliminates this instability, or at least mitigates it enough to be worthwhile.  

I have called this "Tick Tock PLL" without giving much explanation.  Here goes:  The timing receiver outputs a pulse approximately every one second.  I say approximately, because it's accuracy varies by up to +/- 52 nanoseconds for each pulse.  This is not cumulative; each pulse will only be up to +/- 52 ns from the true time tick.  In the GPSDO, the OCXO runs at 10MHz.  Under perfect circumstances, every 1PPS pulse would see exactly 10,000,000 cycles from the OCXO.  But the sawtooth and the stability of the OCXO, as well as the 14 bits of the DAC conspire against perfection.  In previous versions, I used the count error in successive seconds to decide whether or not to increase or decrease the DAC voltage.  If there were two plus counts in a row (i.e. 10,000,001 or more counts from the oscillator) or tow minus counts in a row, I would change the DAC voltage.  However, because of the sawtooth, sometimes there are false pluses and false minuses. 

In viewing the data, it seemed to me that these sawtooth errors appeared as a two plus counts in a row (ignoring any zero counts) immediately followed by a minus count, or vice versa.  So, this Experimental version waits one more second for a veto from an opposite count.  If there is no veto, then the update is passed.  

The code decides to go from the small state machine to the large one with a simple test for best solution:  when it is in locked state and when the DAC, at sometime in the past, has been both incremented and decremented.  What this means is that the DAC has overshot best solution (perfect frequency) and has corrected in the other direction.

I implemented these as state machines.  If you know how to read one, then the code is more transparent.  If not, then sorry.  =)  Writing this type of code just gets too complex when you have all these decisions to make, so a state machine should make it easier to debug and to maintain.

In this version, I have added an extra two digit field to the display at the end.  The first digit is the state of the small state machine when it is active.  The second digit is the state of the large state machine when it is active.

Feel free to contact me if you have any questions.  I hope it works for you.  I have been very pleased with the results I've seen over the past couple of days.

Bob - AE6RV