[GPS_Standard] Phase Detector Timing

[Bob Stewart]

>From the beginning of my testing, something has just not seemed right.  Whenever I had the DAC update more often, its value would start auguring into the ground.  I switched to counting each 1PPS and noticed the same thing:  When I wait 16 counts to change the DAC, things behave pretty good, but when I start increasing how often the DAC updates, the DAC starts going grinding down.

I think I've tracked it down to the section that writes to EEPROM.  If I remember correctly, that essentially freezes the chip while it's writing.  I don't know whether it's getting false counts or something else is happening.  I've just put a branch around the code in that section, and I think I'm starting to see better timing counts coming from the code, though I haven't tested extensively.  I wonder if there are any other gotchas in there?  I believe that Bert got around these issues by giving it one time slice to "settle down" after he had changed anything.  I can't do that, so I've got to get all of these irregularities out of the mainstream.  I will probably add code into the alarm clear section to update the EEPROM.  As I am now down to counting on each 1PPS, I could skip counting for one pulse during any needed EEPROM writes.

Just a note on my testing setup.  Getting a 100% stable and accurate counter to count down to the granularity needed for this is practically impossible; at least for a retiree.  I did come across a 5335A, but that only gave me a relative reading.  I finally realized that I could feed the 1PPS signal to the B channel on my 5334B (it's quieter) and set it for "RATIO A/B" to get a reliable count every other second.  Visually, what I'm looking for is a count that is mostly 10.000000 MHz but with the occasional 9.999999MHz and 10.000001MHz in roughly equal proportions as the phase errors happen in the UT+.

Bob - AE6RV