[time-nuts] u-Blox ZED-F9T block diagram or timing

[Tim S]

My apologies, I subscribed with a daily digest so I just got inundated with
responses.

I've cut down the the comments of interest and reply in-line below to
hopefully cut down on the reading.  Apologies if this is a mess.

-Tim

On Tue, Jan 7, 2020 at 9:00 AM <time-nuts-request at lists.febo.com> wrote:

>
> From: Bob kb8tq <kb8tq at n1k.org>
> "...If you go back in the list archives..."
>

Yep, I'll be doing that over the next week or so.


> "...Bottom line is that both the F9P and F9T have roughly a +/- 4 ns
> sawtooth range. The
> sawtooth error correction information out of the device will take this
> down a bit, but not
> quite as far as some of us hoped.  Since both devices are dual band, you
> can easily post process the data against various services. I put out some
> plots suggesting a pretty good level of performance doing this. (sub
> nanosecond at short tau). I have not revisited the project since then..."
>

What configuration was that using?  The TIMEPULSE outputs, or just the 1PPS
output?  My understanding is that the timepulse is probably something like
a DDS of fractional PLL rather than an integer divider.


> From: "Forrest Christian (List Account)" <lists at packetflux.com>
> "...For a few grand you can get an off the shelf fs740 or something
> similar,
> probably with a rubidium timebase.  But I get the impression this is more
> of a learning experience..."
>

Exactly that - something around the lines of "knowledge without
understanding is meaningless".  I want to understand a good timebase
without checking into a college radio astronomy project for 10 years.  Best
way I can think to do that is get my hands as dirty as possible as fast as
possible - which is probably the same as what I'd have to do at one of
those programs.  I have future projects where I think timing of going to be
very important so I want to prepare myself for dealing with that and
recognizing time stability issues.  I may pick up an FS740 anyway just to
have a production reference to do some local measurements against.  I have
already been in touch with SRS about OCXO and Ru sources (I'm in the S.F.
Bay Area, they are local).

"...One thing which it took me a while to wrap my head around is that for
> frequency, sawtooth error generally disappears for a lot of definitions of
> reasonable accuracy.  Of course this is somewhat simplified and the devil
> is in the

implementation details..."
>

I get that - a nanosecond of error over say 18,000seconds is kind of lost
in the power supply noise and oscillator aging and thermal effects if the
HW design is off.


> "...As I'm sure others will point out, if you're using certain receivers,
> then
> sawtooth correction data is available to you which will enable further
> correction..."
>

I'd like to see if the uBlox engine can be "tapped" somehow to get around
the sawtooth quantization errors on 1PPS in the first place.  For $200, it
doesn't seem too bad to experiment with, even to destruction of the
device.  Even something like a debug register that can be flipped to send
out the engine clock to a "reserved" pad would be extremely interesting.  I
recall reading the Jupiter engines had a 10kHz GPS engine derived clock
that made for a very robust and simple PLL GPDO solution.  That seemed like
a good direction to steer.

From: Hal Murray <hmurray at megapathdsl.net>
> "...Check out hanging bridges. :)..."
>

That's why I think I'm on the right track in my comment above with trying
to get deeper into the ZED-F9T hardware to get access directly to the high
speed GPS engine clock(s).  I have a working theory that if the engine
actually runs at 384MHz and that time is aligned to the GNSS constellations
- I can do some analog division (something like stratch-built Regenerating
Dividers) to get down to 16MHz and 6MHz to pump into an RF mixer and get
out a 10MHz side band which is phase aligned to the GPS engine.  but it's
entirely possible that I'm crazing for thinking that. ;-)

From: jimlux <jimlux at earthlink.net>
> "...How to search archives effectively with Google.. "site:febo.com" ..."
>

Thanks ;-)


> From: Michael Wouters <michaeljwouters at gmail.com>
> "...There's a TDEV plot here:
> http://www.openttp.org/scripts/blog.php
> PPS measurements were post -processed using the sawtooth corrections..."
>

Very interesting, thanks!


> From: Bob kb8tq <kb8tq at n1k.org>
> "...For a rubidium, the sawtooth error may or may not be as big a deal as
> for an
> OCXO. With an OCXO your loop time constant is likely below an hour..."
>
>
Yes, I recall I've been reading that something like the SRS SC10 OCXO has
better stability than their PRS10 Rubidium below about 20 seconds interval
and the PRS retains better stability than terrestrial GPS receiver derived
clocks below about 20 minutes.  They don't seem to be on board with
customization in low volumes (not a surprise at all) - so despite the PRS10
having an OCXO internally, it's lower performance/stability and can't be
factory replaced with a SC10.