"David J Taylor" <[email protected]> writes:
>George R. Kasica wrote: >[] >> Next step....I added back GPS NEMA data without the gpsd daemon (I >> don't pass the data out to anywhere so there's no real need for it) >> >> and I see >> >> # ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> xGPS_NMEA(0) .GPS. 0 l 13 16 377 0.000 -616.37 >> 10.466 >> *SHM(0) .PPS. 0 l 14 16 377 0.000 -0.557 >> 0.712 >> eagle-local 192.168.1.7 2 u 36 64 377 0.153 -44.398 >> 0.607 >> apollo-local 192.168.1.7 3 u 24 64 377 0.250 -16.713 >> 1.912 >> -mirror 209.132.176.4 2 u 29 64 377 10.272 6.391 >> 135.974 >> +tesla.fireduck. 198.82.1.202 3 u 28 64 377 36.123 2.841 >> 115.565 >> +rikku.vrillusio 209.51.161.238 2 u 21 64 377 38.531 -3.260 >> 156.267 >> >> >> I have good PPS and am getting GPS NEMA in as well but the offset for >> the NEMA data seems quite large....what would I do to fix that?? >> >> George >George, >On my FreeBSD system, the ntpq -p output looks like this (some servers >omitted): > remote refid st t when poll reach delay offset >jitter >============================================================================== >-utserv.mcc.ac.u 193.62.22.98 2 u 58 64 377 25.548 3.732 >2.715 >*GPS_NMEA(1) .PPS. 0 l 52 64 377 0.000 0.002 >0.008 >With just the reference clock type 20, I get the accuracy needed. The PPS >line from the GBS-18 LVC is wired to the DCD line of the serial port. In >my ignorance, I don't see why you even need the SHM driver, but as I said >before, I'm no expert! I don't see why my system picks up the PPS from >just the type 20 driver, and yours does not. Because you have the PPS kernel patch installed or it was automatically instaled in BSD? The OP does not and does not want to. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
