<div dir="ltr">Hi John,<div><br></div><div>  I take it the strange PPS behavior when unlocked was discovered on the bench, and no uBlox app note describes that particular state?  (Of course, you understand why I am asking - I have certain other efforts that would greatly benefit from this information.)  I hope that you write that up sometime so I can pass it along.</div><div><br></div><div>73</div><div>Phil W1PJE</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 25, 2021 at 10:28 AM John Ackermann N8UR via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Following up on last night's conversation about holdover... (This is way <br>
longer than anyone wants to read, but I think this is a good opportunity <br>
to document the holdover details.)<br>
<br>
As background, in a traditional GPSDO you get a free low-jitter PPS <br>
signal derived from the XO because the the phase comparator uses GPS PPS <br>
and local PPS as inputs and steers local to match GPS.  In holdover, the <br>
local PPS remains locked to the XO without any glitches or phase jumps <br>
(in theory).  The "PPS OUT" spigot on the GPS is normally the local <br>
signal, as it will have lower jitter than the GPS PPS.<br>
<br>
Our scheme doesn't use PPS for phase comparison, so we don't get that <br>
free signal to work with.  Therefore, PPS during holdover needs to be <br>
derived elsewhere.<br>
<br>
When I tested the u-blox F9T to see what its PPS output looked like when <br>
GPS lock is lost, the result wasn't pretty.  The PPS phase jumped <br>
quickly away from the locked signal and bounced around after that.  We <br>
don't want to use the no-lock GPS PPS for timing.  (I should have <br>
recorded some data but didn't; will try to do so next time I have the <br>
gear set up.)<br>
<br>
So, we don't want to rely on the GPS PPS during holdover.  To make <br>
things more interesting, there is no hardware signal from the GPS to <br>
reliably indicate lock status.  The status is available via both the <br>
u-blox binary and NMEA message streams, but that requires computation to <br>
detect.<br>
<br>
Several NMEA messages include a field that indicates fix/lock status: <br>
GLL, RMC, GGA, VTG, and GNS, though the return values are different <br>
(some return "V" for invalid, others numeral 0, and in one case "N").<br>
<br>
The u-blox binary messages that provide fix/lock status include <br>
UBX-NAV-PVT, UBX-NAV-STATUS, and UBX-NAV-TIMEUTC (there are probably <br>
others).<br>
<br>
u-blox recommends that a 1 Hz rate be used for messages, and I do not <br>
think that polling more frequently will result in faster loss-of-lock <br>
detection.<br>
<br>
Last night I said that the u-blox receivers didn't have a way to control <br>
PPS when lock is lost.  That was in error.  The UBX-CFG-TP5 message <br>
allows you to set different pulse parameters for when the receiver is <br>
locked and unlocked.  So you can, e.g., set the pulse width to 0 in <br>
unlock to disable the PPS output.  Then we could simply test for <br>
presence of GPS PPS and respond accordingly.  I don't know if that's <br>
something we want to do, or not.  It's easily changeable via config, so <br>
we can experiment.<br>
<br>
So, finally, after all that...<br>
<br>
What Scotty and I have talked about is to have a counter in the Data <br>
Engine FPGA that derives a PPS signal from the 122.88 MHz clock (which <br>
comes from the GPSDO and has the holdover stability/accuracy of the <br>
TCXO), and use that as the system PPS.<br>
<br>
At boot, and at reasonable intervals thereafter, the FPGA will check the <br>
GPS to determine lock status.  If it is locked, the FPGA will compare <br>
the phase of the local PPS to the GPS PPS, making an adjustment if <br>
necessary. [ Assuming normal operation the 122.88 will be loosely phase <br>
locked to GPS and there should be no time gained or lost, so adjustment <br>
should never be needed; this is primarily a sanity check. ]<br>
<br>
If GPS lock is lost, the system PPS output will continue unperturbed and <br>
have the stability/accuracy of the TCXO in the CKM module.  When lock is <br>
regained, the FPGA will once again set the system PPS to be in phase <br>
with GPS PPS (whether this should be a jam-sync or steered is an open <br>
question).<br>
<br>
Question: do we need to synthesize a timestamp message for holdover, to <br>
replace a GPS time message?  (e.g., will any service need a <br>
once-per-second current-time message?)<br>
<br>
That's my story, and if you don't like it, well, I have others. :-)<br>
<br>
73,<br>
John<br>
----<br>
<br>
On 5/24/21 10:19 PM, Tom McDermott via TangerineSDR wrote:<br>
> <br>
> Notes from PSWS / TangerineSDR call of 05-24-2021<br>
> <br>
> 1. John and Scotty located a replacement TCXO for the clock module and <br>
> they are on order (the previous unit was not available for production). <br>
> Scotty received the 7-port Ethernet chip. The USB3 (mid August delivery) <br>
> and FPGA (date not yet committed) are the only components not yet promised.<br>
> <br>
> 2. Discussion on power supply bypassing for low conducted noise. Scotty <br>
> will send Tom part numbers of the output bypass caps he is planning for <br>
> the +12v to +5v switcher.<br>
> <br>
> 3. Discussion on PPS during holdover. John recommends having the FPGA <br>
> generate PPS from the synthesizer and update/synchronize that against <br>
> GPS PPS when GPS in-lock, and holdover when GPS out-of-lock. The new <br>
> TCXO has good holdover performance ( +/- 40 ppb over 24 hours at <br>
> constant temperature).<br>
> <br>
> -- Tom, N5EG<br>
> <br>
> <br>
<br>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>