[TangerineSDR] Notes from PSWS / TangerineSDR call
John Ackermann N8UR
jra at febo.com
Tue May 25 12:10:38 EDT 2021
Hi Phil --
Yes, I discovered it when doing testing here. I don't really know if
u-blox has said anything about it. I wish I had documented what the
performance was; I just remember running away screaming. I'll do
another test and capture some plots to share.
BTW -- it is also possible that I've missed something in the many
commands that are available in the F9T. There are several related to
timescales and time offsets, and a dearth of information about how to
actually apply them.
The disable-PPS-on-unlock is an example; you have to notice that they
allow you to independently set pulse/frequency parameters for locked and
unlocked states, and realize that you can set pulse width to 0 when
unlocked.
There's a journey of discovery awaiting anyone who trolls through the
u-blox datasheets and manuals. :-)
73,
John
----
On 5/25/21 10:35 AM, Phil Erickson wrote:
> 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 <mailto: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 <mailto:TangerineSDR at lists.tapr.org>
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
> <http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org>
>
>
>
> --
> ----
> Phil Erickson
> phil.erickson at gmail.com <mailto:phil.erickson at gmail.com>
More information about the TangerineSDR
mailing list