[ntp:questions] Maximum time2 fudge value for NMEA refclock?

jimmyterrence jimmyterrence at gmail.com
Thu Jul 22 14:40:34 UTC 2010


On Jul 22, 9:11 am, Rhys <u... at mailinator.org> wrote:
> In article <mqilh7-0hi.... at p4x2400c.home.lordynet.org>,
> sn... at lordynet.org says...
>
>
>
>
>
>
>
> > Rhys wrote:
> > > In article <keqgh7-lgg.... at p4x2400c.home.lordynet.org>,
> > > sn... at lordynet.org says...
> > >> Rhys wrote:
> > >>> In article <i241ce$bu... at news.eternal-september.org>, david-
> > >>> tay... at blueyonder.co.uk.invalid says...
> > >>>> "Rhys" <u... at mailinator.org> wrote in message
> > >>>>news:MPG.26b018b8126a17a1989681 at news.optusnet.com.au...
> > >>>> []
> > >>>>> Sorry I should have said, GPS18x. Now that its stabilised its still 20-
> > >>>>> 80ms positive out in ntpq, so either my offset didn't actually change,
> > >>>>> or in the wrong direction.
> > >>>> For NMEA alone, no PPS, you may get poorer performance then just with
> > >>>> LAN/Internet sync.  Just to remind me, you're somehow measuring one system
> > >>>> against another?
>
> > >>>>> Seems a regular thing for it to jump crazy on startup, makes fine tuning
> > >>>>> a little impossible. PPS takes 30 minutes i think to reappear, it might
> > >>>>> be kernal PPSing in the background vs NTP trying to synch to NMEA..
> > >>>> What do you mean "reappear"?  To be present on ntpq -p at all, or to have
> > >>>> the synced tag "o"?
>
> > >>>>> I was thinking about turning on more NMEA sentences to see if it
> > >>>>> stabilises NMEA, but getting to the Windows boot on that isn't easy now,
> > >>>>> and this main PC has no serial.
> > >>>> I would have thought that the fewer sentences the better, to be honest,
> > >>>> although I've seen one recommendation to use the sentences which include
> > >>>> the number of satellites locked (IIRC) so that you can get a measure of
> > >>>> how marginal GPS lock might be.
>
> > >>>> My own tests showed that while a serial-to-USB converter made accuracy a
> > >>>> lot worse, it could still be better than a LAN connection alone.
>
> > >>>>  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
>
> > >>>> Cheers,
> > >>>> David
> > >>> Using both 20 MMEA and 22 PPS references. PPS turned off on the NMEA,
> > >>> Kernel mode on the PPS. They seem to operate almost independantly. PPS
> > >>> has zero reach, with no 'when' time, for about 1/2 an hour, it may be
> > >>> waiting for NMEA to get under a certain threshold, or for NTP to stop
> > >>> thrashing around the 500 PPM mark and align. Its present, just not doing
> > >>> anything.
> > >> That's what I see with separate gps and pps sources and
> > >> drivers. PPS does nothing until GPS (or other prefer peer)
> > >> is marked as selected. This can be an hour or more or never
> > >> depending what fudge offset is set for gps although with
> > >> 680ms fudge offset at moment, pps is selected and at reach
> > >> 377 in under 30 minutes from starting ntpd.
>
> Well its settled down ok now. Config NMEA offset is set around 600ms
> again, and using 'true' keyword for both as well. True on just NMEA
> causes PPS to drop out for being too far off. Noselects on all the lan
> clients.
>
> Therefore I've got a config at last that can self align on an airgapped
> lan, thanks to those who posted up their offsets and the link showing
> the offset chart, helps a lot for this kinda stuff.
>
> Now to figure out how to synch an LPRO...

I managed to set up a pps-enabled kernel on another linux box I have.
Same thing, works with gpsd, not with the NMEA driver. One thing I was
wondering, though, what pps pulse length does the NMEA driver seem to
want? I have the gps receiver set at 200 ms right now for gpsd.




More information about the questions mailing list