time transfer over USB
I wonder if the following scheme would work to improve measurement
precision over USB for use with GPS devices or similar.
Instead of USB interrupt transfers, which occur on 1 ms boundaries with
some unknown epoch, use bulk transfers. In the good case, there are no
other USB transactions in flight, the request goes out immediately, the
device responds immediately, and the entire link has the lowest latency
possible. If these conditions don't hold, the completion time will be
delayed. Now use robust estimation techniques to get rid of these
exceptions and instead follow the smooth line of best-case responses. NTP
implementations do something like this already, but at longer timescales,
and targeted at Internet links rather than a single local USB link.
If the best-case response time is calibrated out, how good can this get?
Microseconds?
Cheers,
Peter
On Mon, May 13, 2013 at 08:36:14PM -0700, Peter Monta wrote:
I wonder if the following scheme would work to improve
measurement precision over USB for use with GPS devices
or similar.
Instead of USB interrupt transfers, which occur on 1 ms
boundaries with some unknown epoch, use bulk transfers.
In the good case, there are no other USB transactions in
flight, the request goes out immediately, the device
responds immediately, and the entire link has the lowest
latency possible.
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 these conditions don't hold, the completion time will be
delayed. Now use robust estimation techniques to get rid
of these exceptions and instead follow the smooth line of
best-case responses. NTP implementations do something like
this already, but at longer timescales, and targeted at
Internet links rather than a single local USB link.
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.
best,
Herbert
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.
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
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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
The problem is the PPS needs to be referenced to the same clock the PC
is using as a basis for system time. Yes, you could send the
counter's value periodically but that has the same problem of sending
the PPS, that is an un knowable delay.
The good news is that good Moterola GPS receivers with 50 nanosecond
PPS accuracy are available on eBay for $15. Soyou don't have to mess
with USB.
On Tue, May 14, 2013 at 12:40 AM, Peter Monta pmonta@gmail.com 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
This would seem to be enough to gradually converge to a good estimate of
(USB_host_time - GPS_PPS) across the noisy USB link.
--
Chris Albertson
Redondo Beach, California
On 5/14/13 8:54 AM, Chris Albertson wrote:
The problem is the PPS needs to be referenced to the same clock the PC
is using as a basis for system time. Yes, you could send the
counter's value periodically but that has the same problem of sending
the PPS, that is an un knowable delay.
The good news is that good Moterola GPS receivers with 50 nanosecond
PPS accuracy are available on eBay for $15. Soyou don't have to mess
with USB.
yes you do have to mess with USB, if that is the only interface available.
There is great value in figuring out how to accurately transfer
time/sync/frequency over an existing interface.
Or, at least, to bound the accuracy achievable with various approaches:
vanilla off the shelf device drivers, custom device driver, etc.
I think the isochronous approach probably has promise for the 1ms class,
especially if you can figure a way to do two way.
Bulk transfer might work well on a system where nothing else is going
on, so "best effort" translates to "now".
It's sort of like knowing how well you can do it over Ethernet.. the
performance achievable depends a lot on what your hardware and device
drivers look like, and sometimes, you're stuck with what you got, so
it's useful to know when to stop struggling to do better.
It's also useful as a BS detector in marketing literature.. If someone
came to me and said, I can give you 50ns timing accuracy over USB, I'd
want to ask a lot of very detailed questions about how they claim they
can do it, and an answer of "proprietary magic pixie dust" would not be
very convincing.
On 14/05/13 20:19, Jim Lux wrote:
On 5/14/13 8:54 AM, Chris Albertson wrote:
The problem is the PPS needs to be referenced to the same clock the PC
is using as a basis for system time. Yes, you could send the
counter's value periodically but that has the same problem of sending
the PPS, that is an un knowable delay.
The good news is that good Moterola GPS receivers with 50 nanosecond
PPS accuracy are available on eBay for $15. Soyou don't have to mess
with USB.
yes you do have to mess with USB, if that is the only interface available.
There is great value in figuring out how to accurately transfer
time/sync/frequency over an existing interface.
Or, at least, to bound the accuracy achievable with various approaches:
vanilla off the shelf device drivers, custom device driver, etc.
I think the isochronous approach probably has promise for the 1ms class,
especially if you can figure a way to do two way.
Bulk transfer might work well on a system where nothing else is going
on, so "best effort" translates to "now".
It's sort of like knowing how well you can do it over Ethernet.. the
performance achievable depends a lot on what your hardware and device
drivers look like, and sometimes, you're stuck with what you got, so
it's useful to know when to stop struggling to do better.
It's also useful as a BS detector in marketing literature.. If someone
came to me and said, I can give you 50ns timing accuracy over USB, I'd
want to ask a lot of very detailed questions about how they claim they
can do it, and an answer of "proprietary magic pixie dust" would not be
very convincing.
Well, look at the GNSS sampler, it performs bulk transfer of a
continuous clock but only uses 2 bits in the byte. Trivial to hook up
the PPS to that.
If you do not want to hack into the GNSS sampler, there is a similar USB
chip available on SEEED, check out the FT2232 (if I recall correctly).
We talk about relatively low advancement in hardware hacking to get
access to the signals over USB. Sufficient software support exist to get
you started.
If you could get some signal from the inside going out with some
precision, it could be sampled too, and the delay can be cancelled out.
Cheers,
Magnus
On Tue, 14 May 2013 07:22:26 +0200
Herbert Poetzl herbert@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
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.