You might want to take a look at Misra, P., & Enge, P. (2012). Chapters 1 thru (3-5) in Global Positioning System: Signals, Measurements and Performance (Second Revised ed., pp. 91-144). Lincoln, Massachusetts, USA: Ganga-Jamuna Press.
The equations to solve for GPS have 4 unknowns, X, Y, Z, and time, so there must be at least 4 satellites in view for an accurate, 3D fix. My u_blox GPS device routinely has 20-27 satellites in view. With more than four sources of GPS coordinates available, GPS receivers usually use regression analysis to arrive at a fix. By the time one subtracts the means from each column of observations to precondition the X-matrix for inversion, and do the inversion, a regression analysis solution can take substantial time. In addition, that solution has to be transmitted to the user's computer, which also takes finite time. The above book has a small section on how to estimate these times. I believe it's possible that the 0.5 second difference between internal and external times is could be the result of not accounting for the delays incurred because the GPS device has to compute a solution and then transmit it to the receiver's computer. Charles Elliott -----Original Message----- From: questions [mailto:questions-bounces+elliott.ch=comcast....@lists.ntp.org] On Behalf Of William Unruh Sent: Wednesday, June 9, 2021 10:13 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Score is low and not raising On 2021-06-09, ProGeek <progee...@gmail.com> wrote: > On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote: >> On 06/08/21 20:42, Andreas Mattheiss wrote: >> > Hello, >> > >> > just as additional source of information: I have a similar setup >> > here (ublox PPS into a proper serial port of a PC) and I see a >> > stable offset of >> > -3 ms to 3 servers on the net (-3 ms to any of them). I'm using >> > ntpd though. >> > >> > Regards >> > Andreas >> > >> This is what I see at the ntp host here: >> >> chris@ntp-host:~ % ntpq -pn >> remote refid st t when poll reach delay offset jitter >> ===================================================================== >> = >> o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001 >> +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054 >> *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046 >> >> Using mini pc host with two network interfaces, internet and internal >> network facing. FreeBSD 12 with ttl pps into the serial port dcd line >> via a ttl to rs232 converter... >> >> Chris > this is what i see on sourcestats: > > 210 Number of sources = 7 > .- Number of sample points in measurement set. > / .- Number of residual runs with same sign. > | / .- Length of measurement set (time). > | | / .- Est. clock freq error (ppm). > | | | / .- Est. error in freq. > | | | | / .- Est. offset. > | | | | | | On the -. > | | | | | | samples. \ > | | | | | | | > Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev >=========================================================================== === > GPS0 12 6 176 -29.089 42.914 -8857us 1790us > SHM1 12 7 178 +0.000 0.010 -530ms 435ns > PPS0 12 7 178 +0.001 0.011 +3ns 445ns > blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms > 188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us > time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us > time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us > > if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers. Sorry but that is nuts. Your external sources are 500ms ( 1/2 sec) off from the internal ones. But that is probably because you told your system to screw up the internal sources. > > my settings are like this: > > # SHM(0), gpsd: NMEA data from shared memory provided by gpsd refclock > SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646 Why that offset? and why precision of 1e-1? > > # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd refclock > SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset > 0.5300 Why that offset? Also, why are you having both gpsd and pps0 delivering data? It is the same pps. And they fight each other-- when one interrupt is processing, the other one is locked out. This makes the accuracy of pps less than it should be (by a factor of about 10) Tell gpsd not to use the PPS. > > # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds > refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 > trust prefer delay 0.50 Why that delay? HOw about getting rid of all of the offset and delay stuff on your internal sources. > > something is off but i can't pinpoint what Sure is. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
