Is there a problem with the USRP receiving timestamp mechanism?

After a month's experiment, the USRP synchronization to GPS time project didn't achieve the desired accuracy. I reasonably suspect that there are loopholes in the data receiving mechanism and time tagging mechanism in MATLAB.

Experiment summary:

In order to measure the perfection of USRP synchronization to GPS time, two USRPs are put at close positions and configured to receive WLAN signals at the same time. By observing the preamble time of the same WLAN data packet received by the two USRPs, the theoretical time difference should be tens of ns.

Basic process of the experiment:

(1) Configure USRP to receive 5Ghz signal and configure USRP to lock GPS time.

(2) Configure USRP to receive 4s of data at approximately the same time, and then intercept 1s of data according to GPS timestamp to obtain 1s of sychronizedly received data to be analyzed. In theory, which means if they are synchronized perfectly, the data content received by two USRPs in this 1s should be the same.

(3) Decompose WLAN data packets for the two groups of data, observe the same data packet successfully solved bit, and determine the synchronization accuracy based on the difference between the time of the sampling point, where preamble (L-STF and L-LTF) is located.

Experimental design reference:

Several papers show that they directly use cross-correlation to determine that the difference between the arrival time of signals received by two USRPs at the same location can reach the order of tens of ns (See the end of the paper for reference).

A friend from China who uses the same equipment as me told me that he uses GNURADIO to put the receiving transmitter together, with a homemade signal of 50Mhz. The synchronization result of the receivers should be tens of ns.

Experimental equipment:

The total amount of USRPB210 and GPSDO of tqtt.com is about 20000 RMB.

As mentioned above, the device has been proved by friends to be free of problems.

At the same time, in my experiment, the hardware locking time is about one minute, and there is no hardware locking problem.

At the same time, MATLAB will prompt USRP synchronized to GPS, that is, UHD synchronization is successful.

Experimental environment:

Such as playground, courtyard and other open areas. The current temperature is about 5 degrees Celsius.

Experimental results:

1. Using the USRP burst mode exclusively provided by MATLAB will result in completely asynchronous data reception. In the process of use, the time given by the two USRPs synchronized to GPS time will gradually shift, which may shift to several seconds.

2. Using the normal reception of MATLAB, the difference between the lead time is 500ns~5us.

The figure shows the best experimental results in dozens of experiments, with synchronization accuracy of 230ns.

I think there may be problems and other details

(1) There are loopholes in the receiving mechanism and timestamp marking method of MATLAB itself

(2) In the process of receiving, the data of one computer is interrupted many times, which may cause the timestamp disorder? However, MATLAB will stamp the interrupted data again.

(3) The first receiving meeting of MATLAB sync_ to_ GPS, calibrate your own time. After that, the multiple reception time will gradually drift.

However, it is strange to float a few us in ten minutes.

(4) Tiny possibility: the signal to noise ratio of WLAN signal is low enough to estimate the time difference of arrival.

The question I want to ask

(1) Can the developers supported by MATLAB - USRP confirm that there is no problem with the timestamp mechanism and the receiving mechanism of MATLAB?

(2) Is there any other USRP receiver using MATLAB? Can you tell me whether there are successful cases of time synchronization?

Supplement:

When USRP transmits data to the upper computer, it will stamp the header time of a packet and transmit it upward. I'm curious about how MATLAB handles the time of each packet. This is not open source.

I still hope that it is the problem of my experimental design itself, not the problem of MATLAB. I also hope that other USRP-TDOA developers can not use MATLAB to take my detour.

I hope I'm beaten! Because MATLAB development is relatively simple!

Reference papers:

[1] Gemayel N E , Koslowski S , Jondral F K , et al. A low cost TDOA localization system: Setup, challenges and results[C]// 2013 10th Workshop on Positioning, Navigation and Communication (WPNC). IEEE, 2013.

B210+GPSDO, low-pass filtering+cross-correlation, 20m error.

[2] Zan L , Braun T , Dimitrova D C . Methodology for GPS Synchronization Evaluation with High Accuracy[C]// 2015 IEEE 81st Vehicular Technology Conference: VTC2015-Spring. IEEE, 2015.

Synchronization error<100ns.

[3]Li Z , Dimitrova D C , Braun T . TDOA-Based Localization System with Narrow-band Signals. 2013.

GPSDO has clock offset (0.2ns/s) in the short term, but not in the long term.

[4] Schmitz J , Hernandez M , Mathar R . Real-time indoor localization with TDOA and distributed software defined radio: demonstration abstract. 2016.

It is proposed to use the signal sent by the third USRP to correct the synchronization accuracy of the two USRPs.

The experiment code I wrote is attached:

Link: https://pan.baidu.com/s/1yLgzxuDIxm3KlzKMLTtB5A

Extract code: whca

The execution order is:

(1)GPSDO_ Syn configures USRP, receives 5G signal and synchronizes GPS time.

(2)GPSDO_ Loop receives 4s of data from a certain point in time and obtains the same 1s of data

(3)GPSDO_ The adjust timestamp may be simply corrected (unimportant) due to the overflow of double64 data type

(4)GPSDO_ Small unpack and check the lead time

[Karunya Choppara]

Is the EnforceGPSTimeSync property enabled?

To synchronize the USRP radio time to the valid global positioning system (GPS) time when the GPSDO is locked to the GPS constellation at the beginning of the transmit or receive operation, we need to enable the property EnforceGPSTimeSync in comm.SDRuReceiver or comm.SDRuTransmitter system objects.