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 <[email protected]> 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
