I am investigating the possibility to use the EM7455 GPS as a reference clock for a NTP server. This post let me know that it is possible for the gpsd daemon to extract the GPS data. This is a good start, because ntpd can read gpsd and thus it is possible to use as a reference clock. However I am wondering how good the GPS is and if it can perform a more accurate time than a NTP setup with regular NTP servers.
What I understand from this is that it boils down to if the GPS has Pulse Per Second (PPS) support or not. Does the EM7455 have it? I found no mentioning in the documentation that I have read, but I might have missed something. I am asking here because I would like to be 100% sure before abandoning the idea.
no pps pin, so not usable for gps.
The quality of the GPS is irrelevant. The problem is that USB is unsuitable for precise timing signals because it is a polling protocol. There is no way for the GPS to force a signal to be delivered at at precise time. It will depend on when the host decides to poll.
Some work has been done to try to compensate for this: http://blog.dan.drown.org/pps-over-usb/ .But the host timing is basically unpredictable, so perfect results are impossible.
Still can be “good enough”, though. Depends on your needs.
There are several factors affecting latency over USB:
- EHCI interrupt latency - interrupts are coalesced, one per microframe (125 us)
- USB 2.0 vs 1.1:
- 1.1 typically involves a Hub with transaction translator, this adds significant latency, as the number of transfers is approximately doubled (split transfers).
- longer transfer time
- bulk vs interrupt endpoint - interrupt is only polled once per (micro)frame (125 resp. 1000us), while bulk is polled once every 10us (for EHCI, AsyncSchedSleepTime).
As the EM7455 uses Bulk over USB 2.0 (or potentially 3.0), the expected latency/jitter is -0/+135us, plus any hardware interrupt latency on the host.