Re: [gpsd-dev] RC for DRIFT message

[Gary E. Miller]

Yo Eric!

On Sun, 22 Feb 2015 16:27:39 -0500 (EST)
address@hidden (Eric S. Raymond) wrote:

> I think top of the agenda for the next cycle is the additional report
> that Gary and Hal want for time service.  This, as I understand it,
> should do for in-band time reporting what the PPS message does for
> PPS - that is, report the offset between in-band GPS time and the
> system clock.

Works for me.

> Almost everything about this feature is easy to specify.  We can call
> it DRIFT or CLOCKDRIFT and it can have the same members PPS does -
> second and nanosecond parts for real (GPS) and CPU clock time.

Or call it TOS (for Top of Second) as some will just use it to
frame cycles.

> The question is when it should be emitted. Plausible candidate times
> are:
> 
> * When the first I/O from the report burst for a second is received.

That first I/O would need to contain a verifiably valid timme stamp.

So a GPRMC would work as it tells us the time and that the fix
is valid.

A GPGSV would not, it tells us the fix is valid, but not the time.

> * When the report burst for a second is done and the other reports
>  are omitted.

The message is time stamped so a little delay ( < 1 Sec) probably
acceptable.  The problem is knowing when you are really done without
having already seen the next second.

> Which do you guys actually want? I would favor the second - it fits
> into the existing logic better - but either will be relatively easy.

My gut feel is ASAP.  Chronyd can slew the system clock more than 8%,
so the longer a report sits unsent the harder it is to calculate what
an offset relative to old system time means relative to present system
time.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588