[TangerineSDR] Notes from PSWS / TangerineSDR call
Jonathan
emuman100 at gmail.com
Mon May 31 16:40:06 EDT 2021
Thanks John!
Jonathan
KC3EEY
On Mon, 31 May 2021, John Ackermann N8UR wrote:
> Date: Mon, 31 May 2021 16:24:30 -0400
> From: John Ackermann N8UR <jra at febo.com>
> To: Jonathan <emuman100 at gmail.com>
> Cc: John Ackermann N8UR via TangerineSDR <tangerinesdr at lists.tapr.org>,
> Phil Erickson <phil.erickson at gmail.com>
> Subject: Re: [TangerineSDR] Notes from PSWS / TangerineSDR call
>
> 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