[time-nuts] time transfer over USB
pmonta at gmail.com
Tue May 14 03:40:01 EDT 2013
> IMHO the transfer mode of choice for this purpose should
> be the Isochronous Transfer (in USB 2.0 and 3.0) because
> it happens periodically and thus can achieve a guaranteed
> maximum latency (for high speed this means 125us).
If 1 ms or 125 us is good enough, then this would be fine; but for better
precision there seem to be two problems with isochronous transfers: you
don't know when the USB frame starts, and you don't know where you are in
the pecking order of subscribers to the isochronous subset of the USB
bandwidth. The first one could be overcome by doing many timestamp
exchanges at random times, then seeing which times modulo 1 ms or 125 us
are quickest. But the second one seems more difficult and could change
unpredictably over time.
The nice thing about bulk transfers is that they're best-effort and don't
come burdened with any fancy USB scheduler stuff.
So a USB-based GPS should:
- maintain a cycle count of its local crystal oscillator (e.g. with a timer
- report this count when requested
- timestamp PPS edges from the GPS module, and report these timestamps when
This would seem to be enough to gradually converge to a good estimate of
(USB_host_time - GPS_PPS) across the noisy USB link.
More information about the time-nuts