[time-nuts] Accuracy/drift of Garmin GPS 16 HVS 1 PPS output under invalid fix conditions...

[Tim Lister]

On Tue, Mar 12, 2019 at 4:01 PM Steve Olney <t0502 at internode.on.net> wrote:
>
> Hi Bob,
>
> On 13/03/2019 1:30 am, Bob kb8tq wrote:
> > Sorry if this is an ongoing / somewhat random dump of a bunch of things … I am not doing the
> > same sort of thing you are doing. That makes a lot of this a bit less focused than maybe
> > it could be.
>
> Thanks for your suggestions - they have been most helpful.  It was just
> when the discussion turned to Maser clocks and interferometry that I was
> concerned that the discussion had "dropped out of lock and drifting with
> many ppm" :-)

Hi Steve, let me first off say that what your doing is very
impressive; amateur radio astronomy of any sort is rare and to be
achieving results on sources many orders of magnitude fainter than the
"bright two" radio sources of the Sun and Jupiter is even more
impressive. My poorly worded and too brief comment was a poor attempt
to say that radio astronomers (pulsar and VLBI) tend to go to the very
extremes of clock precision - once the optical lattice clocks make out
of the national labs, I am sure they will be first in line... Sorry if
I dragged things off topic.

However even the VLBI people have offered hope for us mere mortals
minus a maser. A regular feature of the VLBI Workshops has been a
presentation on "Low Cost, High Accuracy GPS timing"; the latest
version is at  https://www.haystack.mit.edu/workshop/TOW2017/files/Seminars/tow-time2017.pdf
This may well be worth a look; once you get past all the maser stuff,
they show that cheap (<$100) ublox6 and 8 chipsets with correction of
the sawtooth and some averaging can give few nanoseconds residuals .
>
> I simply want to know about the behaviour of the GPS 16 HVS under
> no-lock conditions.   I need that information to optimise a fail-safe
> mechanism in my software.  Basically, if there is a loss of lock I need
> to account for that.   In my application, it doesn't matter if the GPS
> unit drops out of lock as I can re-schedule the timing event to a
> slightly later time when a valid fix is present.  All that matters is
> that I have an accurate time-stamp.  It doesn't matter if that
> time-stamp is re-scheduled for a minute or two later.   However, if I
> know the drift of the 1 PPS output under invalid fix conditions I might
> not need to reschedule the timing event at all as long as the
> (tdrift/dt) * (how long the invalid fix has lasted) < 1 ms.  The value
> of tdrift/dt is the key to implementing this.

One other thing to look at may be OpenTTP (openttp.org) which is a
suite of software to drive commodity hardware and provide GPS Common
View processing. This would allow comparisons of your local clock used
for time stamping with GPS to (in principle) better accuracy than the
previously suggested NTP (still a good idea to run) and traceability
back to GPS and UTC. This would allow you to produce a sort-of
"steve2gps.clk" file which could be fed to the TEMPO2 software used by
astronomers to analyze pulsar timings and provide an extra level of
accounting for changes in your local clock, over and above the plan
above.

I have just started playing it with myself for a few days and have
been trying to document as I go
(https://adventuresinprecision.space/2019/03/13/adventures-with-openttp/).
I've added support for installing and running it on Raspberry Pi's and
I'm working on adding support for the ublox6 GPS modules
(configuration and logging seems to be working but not analysis yet)
and the HP5334B time interval counter (OpenTTP already has support for
the ublox M8T GPS chips discussed in the "Low Cost, High Accuracy GPS
timing" presentation and the TAPR TICC popular among list members).

>
> Thanks for your suggestions.
>
> Cheers
>
> Steve
>
> HawkRAO
>

Cheers,
Tim