David J Taylor wrote:
As Bill comments, I hope your milliseconds are actually microseconds!
Yes!
==
oGPS_NMEA(1) .GPS. 0 l 21 64 377 0.000 0.002 0.004
...
Thanks to everyone for helping me work thro
David J Taylor wrote:
...
> I would knock something up if there were enough interest, but it would
> be a Windows program so of limited interest to the OP.
That's the idea anyway. At the time, I was convinced the PPS signal was
showing clearly and it was but with the led transistor in backwards t
Rob wrote:
This is normal with NMEA. You never will get stable time when using
an NMEA time source. For that, you need PPS. Your PPS is apparently
not working.
It feels like I must be missing something here, running with -d I can
confirm that PPS doesn't appear to be working - after enablin
Hal Murray wrote:
How about turning off the PPS fudge flag so you know you are
using the text mode. Then watch it for a while and add a
fudge time2 to get it reasonably close. When that works,
turn the PPS back on.
I added time2 to zero out the offset and things looked good for about an
hour
David J Taylor wrote:
The reach = 0 suggests that the signals from the GPS are not being seen.
I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5
from the ntp-dev port.
I'm still seeing high offset and variable jitter.
204.9.54.119 2 u 283 512 377 86.5629.086
2.488
The -192.52 and 27.455 stats for the GPS have been constant for 72+
hours now. Any suggestions as to what the problem could be?
--
Kelsey Cummings - k...@sonic.net sonic.net, inc.
System Administrator
Kelsey Cummings wrote:
FreeBSD 8.0, with built in ntpd (4.2.4p5) and PPS_SYNC enabled with a
Garmic 18LVC.
I'm going to go install the devel version to see if this issue persists.
Serves me right not to notice the most recent thread. ;)
