[TangerineSDR] Notes from PSWS / TangerineSDR call
Jonathan
emuman100 at gmail.com
Wed May 26 21:07:07 EDT 2021
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