[TangerineSDR] Notes from PSWS / TangerineSDR call

[Jonathan]

Hi John,

Thanks for the reply. I completely agree with you that the FPGA should 
generate the system PPS. Do you mean the FPGA on the clock module itself?

The RES SMT 360 has an option for cable delay compensation and there is a 
caveat that the 15ns timing accuracy is only achievable with precise cable 
delay compensation while running in over-determined clock mode. 
(Trimble's timing mode) I suspect that the 5ns spec (or pretty close to) 
is also achievable in the same manner with the RES720 when it's released.

If L2P is turned off, that reminds me of when WWVB started phase 
modulation and many professional WWVB receivers stopped working. There 
were phase correction options available, so I guess the solution here 
would be L5.

Thanks.

Jonathan
KC3EEY

On Thu, 27 May 2021, John Ackermann N8UR wrote:

> Date: Thu, 27 May 2021 17:57:53 -0400
> From: John Ackermann N8UR <jra at febo.com>
> To: Jonathan <emuman100 at gmail.com>,
>     John Ackermann N8UR via TangerineSDR <tangerinesdr at lists.tapr.org>
> Cc: Phil Erickson <phil.erickson at gmail.com>
> Subject: Re: [TangerineSDR] Notes from PSWS / TangerineSDR call
> 
> 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
>>> 
>