[time-nuts] Transmitting a time sync signal - what's the trick?

[Hal Murray]

> I still can't quite get my head round this bit.  I have to synchronise
> to a packet, but by the time that I've received and recognised the
> packet, the moment is past.  Or do I just add Xms to the time, where X
> is the time it takes to process the packet?

It's simple after you see it.

The timer ticks on the transmitter.  You stuff the current time into a packet 
and hand the packet to a driver.  (Let's ignore queuing delays.)  The driver 
pokes the hardware.  The hardware does whatever it does to get the bits 
started out the wire.  On modern systems that doesn't take long.

Now the packet starts out on the wire.  It flows past any point on the wire 
at N bits/second.

Then there are speed of light delays between the transmitter and receiver.  A 
foot per nanosecond is the simple number.  Double that for lossy wire or PCB 
traces.  [1]  (That's probably not interesting for home RF.  [2])

Now the bits start arriving at the receiver.  The whole process repeats in 
mirror image.

It takes 1/N seconds per bit for the packet to flow across the wire (or ether 
or ...), so the last bit leaves the transmitter X seconds after the packet 
starts.

Round up for overhead and such.

Add that all up.  It's roughly a constant.  So if the packet says it left at 
12:34:56, it arrives at 12:34:56.123  Just pretend the packet said 
12:34:56.123

If all you are doing is stuffing the data into a display so a human can see 
it, don't worry about the fine print.

You can get a good estimate of the 1-way delay by polling a typical remote 
box and dividing the response time by two.  (Correct for packet lengths if 
that matters.)


> I'm using the microcontroller as I don't want to have anything to do
> with real-time programming on the PC - just too much to learn, no time
> to learn it.

Check the numbers. or try it.  If the PC is mostly lightly loaded you may not 
need any real-time stuff.  Just let the scheduler do its thing.  It may screw 
up at 3AM when some cron job does a lot of disk activity.  Who cares.




1]  The speed of light depends on the dielectric constant of the medium.  A 
foot per ns is pretty close for vaccum and air.  Low loss coax is foam which 
is mostly air so it is only slightly slower.  Junk wire or a PCB has lots of 
plastic in the insulation which slows things down.  A factor of 2 is a good 
estimate.  (Traces on the surface layer of PCBs are slightly faster than 
inner layers because they have air on one side for a lower effective 
dielectric constant.)

2]  Early in my networking career, we had a 9600 baud line between San 
Francisco and Los Angeles.  If you compared that to a 56KB satellite link, 
the answer depended on the packet length.  Short packets were faster on the 
slower (lower bit rate) land link.  Long packets (~500 bytes) were faster via 
the higher bandwidth satellite link even though the bits went many extra 
miles.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.