[time-nuts] time transfer over USB

Herbert Poetzl herbert at 13thfloor.at
Tue May 14 04:08:24 EDT 2013


On Tue, May 14, 2013 at 12:40:01AM -0700, Peter Monta 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.

You can easily assure that you are the only subscriber.

> 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.

I thought the plan was to transfer the PPS via USB without
additional hardware, of course, with external timestamping
the actual usb transfer doesn't matter much if you do it
properly (and over time that is)

best,
Herbert

> 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