[TangerineSDR] Notes from PSWS / TangerineSDR call

Tue May 25 10:35:19 EDT 2021

Hi John,

  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.

73
Phil W1PJE

On Tue, May 25, 2021 at 10:28 AM John Ackermann N8UR via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> 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
> >
> >
>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>

-- 
----
Phil Erickson
phil.erickson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20210525/85779361/attachment-0001.html>