Re: [chrony-users] Not getting time from gpsd

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Thu, 11 Aug 2016, Chris Greenman wrote:

> Ok I've got the new refclock line in place and statistics are logging.   I'll check it in a couple days.   
>
>
> Quick question on binary mode.   It's a ublox and GPSD supports it.   Would I get better results if I force
> the module into binary mode?

Maybe, maybe not. I doubt it would make that much of a difference. Now if you
activated PPS on it, that would make a difference of at least a factor of
1000. But then you may well not need that.
What your results say is that you now have an uncertainty of about 10ms. I
suspect ( but someone who knows the chipset better may be able to contradict
me) that binary mode will not be that much better.


> On Aug 10, 2016 3:24 AM, "Miroslav Lichvar" <mlichvar@xxxxxxxxxx> wrote:
>       On Tue, Aug 09, 2016 at 04:22:56PM -0400, Chris Greenman wrote:
>       > Ok I set it to 0.0065 offset.  Here's my chrony.conf
>       >
>       > pool pool.ntp.org
>       > driftfile /var/lib/chrony/drift
>       > allow
>       > refclock SHM 0 refid GPS offset 0.065
>       > #refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2
>       > makestep 1 -1
>       >
>       > and here is the chrony sources output:
>
>       > ===============================================================================
>       > #* GPS                           0   4   377    12  +2112us[+2967us] +/-
>       >  325us
>       > ^- orchid.sidereal.ca            2   6    17    19    +11ms[  +12ms] +/-
>       > 40ms
>       > ^- static-96-244-96-19.bltmm     2   6    17    19    +11ms[  +12ms] +/-
>       > 40ms
>       > ^- hydrogen.constant.com         2   6    17    18    +14ms[  +15ms] +/-
>       > 32ms
>       > ^- host2.kingrst.com             2   6    15    19  +9078us[  +10ms] +/-
>       >  100ms
>
>       Ok, so now it seems the correction should be actually about 10
>       milliseconds smaller. This means the GPS offset is not very stable,
>       which is normal with message based (e.g. NMEA) samples. The value
>       specified by the delay option should include this interval. If you set
>       it to 0.2, the assumed error of the source will be +/- 0.1 seconds. As
>       long as the GPS time (corrected by the offset) doesn't move from the
>       true time by more than 0.1 seconds, the error interval will contain
>       the true time and the source will always agree with other good
>       sources.
>
>       If you enable the statistics log and run it for few days, you will
>       probably better see how much the offset moves. If you don't have time
>       for that, I think delay of 0.2 seconds should be good enough.
>
>       The recommended refclock line in this case would be:
>
>       refclock SHM 0 refid GPS offset 0.060 delay 0.2 minsamples 64
>
>       The assumed error of the GPS source will now be similar or larger than
>       the NTP sources, so if they are online, GPS should be ignored or
>       combined with them (+ symbol in the sources output). Only when the NTP
>       sources are offline the synchronization will use GPS alone.
>
>       --
>       Miroslav Lichvar
>
>       --
>       To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
>       with "unsubscribe" in the subject.
>       For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
>       with "help" in the subject.
>       Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.