I CAN hook it up for PPS but it will require cracking open the puck and
it's not that crucial for my use anyway.
On Thu, Aug 11, 2016 at 6:39 PM, Bill Unruh <un...@physics.ubc.ca> wrote:
> 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
> 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
> 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
>> > 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
>> it to 0.2, the assumed error of the source will be +/- 0.1 seconds.
>> 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
>> 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
>> the NTP sources, so if they are online, GPS should be ignored or
>> combined with them (+ symbol in the sources output). Only when the
>> sources are offline the synchronization will use GPS alone.
>> Miroslav Lichvar
>> 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.