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

Reply via email to