[TangerineSDR] Notes from PSWS / TangerineSDR call

[Jonathan]

After speaking with the dev of gpsd, he said uBlox will be shipping a
version of the F9T that does support L1L5. See here:
https://www.u-blox.com/en/press-releases/u-blox-announces-first-timing-solutions-based-l1-and-l5-gnss-signals

Jonathan
KC3EEY

On 5/26/21, Jonathan <emuman100 at gmail.com> wrote:
> Hi John,
>
> Thanks for this. On the Trimble RES SMT 360, the PPS output can be
> configured to disable if fix is less than 3 SVs or less than 1 SVs. There
> does not seem to be a spec on whether the PPS is steered or jam-synced.
> Because of the options to disable the PPS with less than 3SVs/1SVs, it
> might be jam-synced.
>
> In this case, it may be better to do exactly this for the Z9T, and simply
> watch for the loss of PPS based on the time the last one came in. This
> way, PPS can then be generated from the TCXO in the FPGA. I wonder if it
> would be better to look for less than 3SV/1SV in the Ublox packet stream.
>
> As for generating a time message, as long as the time is kept track of in
> the FPGA during holdover, it won't be needed for VLF (unless that's how
> you intend on keeping track of time during holdover), but may be needed
> elsewhere.
>
> On a different note, Trimble will be releasing their shiny and new RES 720
> GNSS timing receiver. Its PPS accuracy is claimed to be 5ns vs the 15ns of
> the RES SMT 360 that I use now. It is also an L1L5 band receiver. The
> Trimble guy told be that, rumor has it, L2 will be going away and L5 will
> be the new kid on the block. The RES 720 will release in July and I expect
> protocol and specs will be available too. Prices were available next week.
> They will also release a L1L5 antenna at the same time.
>
> The Trimble guy also told me there may be a version of the Z9T that
> supports L1L5. I wasn't able to find it.
>
> Thanks.
>
> Jonathan
> KC3EEY
>
> On Tue, 25 May 2021, John Ackermann N8UR via TangerineSDR wrote:
>
>> Date: Tue, 25 May 2021 12:10:38 -0400
>> From: John Ackermann N8UR via TangerineSDR <tangerinesdr at lists.tapr.org>
>> To: Phil Erickson <phil.erickson at gmail.com>,
>>     TAPR TangerineSDR Modular Software Defined Radio
>>     <tangerinesdr at lists.tapr.org>
>> Cc: John Ackermann N8UR <jra at febo.com>
>> Subject: Re: [TangerineSDR] Notes from PSWS / TangerineSDR call
>>
>> 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>
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>