[time-nuts] time transfer over USB
lists at rtty.us
Tue May 14 06:37:01 EDT 2013
Unless you are going to roll your own driver (and possibly hardware) the transfer mode is not likely to be under your control.
On May 14, 2013, at 3:40 AM, Peter Monta <pmonta at gmail.com> wrote:
>> 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts