[USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS
Marcus D. Leech
mleech at ripnet.com
Wed Mar 16 21:50:11 EDT 2016
On 03/16/2016 05:21 PM, Paul Garver wrote:
> 25MSPS with 50 MHz clock rate on UHD 3.8.5.
Since 3.8.5 there have been *several* fixes that I would categorize as
"coherency management". Please try the latest UHD software
and matching firmware.
> On 03/16/2016 03:46 PM, Marcus D. Leech wrote:
>> On 03/16/2016 02:08 PM, Garver, Paul W wrote:
>>> 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?
>> What is your sample rate? What version of UHD are you using?
>>> *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 , 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
>>> 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  regarding B200
>>> synchronization, but I did not see the uncorrected offset. 
>>> shows ~ 10uS offset.
>>> I have performed a similar experiment using the Ettus Octoclock
>>> Timing Distribution (w/o GPSDO)  and a Jackson Labs LC-XO
>>> GPSDO , 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 . 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?
>>>  https://fosdem.org/2016/schedule/event/distributedsdr/
>>>  https://www.ettus.com/product/details/OctoClock
>>>  http://www.jackson-labs.com/index.php/products/lc_xo
>>> USRP-users mailing list
>>> USRP-users at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users