I have a system that sends data from one location to another via radio and I needed to find out the point to point delay propagation from the sensor measurement on one side to the reception on the other side.

The system is like this:

Computer 1 ----> RF TX --> ) ) ) ) --> RF RX ----> Computer 2

On Computer 1:

              ETH                       ETH
Sensor Signal ---> Processing Softwares ---> RF Converter 

On Computer 2:

             ETH          ETH                      Protocol
RF Converter ---> Stroage ---> Processing Software -------> Display Software

The RF Converter is dedicated hardware to converting RF packet to ETH format.

I need the time from the Sensor Signal to the Display Software, "point-to-point".

Some points:

  • I can't use a timestamp difference because they are two different machines - that is, their clocks are not synchronized.

  • I can simulate monitoring an event from both sides using an oscilloscope in the laboratory, but the real case will have a distance of approximately 200 meters, and I would like a solution for measuring in the field.

  • I can't receive data on Computer 1, as I thought one possibility would be to measure the send/response time and divide by two, but unfortunately it wouldn't be possible.

Is there any way to synchronize the times or any suggestion of an idea so that I can measure this delay?

The computers' OS is Windows.


  • I added communication (ETH) and other intermediaries
  • My timing accuracy needs to be in milliseconds, the GPS guarantees seconds sync
  • The size of the packet sent by RF varies, so I cannot assume a fixed value, I am looking for a methodology that fits different sizes
  • I can use audio and video resources, but it involves a cost that I don't know if I would be able to.

I expressed myself badly by putting only Computer 1, there is a bigger process involved.

  • 2
    \$\begingroup\$ What kind of accuracy do you need, and from what reference event are you measuring? 200m is roughly 600ns in open air, but there are other delays in the transmission chain which would quickly dominate that. For instance, you mention there is "computer 1." What parts of the computer are involved? If a PCIe bus is involved, high quality low-latency parts may add 300ns to the signal chain. I know of systems which used an expensive high-bandwidth Infiniband configuration, not for the bandwidth, but just to lower latency by transmitting bits faster. \$\endgroup\$
    – Cort Ammon
    Jul 25, 2022 at 14:27
  • 1
    \$\begingroup\$ What @Cort said. Without knowing what kind of accuracy you need, we're all kind of shooting in the dark. Using something based on stable atomic clocks (like GPS) along with some additional calibration techniques can get you well under a us accuracy. \$\endgroup\$
    – SteveSh
    Jul 25, 2022 at 15:53
  • \$\begingroup\$ PTP comes to mind. \$\endgroup\$
    – winny
    Jul 25, 2022 at 17:36
  • \$\begingroup\$ PC1 send a "digital" optical pulse for reference at "start" time... which should be "tested" by PC2 and starting timer counter until "data" is received... \$\endgroup\$
    – Antonio51
    Jul 25, 2022 at 18:06
  • \$\begingroup\$ NB: The GPS system has a built-in clock signal accurate to 10 nanoseconds, although most GPS receivers will only provide an accuracy of 100 nanoseconds to 1 microsecond. Too imprecise. \$\endgroup\$
    – Antonio51
    Jul 25, 2022 at 18:47

5 Answers 5


Use GPS to sync the times and subtract times OR get a serial loopback connector and measure the round trip time with the oscilloscope or PC and divide that time by two for one way time.

The GPS method would be way more accurate it just depends on how much accuracy you need. The propagation time will most likely vary because of the radios so you may need to get an average time.

  • \$\begingroup\$ The gps I can only sync 1 second, as much as it gives me the time with greater precision, between two readings from two different points the guarantee of sync is 1 second. \$\endgroup\$
    – Arcaniaco
    Jul 27, 2022 at 11:00
  • 1
    \$\begingroup\$ That's the pps signal, it happens every second but it's accurate to us or nah. Use a USB dongle instead and sync to that oh8stn.org/blog/2019/11/04/… you don't have to use the pps signal for a sync \$\endgroup\$
    – Voltage Spike
    Jul 27, 2022 at 13:39

I need to find out the delay propagation point to point, from the sensor measurement on one side to the reception on the other side.

If you are sending data via radio, that data needs to be packetized into a frame. A frame might consist of a preamble, a header, the data and, a checksum. Only when that packet is processed without finding an error is that data available for use in the receiving computer or system.

Putting typical numbers onto the packet parts: -

  • Preamble might be a hundred microseconds to 10 ms in time (say 1 ms)
  • Header might be 1 or 2 bytes and, if running at (say) 9600 bps, that takes 1 ms or 2 ms
  • Date might be 1 byte (minimal) or 1 ms
  • Checksum might be 2 bytes or 2 ms

So, total running time for the data packet might be 5 ms (9600 bps) before your PC can actually regard it as good data. This is a true delay of 5 ms.

The time an EM wave takes to travel 200 metres is 667 ns.

Do you see that the flight time of the EM wave is totally unimportant because the processing time to send and receive valid data might take 5,000 to 10,000 times longer.

  • \$\begingroup\$ Plausibly what the OP wants is that total sample-to-receipt time. While the propagation delay might be negligible, it's surely essentially the same question if they want to experimentally characterize the marshalling and unmarshalling delay? \$\endgroup\$
    – Dannie
    Jul 25, 2022 at 17:39
  • \$\begingroup\$ @Dannie you may be right but the question doesn't exactly spell that out so, if we can feasibly ignore the transmission time then, we are left with fairly predictable numbers based on packet shape, size and speed. This question then boils down to a question about a PC running windows (with its variable timing nuances) and, that is likely off-topic. \$\endgroup\$
    – Andy aka
    Jul 25, 2022 at 17:44

I can't use a timestamp difference because they are two different machines, that is, the timestamps are not synchronized.

GPS solves that problem. And all the subsequent problems. Two identical GPS receivers will keep relative time offset almost as low as theoretically possible in that system when placed 200m away from each other.

A very simple implementation would send two packets:

  1. The data packet.
  2. A timing packet that has the delay from the last GPS PPS edge to the first edge of the serial data packet. This can be measured using a timer on an MCU.

The receiver would also use a timer to get the delay from the PPS signal edge to the first edge of the serial data packet coming from the RF modem. You then have a PPS-to-send and PPS-to-receive delays, and can easily calculate their difference modulo 1 second.


Since those are Windows PCs, a local PTP or IEEE1588.2 server can provide the required measurement. Ideally, one of the PCs should have a grandmaster clock available on its network, but the solution can work without one.


You say you can bench-test the delay, so as a general approach:

You could measure the delay in the lab over a range of 1 metre to your longest available corridor*, with repeated measurements at each distance to assess the uncertainty of course, and to ns precision (even if, like me, you work in SI units, treating the speed of light as 1 ft/ns is handy). Then plot time vs distance and use that to extrapolate.

I strongly suspect that you'll get a linear fit, with the following features:

  • the intercept (offset) is by far the biggest fraction of the time delay
  • the slope isn't necessarily c, the speed of light, but c/n where n is a small integer that depends on your protocol. If it really is a unidirectional link, i.e. PC 2 has no transmit hardware or PC 1 no receive, you will find n=1.
  • if the physical layer supports bidirectional comms, n>1, and a weak signal could cause a (random) departure from linear due to failed error checks and the need to resend.

* I work in optics, and would double (even up to 8x once) the length of the laser beampath by putting sender and receiver next to each other with a mirror. This is likely to be quite hard with radio.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.