[time-nuts] time transfer over USB
albertson.chris at gmail.com
Wed May 15 00:02:04 EDT 2013
What if you re-clock an isochronous bit stream? To transfer time over USB
the GPS sends something like IRIG as amplittude modulated audio. The GPS
looks to the PC just like a USB audio device. The bits come in packets but
the software buffers and reclocks then out at a constant rate.
The long term ability woud be near perfect and in practice the audio is
very stable but has a fixed lag. You can measure the lag one and it
remains the same forever, until you deside to change the buffer length.
Typically the audio is sampled at 48KHz or sometimes 96KHz Th reason for
using audio to transfer time is that there is already software to read
audio time code and the computer audio gear is is pretty good at keeping
the bit rates spot on.
On Tue, May 14, 2013 at 8:10 PM, Peter Monta <pmonta at gmail.com> wrote:
> > > 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 means "now", or pretty close. No waiting for start-of-USB-frame or
> Herbert mentions that all USB transfers are host-initiated, which is true
> (even for the so-called "interrupt" transfers), but the latency is usually
> much less than one frame on a lightly loaded bus I believe.
> I agree with Magnus' remark that this is not rocket science. Maybe it's
> time for a small proof of principle, using something like a Teensy board,
> that takes PPS edges from the outside world and connects them to USB.
> GNSS samplers should be timestamping their packets so that the relationship
> between sample number and device-local time (and ultimately also host time)
> can be known.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
Redondo Beach, California
More information about the time-nuts