[time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs.PPSdecoding cards

Hal Murray hmurray at megapathdsl.net
Wed Feb 22 06:37:47 EST 2017


tvb at LeapSecond.com said:
> It seems to me that if the read path and the write path are different it
> breaks down. Given how USB works, not to mention all the layers of software
> involved I can't imagine the paths are equal. There's no doubt you can get
> great consistency from your method. But turning that into precise time
> requires some kind of calibration of the actual code path delays.

There are 3 clocks: PC, USB, and Gizmo on the end of the USB.

We could get a USB logic analyzer.  That would give us some more data on the 
USB timings.  (There are probably some limits in the specs, but I won't be 
surprised if somebody doesn't get it right..)

I think the problem is how to get accurate timing on a write from PC.  With 
that, we could collect some data, wave our hands, and make an estimate on the 
error bars.

The USB firmware has a schedule with slots for the Gizmo.  (I don't know the 
USB details, so this is a bit handwavy.)  You can get synced with the USB 
schedule by doing a read.  Then pause a bit, do a write, then a read.  The 
Gizmo returns time stamps (its clock) for the write and read.  Now adjust the 
length of the pause to minimize the PC time between start of write and finish 
of the read.  That gives you an upper bound on the time error between the 
Gizmo clock and the PC clock.

We could subtract off the USB data transfer times, and maybe some of the idle times.  With some kernel hacking, we could get some PC time stamps for when the read and writes finish.  On the read side, that just saves a bit of CPU time - interrupt to running user code.  I don't know how to wait for a buffer to get sent.  There may be an ioctl for that.

I'm not sure it would ever be good enough for serious time-nuts work, but it would be an interesting experiment.


-- 
These are my opinions.  I hate spam.





More information about the time-nuts mailing list