[time-nuts] time transfer over USB

Bob Camp lists at rtty.us
Tue May 14 10:37:01 UTC 2013


Hi

Unless you are going to roll your own driver (and possibly hardware) the transfer mode is not likely to be under your control.

Bob

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_lists.febo.com mailing list