[TangerineSDR] Notes from PSWS / TangerineSDR call

John Ackermann N8UR jra at febo.com
Mon May 31 16:24:30 EDT 2021


It'll be the FPGA on the Data Engine; there isn't one on the CKM module.

73,
John
----

On 5/31/21 3:55 PM, Jonathan wrote:
> 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
>>>>
>>



More information about the TangerineSDR mailing list