Syncrinization of two USRP2s

GNU Radio
1

Hi,

We’ve set up a test comparing a recieved white noise signal recieved by
two usrp2 recievers. The two receivers were clocked (1PPS and refclk) by
a GPS diciplined OCXO which outpus a 1PPS signal which is phase locked
to the 10 MHz reference. The daughterboard was the RFX400 configured
with a center frequency of 450 MHz and a decimation factor of 4. Several
cross spectrums between the two received signals shows that the
syncronisation is drifting by +/- 1 sample. We would like the difference
to not drift. Is this possible?

Regards,
//Ulrika

2

I was just recently fighting with this, and Matt told me that I have
to modify the firmware to get the USRP2 to lock (or at least this is
the easiest way to get the lock). Have you modified the firmware yet?
You need to add

clocks_mimo_config(MC_WE_LOCK_TO_SMA);

in the main() function of txrx.c and u2_init();

juha

3

We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2
(before the start of receiving). Is clocks_mimo_config() different from
config_mimo()?

I also read about the troubles with config_mimo before revision 10471,
but we use 10899 of the software, so that problem should be solved i
guess. The firmware used is the built version of 10766.

/Ulrika

-----Ursprungligt meddelande-----
Från: Juha V. [mailto:[email protected]]
Skickat: den 14 maj 2009 12:39
Till: Ulrika U.
Kopia: [email protected]
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s

I was just recently fighting with this, and Matt told me that I have to
modify the firmware to get the USRP2 to lock (or at least this is the
easiest way to get the lock). Have you modified the firmware yet?
You need to add

clocks_mimo_config(MC_WE_LOCK_TO_SMA);

in the main() function of txrx.c and u2_init();

juha

4

We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2 (before the start of receiving). Is clocks_mimo_config() different from config_mimo()?

This is correct. The host driver has the function call to cause the
USRP2 clock to synchronize with an external reference on the SMA, as
you are doing. Modifying the firmware to add a call to the firmware’s
internal clocks_mimo_config() function is possible, but not needed
unless you are creating a standalone USRP2 application.

Ok. I managed to get a lock only after modifying the firmware. Is
there some example for doing this on the host, I’m just wondering what
I did wrong.

juha

5

On Thu, May 14, 2009 at 4:44 AM, Ulrika U. [email protected]
wrote:

We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2 (before the start of receiving). Is clocks_mimo_config() different from config_mimo()?

This is correct. The host driver has the function call to cause the
USRP2 clock to synchronize with an external reference on the SMA, as
you are doing. Modifying the firmware to add a call to the firmware’s
internal clocks_mimo_config() function is possible, but not needed
unless you are creating a standalone USRP2 application.

Johnathan

6

On Thu, May 14, 2009 at 7:32 AM, Juha V. [email protected]
wrote:

Ok. I managed to get a lock only after modifying the firmware. Is
there some example for doing this on the host, I’m just wondering what
I did wrong.

Calling:

->config_mimo(MC_WE_LOCK_TO_SMA)

…from your host code usrp2 instance pointer commands the firmware to
invoke the same function you are calling in your modified firmware;
the results are identical.

Johnathan

7

Johnathan C. wrote:

On Thu, May 14, 2009 at 7:32 AM, Juha V. [email protected]
wrote:

Calling:

->config_mimo(MC_WE_LOCK_TO_SMA)

Johnathan

It will be grateful if python bindings for “config_mimo”,
“sync_every_pps”
are added to usrp2_base.h and usrp2.i in gr-usrp2.
(Until now, I have added them everytime when I updated the gnuradio.)

I am using “sync_every_pps” for synchronizing boundaries of frames
transmitted
from multiple USRP2. Since the samples are discarded when the samples
arrive
later than the preset timestamp value, I use “sync_every_pps” and set
timestamp value to 99999999 in order to guarantee transmission of the
frame.

Changkyu Seol

8

Ulrika U. wrote:

Hi,

We’ve set up a test comparing a recieved white noise signal recieved
by two usrp2 recievers. The two receivers were clocked (1PPS and
refclk) by a GPS diciplined OCXO which outpus a 1PPS signal which is
phase locked to the 10 MHz reference. The daughterboard was the
RFX400 configured with a center frequency of 450 MHz and a decimation
factor of 4. Several cross spectrums between the two received signals
shows that the syncronisation is drifting by +/- 1 sample. We would
like the difference to not drift. Is this possible?

I am not sure exactly what you mean by drifting by 1 sample. Are you
making use of the time fields in the received data?

The first thing to do would be to make sure that both USRP2s are locked
to the reference. You can do this by calling

clocks_enable_test_clk(true, 1);

in the firmware. This will turn on the clock on J503 of the USRP2
motherboards. Pins 1 and 4 of that connector are ground, and 2 and 3
are the differential clock. Connect an oscilloscope to those pins on
each USRP2 and make sure that the clocks do not drift relative to each
other. They should be perfectly locked and in phase.

The second issue is the 1 pps signal. It must be synchronous with the
10 MHz reference clock. GPSDOs have 2 types of PPS outputs, those that
are synchronous to the OCXO (often called ocxo-derived) and those that
are directly generated by the GPS. You need to use the former.

One final issue is that depending on the relative delay of your PPS and
10 MHz signals, you might want to sample PPS on the positive edge or
negative edge. If you are using the wrong edge, there may be timing
issues. To set this, in the firmware call:

timesync_regs->tick_control = 0xC; // Positive edge
or
timesync_regs->tick_control = 0x4; // Negative edge, default

Matt

9

And again we are back to this misspelled topic.

Thank you Matt for your reply. It turned out that we used non
synchronous 1PPS and 10 MHz signals after all, and by using a 1PPS
synchronous to the 10 MHz we got different results.

However, we still don’t get the time stamped samples to be perfectly
synchronous in time (yes we do use the time field in the received data).
We believe that the DDC is the issue here. Is there any present solution
to reset the DDC at a certain time (for example at the PPS signal)?

Best regards
Ulrika

-----Ursprungligt meddelande-----
Från: Matt E. [mailto:[email protected]]
Skickat: den 14 maj 2009 19:07
Till: Ulrika U.
Kopia: [email protected]
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s

Ulrika U. wrote:

Hi,

We’ve set up a test comparing a recieved white noise signal recieved
by two usrp2 recievers. The two receivers were clocked (1PPS and
refclk) by a GPS diciplined OCXO which outpus a 1PPS signal which is
phase locked to the 10 MHz reference. The daughterboard was the RFX400
configured with a center frequency of 450 MHz and a decimation factor
of 4. Several cross spectrums between the two received signals shows
that the syncronisation is drifting by +/- 1 sample. We would like the
difference to not drift. Is this possible?

I am not sure exactly what you mean by drifting by 1 sample. Are you
making use of the time fields in the received data?

The first thing to do would be to make sure that both USRP2s are locked
to the reference. You can do this by calling

clocks_enable_test_clk(true, 1);

in the firmware. This will turn on the clock on J503 of the USRP2
motherboards. Pins 1 and 4 of that connector are ground, and 2 and 3
are the differential clock. Connect an oscilloscope to those pins on
each USRP2 and make sure that the clocks do not drift relative to each
other. They should be perfectly locked and in phase.

The second issue is the 1 pps signal. It must be synchronous with the
10 MHz reference clock. GPSDOs have 2 types of PPS outputs, those that
are synchronous to the OCXO (often called ocxo-derived) and those that
are directly generated by the GPS. You need to use the former.

One final issue is that depending on the relative delay of your PPS and
10 MHz signals, you might want to sample PPS on the positive edge or
negative edge. If you are using the wrong edge, there may be timing
issues. To set this, in the firmware call:

timesync_regs->tick_control = 0xC; // Positive edge or
timesync_regs->tick_control = 0x4; // Negative edge, default

Matt

10

We have already implemented start_streaming_at(0) (see attached file).
The problem is that the FPGA doesn’t reset the ddc on PPS so the sample
marked with ‘time stamp’ = 0 is delayed by an unknown fractional number
of samples realtive to the output rate.

regards

Patrik and Ulrika

Från: discuss-gnuradio-bounces+patrik.eliardsson=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+patrik.eliardsson=removed_email_address@domain.invalid] För
Douglas G.
Skickat: den 8 juni 2009 15:08
Till: Ulrika U.
Kopia: [email protected]
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s

How are you starting the streaming samples from the two USRP2’s? The
default start_rx_streaming call (and thus, the standard usrp2_source
block) just starts streaming when it receives the command from the host
PC. So any delay between when each USRP2 receives the command over the
gig-E interface means will be reflected in the timestamps of the frames
they send back. In other words, the internal clocks are/maybe
synchronized, but you won’t be able to tell that from the timestamps
alone.
I’m sitting on a (at least mostly working) patch to add a
start_rx_streaming_at(…) call to the USRP2 host and firmware code,
which lets you specify a time (according to the USRP2’s internal timer)
to start streaming at. I use this to send a sync_to_pps() command, and
then start streaming at a specific time (since the sync_to_pps() should
result in the timer getting reset to zero at the same time on each
USRP2). From what I understand this will be much easier to do with the
usrp2-vrt rewrite, but in the meantime, I expect to be sending the patch
to the list soon.
Doug

On Mon, Jun 8, 2009 at 6:51 AM, Ulrika U.
<[email protected]mailto:[email protected]> wrote:
And again we are back to this misspelled topic.

Thank you Matt for your reply. It turned out that we used non
synchronous 1PPS and 10 MHz signals after all, and by using a 1PPS
synchronous to the 10 MHz we got different results.

However, we still don’t get the time stamped samples to be perfectly
synchronous in time (yes we do use the time field in the received data).
We believe that the DDC is the issue here. Is there any present solution
to reset the DDC at a certain time (for example at the PPS signal)?

Best regards
Ulrika

11

How are you starting the streaming samples from the two USRP2’s? The
default start_rx_streaming call (and thus, the standard usrp2_source
block)
just starts streaming when it receives the command from the host PC. So
any
delay between when each USRP2 receives the command over the gig-E
interface
means will be reflected in the timestamps of the frames they send back.
In
other words, the internal clocks are/maybe synchronized, but you won’t
be
able to tell that from the timestamps alone.
I’m sitting on a (at least mostly working) patch to add a
start_rx_streaming_at(…) call to the USRP2 host and firmware code,
which
lets you specify a time (according to the USRP2’s internal timer) to
start
streaming at. I use this to send a sync_to_pps() command, and then start
streaming at a specific time (since the sync_to_pps() should result in
the
timer getting reset to zero at the same time on each USRP2). From what I
understand this will be much easier to do with the usrp2-vrt rewrite,
but in
the meantime, I expect to be sending the patch to the list soon.
Doug