[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] RC for DRIFT message

From: Eric S. Raymond
Subject: Re: [gpsd-dev] RC for DRIFT message
Date: Mon, 23 Feb 2015 00:12:02 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Gary E. Miller <address@hidden>:
> Or call it TOS (for Top of Second) as some will just use it to
> frame cycles.

I like it.
> > 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.

I have cycle detection logic, so after the first full cycle I can set
a flag at the end of the report-ender sentence.  I have to do that
anyway to ship the JSON reports, which go out at that time.

That implies that when I *next* get I/O I can note the clock time, and
as soon as I have valid GPS time I can ship a TOS report.   This is
actually going to happen at the same time the unit-0 ntpshm report is
shipped, I think.

> 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.

Like I said, there's sentence-cycle detection.  Solved problem.

> > 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.

This can be done.  It won't even be hard.
                <a href="";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]