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. Cheers, David _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions