[time-nuts] time transfer over USB

Bob Camp 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
> peripheral)
> - report this count when requested
> - timestamp PPS edges from the GPS module, and report these timestamps when
> requested
> This would seem to be enough to gradually converge to a good estimate of
> (USB_host_time - GPS_PPS) across the noisy USB link.
> Cheers,
> Peter
> _______________________________________________
> 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 mailing list