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

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
----- Original Message -----

From: "Marcus D. Leech" mleech@ripnet.com
To: usrp-users@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@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.

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 herehttp://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.

Kyle Logue · The Aerospace Corporation · ETG-DCID · Senior MTS · 310.336.3038 · kyle.logue@aero.orgmailto:kyle.logue@aero.org

From: USRP-users usrp-users-bounces@lists.ettus.com on behalf of Garver, Paul W via USRP-users usrp-users@lists.ettus.com
Sent: Wednesday, March 16, 2016 11:08
To: usrp-users@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@ripnet.com
To: usrp-users@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@lists.ettus.commailto:USRP-users@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.

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@lists.ettus.com on behalf of Marcus D. Leech via USRP-users usrp-users@lists.ettus.com
Sent: Wednesday, March 16, 2016 13:03
To: usrp-users@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 herehttp://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@aero.orgmailto:kyle.logue@aero.org

From: USRP-users usrp-users-bounces@lists.ettus.commailto:usrp-users-bounces@lists.ettus.com on behalf of Garver, Paul W via USRP-users usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Sent: Wednesday, March 16, 2016 11:08
To: usrp-users@lists.ettus.commailto:usrp-users@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@ripnet.commailto:mleech@ripnet.com
To: usrp-users@lists.ettus.commailto:usrp-users@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@lists.ettus.commailto:USRP-users@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@lists.ettus.commailto:USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

In my application i set the master clock rate to 20x my sample rate before doing the PPS clock dance to align the TOD registers:

addr = uhd.device_addr_t('master_clock_rate=' + str(samp_rate * 20))

args = uhd.stream_args(cpu_format="sc16", otw_format="sc16", channels = [0])

self.usrp0 = cuav.usrp_source(addr, args)

self.usrp0.set_samp_rate(samp_rate)
self.usrp0.set_center_freq(2.440e9, 0)
self.usrp0.set_gain(40,0) # 38 is midpoint, 76 is max
self.usrp0.set_antenna("RX2", 0)

[... much later, after checking for gps lock and pps source]

print('--','Explicity seting PPS Time...')
cur_pps = last_pps = usrp.get_time_last_pps().to_ticks(1.0)
while cur_pps == last_pps: # Wait for PPS Edge
cur_pps = usrp.get_time_last_pps().to_ticks(1.0)
time.sleep(0.2) # allow NMEA string to propagate
usrp.set_time_next_pps(
uhd.time_spec_t(
usrp.get_mboard_sensor('gps_time').to_int()
+ 1 - offset));
cur_pps = last_pps = usrp.get_time_last_pps().to_ticks(1.0)
while cur_pps == last_pps: # Wait for PPS Edge
cur_pps = usrp.get_time_last_pps().to_ticks(1.0)
time.sleep(0.2) # allow NMEA string to propagate

From: Marcus D. Leech mleech@ripnet.com
Sent: Wednesday, March 16, 2016 13:34
To: Kyle A Logue; Ettus Mail List
Subject: Re: [USRP-users] Time Alignment Error Across Multiple B200s with 10MHz/1PPS

On 03/16/2016 04:30 PM, Kyle A Logue wrote:

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

Make sure that your master-clock-rate doesn't change after you've set the time--like asking for a sample rate that would change
the desired master clock rate.  Ideally, setup your master-clock-rate in the device args, chose sample rates that are integer
fractions of that, preferrable divisible by 2.

If you set the TOD registers and THEN the master-clock-rate changes, there's going to be a glitch in timing.

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

You'll still need to do that for phase calibration--the frac-N synthesizers in the AD936x don't have a resynch feature that is used.

From: USRP-users usrp-users-bounces@lists.ettus.commailto:usrp-users-bounces@lists.ettus.com on behalf of Marcus D. Leech via USRP-users usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Sent: Wednesday, March 16, 2016 13:03
To: usrp-users@lists.ettus.commailto:usrp-users@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 herehttp://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@aero.orgmailto:kyle.logue@aero.org

From: USRP-users usrp-users-bounces@lists.ettus.commailto:usrp-users-bounces@lists.ettus.com on behalf of Garver, Paul W via USRP-users usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Sent: Wednesday, March 16, 2016 11:08
To: usrp-users@lists.ettus.commailto:usrp-users@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@ripnet.commailto:mleech@ripnet.com
To: usrp-users@lists.ettus.commailto:usrp-users@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@lists.ettus.commailto:USRP-users@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@lists.ettus.commailto:USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com