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