Re: [time-nuts] time transfer over USB
On May 14, Peter Monta wrote: 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 I was already tinkering with stuff along these lines, so I threw together some code that just prints to a USB emulated serial port on every PPS pulse as well as a simple program on the PC side to timestamp it. I know this isn't ideal, I just wanted to get a starting point. My goal is to get the error under 1ms (NTP grade instead of timenut grade :). This is the result (red bar of 41k samples), compared to NTP loopstats info (green line, cable modem connection): http://dan.drown.org/stm32/run2/time-drift.png From that picture, you can see that it's around 2ms worth of inaccuracy. I'm working on adding your recommendations to see if I can get that number lower. More info and graphs if anyone's interested: http://dan.drown.org/stm32/run2.html ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
On Tue, 14 May 2013 07:22:26 +0200 Herbert Poetzl herb...@13thfloor.at wrote: If the best-case response time is calibrated out, how good can this get? Microseconds? With 125us latency and a fixed interval, it should be possible to calculate the relation between the transfer intervall (USB clock crystal) and the PPS (or whatever information is transmitted) and thus easily get below the 100us. You can actually get better than that. If you are using a uC at the sending end, you get a transfer completed interrupt. You can time this interrupt and send a second packet to the PC to tell it how long it took for the PC to receive the first packet. Thus getting rid of quite a bit of the uncertainty between the device and the usb controller. Also use a uC with HS USB, as this allows to use micro frames which are 125us long insted of the normal 1ms long frames. Also, use interrupt transferes instead of bulk, as these are prefered over bulk transfere in case of congestion, and have two times as many slots per frame. Oh.. and connect the whole thing to a port on the PC that does _not_ have an internal USB hub. Attila Kinali -- The people on 4chan are like brilliant psychologists who also happen to be insane and gross. -- unknown ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
On 5/20/13 2:43 AM, Attila Kinali wrote: Oh.. and connect the whole thing to a port on the PC that does _not_ have an internal USB hub. That's a bit of challenge, I suspect.. A casual look at the PCs I have around here running windows all seem to have on-mobo hubs when you check Device Manager. I suspect they are integrated into one of the peripheral chips. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
I suspect the idea is to use a port where no other devices, that is internal, are on the hub. Like you, I never saw a usb port not on a hub. -Original Message- From: Jim Lux jim...@earthlink.net Sender: time-nuts-boun...@febo.com Date: Mon, 20 May 2013 06:14:12 To: time-nuts@febo.com Reply-To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] time transfer over USB On 5/20/13 2:43 AM, Attila Kinali wrote: Oh.. and connect the whole thing to a port on the PC that does _not_ have an internal USB hub. That's a bit of challenge, I suspect.. A casual look at the PCs I have around here running windows all seem to have on-mobo hubs when you check Device Manager. I suspect they are integrated into one of the peripheral chips. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
On Mon, 20 May 2013 06:14:12 -0700 Jim Lux jim...@earthlink.net wrote: On 5/20/13 2:43 AM, Attila Kinali wrote: Oh.. and connect the whole thing to a port on the PC that does _not_ have an internal USB hub. That's a bit of challenge, I suspect.. A casual look at the PCs I have around here running windows all seem to have on-mobo hubs when you check Device Manager. I suspect they are integrated into one of the peripheral chips. In my experience, it's usually two or 4 ports connected to an internal hub, where at least one is not on a hub at all. You have to try to find out which they are. I dont know any similar tool with windows, but on linux (and i guess *BSD) you can use lsusb to give you a hierarchy of the USB system on your mainboard. There you can see which ports have a hub behind them and which dont. Attila Kinali -- The people on 4chan are like brilliant psychologists who also happen to be insane and gross. -- unknown ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time transfer over USB
On Tue, May 14, 2013 at 03:11:58PM -0700, Hal Murray wrote: jim...@earthlink.net said: Bulk transfer might work well on a system where nothing else is going on, so best effort translates to now. Does it mean now or next polling cycle? It's always 'next polling cycle' because all USB transfers are initiated by the host, and the client 'just' replies with e.g. data. Personally I do not see how Bulk Transfers would be better than Interrupt or Isochronous Transfers because they will have a lower priority an the same minimum interval, so no advantage over the other transfer modes. best, Herbert -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
