Distributed devices or systems with timing or data logging often require synchronization between the local system clocks to ensure time-accurate measurements and logs. Such systems can include distributed data loggers, UAVs, robots, wireless sensor networks, or networking devices. Further, distributed MIMO systems that require synchronization between geographically spread antennas and repeaters could benefit from this approach of PTP synchronization over Wi-Fi The Precision Time Protocol (PTP) stands out as an attractive solution for synchronizing multiple free-running distributed clocks on a common network. PTP, when first introduced in 2001, was designed to serve a niche group of locally networked devices that required more accurate synchronization than network time protocol (NTP) could offer (few milliseconds), but at a lower cost than GPS synchronization (tens of nanoseconds) or outside GPS coverage.

Using Precision time protocol (PTP) and a successive drift correction algorithm, the time-domain channel sounder is able to determine the absolute timing of arrival of multipath components traveling from the transmitter (TX) to the receiver (RX) [1]. The TX employs a Rubidium (Rb) atomic clock to locally synchronize the timing and phase of all system components. Likewise, the RX also employs an Rb atomic clock that is untethered and running asynchronously to the TX. However, differences in the phase/frequency output of the asynchronous system components in both the TX and RX, which are each connected to different and independent atomic clocks, can cause a drift in the timekeeping between TX and RX systems, which we term as ‘time drift’.

In the context of time-domain channel sounders, time drift can lead to undesired offsets in capturing the propagation delay of multipath components (MPCs) departing the TX and arriving at the RX. The arriving MPCs appear as peaks in a power delay profile (PDP), captured at the RX as discrete samples. The MPC time drift appears as a circular shift of the captured PDP samples. Two RaspberryPi computers are programmed to implement PTP over a dedicated Wi-Fi link in a master-slave configuration and synchronize the TX and RX Rubidium clocks continuously every second using timestamps. This synchronization minimizes the real-time drift, reducing PDP sample drift to 7.5 ns/ hour, compared to about 350 ns/hour without synchronization.

For free running Rb clocks, the real-time drift can appear to be as much as 350 ns/hour, which on the NYU channel sounder results in a dilated propagation time drift of up to 2.8 ms/hour (time-dilation factor of 8000). By implementing PTP synchronization every second as described in [1], the real-time drift of Rb clocks is reduced to 7.5 ns/hour, or 60 us/hour on the channel sounder. Further, implementing the successive drift correction algorithm every measurement sweep (lasts about 3 mins) on a time-domain channel sounder reduces the real-time drift to few tens of picoseconds/hour.

The PTP synchronization works by observing the offset between timestamps taken every second and correcting the slave offset. Since each of the clocks is independent, when the slave receives a master’s timestamp, it could change its clock to match the master’s timestamp value but would still see an offset. The reason for the offset is the time elapsed between the recording of the master timestamp and it being delivered to the slave clock. For a wired medium, since the cable provides a static medium, the time elapsed can be accurately determined with a residual error of up to a few picoseconds. When implementing PTP over a wireless link, the estimate of the offset of the time elapsed can vary as the wireless channel changes, causing errors in the estimation of a few microseconds (e.g. 5 us). These errors were measured in the lab and are believed to be due to the varying signal propagation delay and the packet processing delay for the Wi-Fi link. As the Rb clocks continually correct this offset every second, the result is a time drift of up to 7.5 ns/hour.

Additionally, a successive drift correction algorithm is applied every measurement sweep (about 3 mins) to eliminate PDP sample drift and achieve sub-nanosecond accuracy. The required correction is determined by observing the shift in an identical PDP encountered after completing a full 360-degree sweep. The algorithm compensates the PDP sample drift by applying an opposite circular shift following a 360-degree measurement sweep that lasts about 3 minutes. Such successive correction prevents small drifts from accumulating and causing errors in MPC arrival times.

follow this research