On 2021-06-23, Jim Pennino <j...@gonzo.specsol.net> wrote: > William Unruh <un...@invalid.ca> wrote: >> On 2021-06-23, Jim Pennino <j...@gonzo.specsol.net> wrote: >>> William Unruh <un...@invalid.ca> wrote: >>>> On 2021-06-23, Jim Pennino <j...@gonzo.specsol.net> wrote: >>>> ... >>>>> >>>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse >>>>> available from Amazon for $14, uses the Windows 10 native driver so it >>>>> works with Meinberg ntp, and keeps the time within single digit >>>>> milliseconds without any other servers. >>>> >>>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy, >>>> after correction for the NMEA delay is probably in the 10s of ms, not >>>> their claimed microsecond. But certainly for most people ms is more than >>>> enough accuracy. >>>> >>> >>> Correct, no PPS. >>> >>> From short term (day or so) testing looking at peerstats data: >>> >>> Samples: 3914 >>> Avg offset: -0.00190137 >>> Std dev: 0.00921412 >> >> The problem is that that does not test the accuracy, just jitter. Ie, >> the time could be off by a century, but it is repeatable, so ntp says >> that the offset and standard deviation is small. >> You need to compare with another time source that is known to be more >> accurate than yours. Typically nmea signals are delivered late and the >> length of the signal is long delaying things still more, expecially if >> you choose an nmea sentence which reports lots of information, not just >> the time. > > I didn't bother with the full story as I wanted to be brief unless > someone had specific questions. > > A bit more detail: > > For testing purposes, ntp was configured to use my machine that has a > real PPS GPS and about a half dozen public servers, most of them stratum 1.
OK, sounds good. > > I also enabled all the statistics files. > > Initial, i.e. an hour or so, testing was with standard linux utilities, > i.e. ntpq, ntpstat, ntptime, for a sanity check and a tweek of the fudge > value, which came out to 0.027. That is fast. Hardly enough time to send the nmea sentence. But it must be working faster than 9600Bd (serial port speeds). > > After several days I ran a pile of sed/awk scripts to look at the > statistics files and came to the conclusion that the absolute time error > was always less than about 5 ms and typically around 1 ms, which for $14 I > condider good enough. > > FYI I have tested a several other generic USB GPS pucks and found the > jitter to be over an order of magnitude greater than this device with > fudge times in the order of 0.500 and time errors in the several 10s > of ms. Yes, that is what I would expect. > >>> >>> ntpq typically shows offset and jitter at about 1 and the satellites in >>> view are usually 14 or more with the puck in a window sill. >> >> And that means that the processor in the gps receiver has to work harder >> and delays the report of the NMEA even longer. Now of course you may not >> care -- 100ms may be perfectly acceptable (It is far more accurate than >> a wrist watch for example) and then my comments are entirely irrelevant. >> If you want higher accuracy however, then they start to become relevant. >> Hook it up to the network and use some of the low stratum sources to get >> the time. That should be accurate probably to better than a ms. That >> will allow you to calibrate your gps delay and tell ntp to subtract the >> persistant offset from the gps signal, and improve your accuracy. >> >> Again that is only important if you have some reason to care. Again, if >> accuracy to the nearest second is good enough, ignore this. > > See above. > > I am assuming that the fudge time of 0.027 versus the typical generic GPS > puck time of 0.500 means this thing is processing things much faster. > > FYI all this is done on a USB 2.0 interface. Certainly if it used the usb channel at its full speed, that should be fine. I always thought that gps ran at serial port speeds, but clearly that is not true. > >>> >>> That is from a linux PC where there are more tools for testing things. >>> >>> The reason I bought it is that it is advertised to work with the Windows >>> native USB driver, which produces a virtual com port, which makes it >>> usable with Meinberg ntp without any other drivers or software. >>> >>> I have yet to do any Windows testing other than to verify it does work, >>> but I see no reason why Windows would be much different. >> >> Probably not. But again, testing it against some good network ntp >> sources should give you an idea of how well it is doing, if that is >> important. >> Of course we all like our stuff to be better than others. My system, >> using pps from a gps is probably goot to a few microseconds. Do I need a >> few microsecond accuracy. No. Even ms accuracy would be way more than I >> need. But I like seeing how far I can push stuff. My only defence is >> "its a hobby". > > From my analysis of my real PPS GPS system, the absolue time on that > machine is typically accurate to about a microsecond with a standard > deviation of about 0.8 us. > > The time accuracy I actually need for stuff I do is in the order of > about 50 ms, but like you, I too like seeing how far I can push stuff, > especially for $14. Yes, it certainly is impressive. > > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
