[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