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

[Chris Greenman <chris.m.greenman@xxxxxxxxx>]

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 <unruh@xxxxxxxxxxxxxx> 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" <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@xxxxxxxxxxfamily.org
      with "unsubscribe" in the subject.
      For help email chrony-users-request@xxxxxxxxxxfamily.org
      with "help" in the subject.
      Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.