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
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
