[TangerineSDR] Notes from PSWS / TangerineSDR call

[John Ackermann N8UR]

Following up on last night's conversation about holdover... (This is way 
longer than anyone wants to read, but I think this is a good opportunity 
to document the holdover details.)

As background, in a traditional GPSDO you get a free low-jitter PPS 
signal derived from the XO because the the phase comparator uses GPS PPS 
and local PPS as inputs and steers local to match GPS.  In holdover, the 
local PPS remains locked to the XO without any glitches or phase jumps 
(in theory).  The "PPS OUT" spigot on the GPS is normally the local 
signal, as it will have lower jitter than the GPS PPS.

Our scheme doesn't use PPS for phase comparison, so we don't get that 
free signal to work with.  Therefore, PPS during holdover needs to be 
derived elsewhere.

When I tested the u-blox F9T to see what its PPS output looked like when 
GPS lock is lost, the result wasn't pretty.  The PPS phase jumped 
quickly away from the locked signal and bounced around after that.  We 
don't want to use the no-lock GPS PPS for timing.  (I should have 
recorded some data but didn't; will try to do so next time I have the 
gear set up.)

So, we don't want to rely on the GPS PPS during holdover.  To make 
things more interesting, there is no hardware signal from the GPS to 
reliably indicate lock status.  The status is available via both the 
u-blox binary and NMEA message streams, but that requires computation to 
detect.

Several NMEA messages include a field that indicates fix/lock status: 
GLL, RMC, GGA, VTG, and GNS, though the return values are different 
(some return "V" for invalid, others numeral 0, and in one case "N").

The u-blox binary messages that provide fix/lock status include 
UBX-NAV-PVT, UBX-NAV-STATUS, and UBX-NAV-TIMEUTC (there are probably 
others).

u-blox recommends that a 1 Hz rate be used for messages, and I do not 
think that polling more frequently will result in faster loss-of-lock 
detection.

Last night I said that the u-blox receivers didn't have a way to control 
PPS when lock is lost.  That was in error.  The UBX-CFG-TP5 message 
allows you to set different pulse parameters for when the receiver is 
locked and unlocked.  So you can, e.g., set the pulse width to 0 in 
unlock to disable the PPS output.  Then we could simply test for 
presence of GPS PPS and respond accordingly.  I don't know if that's 
something we want to do, or not.  It's easily changeable via config, so 
we can experiment.

So, finally, after all that...

What Scotty and I have talked about is to have a counter in the Data 
Engine FPGA that derives a PPS signal from the 122.88 MHz clock (which 
comes from the GPSDO and has the holdover stability/accuracy of the 
TCXO), and use that as the system PPS.

At boot, and at reasonable intervals thereafter, the FPGA will check the 
GPS to determine lock status.  If it is locked, the FPGA will compare 
the phase of the local PPS to the GPS PPS, making an adjustment if 
necessary. [ Assuming normal operation the 122.88 will be loosely phase 
locked to GPS and there should be no time gained or lost, so adjustment 
should never be needed; this is primarily a sanity check. ]

If GPS lock is lost, the system PPS output will continue unperturbed and 
have the stability/accuracy of the TCXO in the CKM module.  When lock is 
regained, the FPGA will once again set the system PPS to be in phase 
with GPS PPS (whether this should be a jam-sync or steered is an open 
question).

Question: do we need to synthesize a timestamp message for holdover, to 
replace a GPS time message?  (e.g., will any service need a 
once-per-second current-time message?)

That's my story, and if you don't like it, well, I have others. :-)

73,
John
----

On 5/24/21 10:19 PM, Tom McDermott via TangerineSDR wrote:
> 
> Notes from PSWS / TangerineSDR call of 05-24-2021
> 
> 1. John and Scotty located a replacement TCXO for the clock module and 
> they are on order (the previous unit was not available for production). 
> Scotty received the 7-port Ethernet chip. The USB3 (mid August delivery) 
> and FPGA (date not yet committed) are the only components not yet promised.
> 
> 2. Discussion on power supply bypassing for low conducted noise. Scotty 
> will send Tom part numbers of the output bypass caps he is planning for 
> the +12v to +5v switcher.
> 
> 3. Discussion on PPS during holdover. John recommends having the FPGA 
> generate PPS from the synthesizer and update/synchronize that against 
> GPS PPS when GPS in-lock, and holdover when GPS out-of-lock. The new 
> TCXO has good holdover performance ( +/- 40 ppb over 24 hours at 
> constant temperature).
> 
> -- Tom, N5EG
> 
>