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" <mlich...@redhat.com> 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
> 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] +/-
> ^- orchid.sidereal.ca 2 6 17 19 +11ms[ +12ms] +/-
> ^- static-96-244-96-19.bltmm 2 6 17 19 +11ms[ +12ms] +/-
> ^- hydrogen.constant.com 2 6 17 18 +14ms[ +15ms] +/-
> ^- host2.kingrst.com 2 6 15 19 +9078us[ +10ms] +/-
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
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.
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.