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

Marcus D. Leech mleech at ripnet.com
Wed Mar 16 16:03:09 EDT 2016


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> on behalf of 
> Garver, Paul W via USRP-users <usrp-users at lists.ettus.com>
> *Sent:* Wednesday, March 16, 2016 11:08
> *To:* 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>
> *To: *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
>     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
> 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/1070acab/attachment-0002.html>


More information about the USRP-users mailing list