> 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.

Quoth Hal Murray at 2008-02-27 17:03... > It's simple after you see it. Now you've explained it, yes it is :-) > 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 could even integrate that into the system - at least for the 2-way nodes. > 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. I'll probably stick with the microcontroller as I don't think I'll have a PC involved at all when I'm testing the RF link. Many thanks for helping to get this through my thick skull! It seems so simple now... Cheers M -- Matthew Smith Smiffytech - Technology Consulting & Web Application Development Business: http://www.smiffytech.com/ Personal: http://www.smiffysplace.com/ LinkedIn: http://www.linkedin.com/in/smiffy