[USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS

Kyle A Logue kyle.a.logue at aero.org
Wed Mar 16 16:30:18 EDT 2016


Yes that is correct. We are using the 'rx_time' tag coming from the USRP source to do our alignment.


We are currently compensating for the bias in each radio by sending out a calibration signal, but this is less than ideal.


________________________________
From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of Marcus D. Leech via USRP-users <usrp-users at lists.ettus.com>
Sent: Wednesday, March 16, 2016 13:03
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS

On 03/16/2016 03:56 PM, Kyle A Logue via USRP-users wrote:
Paul et al,

I don't have a fix for you, but I've seen this problem consistently and have done some measurements.

I believe this same problem occurs on the E310 images as discussed multiple times previously, including my thread here<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017483.html>. Even with a robust external PPS source I get a consistently random starting offset with a mean of ~2.9us and stdev of ~2us.

We have been drilling down into the FPGA level to determine the source, since it seems much more than random phase offset.

If this problem disappeared my life would be much easier; let's hope it's fixable.
So, to clarify.   Even *AFTER* you've time-aligned samples from the timestamps, there's a time offset?



Kyle Logue · The Aerospace Corporation · ETG-DCID · Senior MTS · 310.336.3038 · kyle.logue at aero.org<mailto:kyle.logue at aero.org>

________________________________
From: USRP-users <usrp-users-bounces at lists.ettus.com><mailto:usrp-users-bounces at lists.ettus.com> on behalf of Garver, Paul W via USRP-users <usrp-users at lists.ettus.com><mailto:usrp-users at lists.ettus.com>
Sent: Wednesday, March 16, 2016 11:08
To: usrp-users at lists.ettus.com<mailto:usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS

Hi Marcus,

I didn't describe this step, but we do as you say. The receivers call set_time_next_pps() to 0, confirm it is set properly, and then schedule a start-of-streaming time to record with metadata. The transmitter transmits a repeating signal on the second (it transmits on (or close to) the PPS edge) which is about 0.5s in duration. For each receiver, we loop through the headers and find the timestamp closest to integer seconds and split the recorded files on those integer seconds. Then the cross-correlation is performed to estimate the TDoA between the sensors. Using this method the delays are still on the order of microseconds. Are you saying this is expected behavior? If so, how does the PPS help?

PWG

________________________________
From: "Marcus D. Leech" <mleech at ripnet.com><mailto:mleech at ripnet.com>
To: usrp-users at lists.ettus.com<mailto:usrp-users at lists.ettus.com>
Sent: Wednesday, March 16, 2016 11:34:09 AM
Subject: Re: [USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS

On 03/16/2016 09:56 AM, Paul Garver via USRP-users wrote:
The question regarding time synchronization with B200's has been asked multiple times on this mailing list [3,4,5,6]. Many of these threads end with limited information in terms of how to successfully sync B200s and the expected accuracy. In [4], it is explained there is a random phase offset due the 3 fractional-N PLL's which supply the RF LO's. So I understand that there is some calibration which is needed, potentially across every tune. What I haven't seen, however, is an expected value for the these delays.

Suppose I have a high quality timing reference driving the 10 MHz / 1 PPS inputs on the B200s assuming matched length cables, etc. I split an input signal and receive it with three B200s attached to three separate PCs. I then perform a cross-correlation to determinte the TDoA between the signals. What is the expected value for these measurements? Is it just a phase term, or could the alignment be off by more? There was a nice presentation given in FOSDEM 2016 [1] regarding B200 synchronization, but I did not see the uncorrected offset. [4] shows ~ 10uS offset.

I have performed a similar experiment using the Ettus Octoclock Timing Distribution (w/o GPSDO) [7] and a Jackson Labs LC-XO GPSDO [8], which I believe is the same used in the Octoclock with GPSDO option. The LC-XO is connected to the Octoclock, and then equal length (not phased matched) cables are connected to the 1 PPS/ 10 MHz outputs to drive 3 B200s on separate computers. A separate B200 transmits a BPSK-modulated PN sequence with a RRC pulse shape and a bandwidth around 20 MHz. The data is recorded (after setting clocks and next_time_pps) and then cross-correlation is performed. The time delay between receivers is estimated by taking the maximum sample number of the cross-correlations. A sub-sample estimate is performed via parabolic interpolation. Our results show differences on the order of 10's of microseconds, but the actual number is random, which agrees with [4]. This leads me to believe that either

1) The random offset due to the 3 fractional-N PLL's (or other RF front-end ambiguities) is more than a phase ambiguity
2) There is something incorrect in the code for performing the time synchronization

Has anyone successfully synchronized B200's in this way? If so, what is the expected value of the random delay (or phase offset?) between receivers? Is it on the order of nanoseconds, microseconds, etc? I'd be really interested in some hard numbers on these things. Of course, it depends on the particulars such as bandwidth, etc, but just some idea of what other folks are getting. I believe the B200 only samples the 1 PPS at the rate of the master clock so I would expect with calibration the B200s should be able to be synchronized on the order of maybe 100ns. Is this realistic?

PWG

[1] https://fosdem.org/2016/schedule/event/distributedsdr/
[2] https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
[3] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-January/012227.html
[4] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-May/014025.html
[5] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-December/017400.html
[6] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-June/014656.html
[7] https://www.ettus.com/product/details/OctoClock
[8] http://www.jackson-labs.com/index.php/products/lc_xo




_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com<mailto:USRP-users at lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


There will be an unknown phase error among all your B200s.  This can be anywhere along the phase circle.

The timing ambiguity is a different issue.  Since you can only have 1 B200 per multi_usrp object, time-alignment is not down automatically.

Assuming that you've set the TOD registers on all your participating B200s via set_time_next_pps() or set_time_unknown_pps(), and you've
  set a common start-of-streaming time, then you'll have to look at timestamps on all your streams, via the metadata, to understand what
  the timing offsets are.   Without those two steps, you can't predict what the timing offset will be, since the N streams will all be started
  at some random time relative to each other.






_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com<mailto:USRP-users at lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160316/cc68a61f/attachment-0002.html>


More information about the USRP-users mailing list