[TangerineSDR] Notes from PSWS / TangerineSDR call

[John Ackermann N8UR]

Hi Jonathan --

Thanks for all that info!

While it's not written in stone, my thinking is that we should use the 
FPGA-synthesized PPS as the system PPS, rather than trying to switch 
between it and the GPS PPS.  The synthesized pulse should have lower 
jitter than even the best GPS-generated pulse, and won't suffer from 
sawtooth and other effects.  As important, it would make going into 
holdover seamless with no transient phase changes.  (Of course, coming 
out of holdover there will be some sort of sync activity, but that will 
be the case no matter what we do.)

The good news is that this decision is all in software/firmware so is 
something we can change if we think better of it.

The performance being quoted by Trimble is really good, but you need to 
be careful whether they are specifying jitter or actual accuracy vs. 
USNO.  The jitter can be reduced by higher clock frequencies, sawtooth 
correction, or other tricks, but the absolute accuracy depends on a lot 
of factors outside the GPS -- for example, do you know the delay of your 
antenna?  Or its tempco?  Or the tempco of the feedline?  At small 
nanosecond resolution, those become important factors.  I'm still 
inclined to believe the accepted wisdom that it's pretty easy to get 25 
ns or so absolute accuracy, but beyond that all these things need to be 
accounted for.  Getting below 10 ns is still in the realm of the 
common-view sync or two-way satellite sync methods, that are beyond most 
amateur capabilities.

Re L5 vs. L2, I need to update myself but the last I knew, it is 
possible that the civilian-accessible (but still encrypted) L2P code 
will be turned off later in this decade but no date has been given. 
There is still an awful lot of professional gear out there that relies 
on it so any change is going to be painful to many.  At this point, I 
don't think that any of the post-processing services like NRCan or OPUS 
will accept L5 data.

73,
John
----

On 5/26/21 9:07 PM, Jonathan 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
>>