Relevant statistics:
1ms or better accuracy on a USB-connected GPS.
stm32f4 discovery board using a 10.5mhz internal timer is measuring the PPS interval from a Fastrax UP501 GPS reciever (claims "+/- 50 ns (RMS) accuracy"). The stm32f4 is connected via full-speed usb to a pc
First graph is a histogram of the number of cycles of the 10.5mhz timer between PPS signals. This covers 41k samples (over 14 hours) worth of data. Data for pulses that take longer than 1 second are ignored.
Relevant statistics:
mean: 10500787 Hz
std dev: 4.91
min: 10500774 Hz
max: 10500798 Hz
Conclusion: The stm32f4's clock is 73ppm-76ppm off. While the PPS signal is active (and this timer is adjusted for its long-term error), this timer should have an error of 6µs or less.
The stm32f4 board is configured to emulate a USB-serial adapter, and is printing the interval data to a PC. The PC timestamps each message recieved and this graph shows the histogram of the intervals between messages
I assume the clustering of samples is the USB polling interval. The software has a setting, "CDC_IN_FRAME_INTERVAL" set to 5, which controlls how often the stm32f4 responds to a USB poll. See run 2 for the results of changing it.
Relevant statistics:
mean: 1.000001 s
std dev: 0.002835 s
min: 0.994959 s
max: 1.004749 s
Conclusion: USB adds around 9.7ms worth of time uncertainty for this setup.
The PC also saves the microsecond portion of the timestamp. PC is configured to get its time from the internet via NTP, so this next graph contains both the USB polling errors (of ~9.7ms) as well as any internet-influcened NTP errors (error between 1ms and 22ms for the sources configured). Ideally, this graph would be 100% of samples at 0 µs
Relevant statistics:
mean: 7644 µs
std dev: 1869
min: 3564 µs
max: 12042 µs
Conclusion: part of the error (I estimate between 2.5ms and 5ms) comes from the nature of cable modems (my connection to the internet). Search for "docsis request-grant latency" for more details about the asymmetric nature of latency on a cable modem.
Lastly, a graph comparing NTP's local clock offset (from loopstats) to the GPS timestamps. Since the NTP timestamps will always be offset from the actual time due to how my internet connection works, I've shifted NTP's time to be 5ms higher
Conclusion: the "NTP inverted and shifted" line has roughly the same shape and offset as the leading edge of GPS timestamps.
This the window between the PPS happening and when the computer gets the time is 6ms wide.