There are significant peaks at -5µs, -10µs, -15µs, -20µs, as well as minor peaks at 5µs, 10µs, 15µs, and 20µs. I suspect the USB host only transfers data on a 200khz timer
Comparison between run 7 and run 8:
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
See: usb gps
Revert back to sending timestamp data to NTP on a 16 second interval
Ignore repeated NMEA data (happens ~5 times a day, causes the offset to spike to -1s)
Send STM32F4 clock data at 2HZ instead of 1HZ
This takes all samples within a 16 second window and graphs the number of samples within X µs of the mode and compares it with the count of offsets sent to NTP
There are significant peaks at -5µs, -10µs, -15µs, -20µs, as well as minor peaks at 5µs, 10µs, 15µs, and 20µs. I suspect the USB host only transfers data on a 200khz timer
Comparison between run 7 and run 8:
| percentile | Run 7 | Run 8 |
|---|---|---|
| 50% | 5 µs | 3 µs |
| 90.0% | 20 µs | 19 µs |
| 99.0% | 43 µs | 42 µs |
| 99.9% | 53 µs | 51 µs |
Loopstats graph - local clock error (PPM, green) and USB/GPS offset (µs, red)
Doubling the timer transfer did not have a large impact, and more investigation is needed into the 5µs rounding