It's not necessary to use refclock_process() if the driver creates
its own l_fp timecode timestamp and uses refclock_process_offset(). I
was considering removing refclock_process() when I added the rollover
workaround to the trimble driver, but then I read this:
https://bugs.ntp.org/show_bu
Hal Murray :
>
> >> We could test fixup software by setting the system clock
> >> ahead far enough to look like GPS had rolled over.
>
> > What kind of fixup? I looked long and hard at this problem in the context
> > of GPSD. I never found one that wasn't as bad - or worse - than relying on
> >
>> We could test fixup software by setting the system clock
>> ahead far enough to look like GPS had rolled over.
> What kind of fixup? I looked long and hard at this problem in the context
> of GPSD. I never found one that wasn't as bad - or worse - than relying on
> the sysrem clock date.
I
Hal Murray :
>
> >> How many of the NMEA devices have GPS rollover problems?
> >> (either now or soon)
>
> > It's impossible to tell. When a device will roll over is, because of the
> > pivot-date trick, not a function of its hardware type but of its firmware
> > release. --
>
> Are there any
>> How many of the NMEA devices have GPS rollover problems?
>> (either now or soon)
> It's impossible to tell. When a device will roll over is, because of the
> pivot-date trick, not a function of its hardware type but of its firmware
> release. --
Are there any known examples?
I have a coll
Hal Murray :
> How many of the NMEA devices have GPS rollover problems? (either now or soon)
It's impossible to tell. When a device will roll over is, because of the
pivot-date trick, not a function of its hardware type but of its
firmware release.
--
http://www.catb.org/~esr/";
How many of the NMEA devices have GPS rollover problems? (either now or soon)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Hal Murray :
> The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
> not an integral number of years. The day and month are garbage too.
Right, not the same problem.
> I agree this is a mess. I think we need a flag to go with with the year.
> Then we can update the dr
devel@ntpsec.org said:
> No? Well, I just did. Fsck...me...sideways! It's true. The reason all
> those old, busted Y2K-afflicted refclocks worked is that ntpd really does
> ignore the year part of clock timestamps.
The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
Hal wrote:
>Here is a comment in refclock_process_f
>/*
> * Compute the timecode timestamp from the days, hours, minutes,
> * seconds and milliseconds/microseconds of the timecode. Use
> * clocktime() for the aggregate seconds and the msec/usec for
> * the fr
10 matches
Mail list logo
