USRP synchronization

GNU Radio
1

Hi All,

We are trying to use 4 USRPs to extract the phase information due to
differences in positions of the antennas.

In a standard communications system an internally generated carrier is
locked IN PHASE with the incoming signal to perform downconversion (see
Figure 1.).
http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg

As mentioned above we are using 4 USRPs to receive a signal from a
single
source. We wish to retain the phase information of this signal between
boxes
due to the different positions of the antennas. We feed all 4 boxes with
a
clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks
should be locked in phase with respect to each other. Are the internally
generated carriers generated using this clock as a phase reference, i.e.
is
it correct, that this should also make all the internally generated
carriers
have zero phase difference between the boxes instead of locking to the
phases of the incoming signals (see Figure 2.)?
http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg

However, when we observe the internal clocks of 4 USRPs they are phase
locked with respect to one another, but THERE IS A PHASE DIFFERENCE
BETWEEN
THEM, which is constant for a given power cycle. Does this imply that
the
phases of the internally generated carriers are locked to one another,
but
also with some NON 0 PHASE difference, i.e. that our actual system looks
like Figure 3?
http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg

Thanks,
Valentin.

View this message in context:
http://old.nabble.com/USRP-synchronization-tp27838821p27838821.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Tue, Mar 09, 2010 at 09:20:28AM -0800, ValentinG wrote:

However, when we observe the internal clocks of 4 USRPs they are phase
locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN
THEM, which is constant for a given power cycle. Does this imply that the
phases of the internally generated carriers are locked to one another, but
also with some NON 0 PHASE difference, i.e. that our actual system looks
like Figure 3?
http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg

Thanks,
Valentin.

Matt can provide more info when he gets a chance, but I’m pretty sure
that what you’re seeing is is normal and is due to the PLLs on the
daugherboards. There’s a finite number of phases that the PLL’s will
lock to depending on the ratios programmed into the PLLs. I don’t
recall which daughterboards use integer-N vs fractional-N PLL’s, but
they give different numbers of possible solutions.

Eric

3

On 03/09/2010 09:20 AM, ValentinG wrote:

However, when we observe the internal clocks of 4 USRPs they are phase
locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN
THEM, which is constant for a given power cycle. Does this imply that the
phases of the internally generated carriers are locked to one another, but
also with some NON 0 PHASE difference, i.e. that our actual system looks
like Figure 3?
http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg

Thanks,
Valentin.

I assume you are using all USRP2s. There are multiple sources of
ambiguity here.

First, unless you are using a common PPS signal to all systems, using
sync_on_pps, your time samples won’t be aligned. Think of it this way
– everyone’s watch is running at the same speed, but everybody thinks
the time is different because you haven’t coordinated. That’s what the
PPS is for

Second, and this is what Eric mentioned, the PLLs on the daughterboards
will all be locked to the same reference, but they can have an arbitrary
offset which will change every time you tune. The important thing is
that the relative phases don’t change with time. This means you can do
MIMO operations, but phased-arrays will require you to calibrate every
time. You can use the TX side of the RFX-series as a signal generate to
do this, but it will take some software.

You didn’t tell us what daughterboards you are using. The ones with the
integer-N PLLs (DBSRX, RFX-series) will have a finite number of
possibilities for that phase difference, usually less than 25, and you
can tune in such a way that there is no ambiguity if you are careful.
The fractional-N ones (XCVR2450, WBX) will have an effectively infinite
number of possibilities, but you can still measure it and compensate.

If you are just using the BasicRX or LFRX then you don’t have this
problem, you just need to align their DDC oscillators using PPS.

Matt

4

Thanks a lot for the answers!

Yes all of our boards are USRP2s.

We do have a common PPS signal provided by the external signal
generator. We
use code from the VRT branch and call set_time_at_next_pps for all 4
boards
to reset their times. Then we call start streaming for all 4 boards some
seconds later. This as we understand ensures the alignment of the
samples
received.

We use RFX2400 daughterboards.

There are a few other questions we wanted to ask:

1.) We observe a phase shift between MB clocks on different USRP2
MotherBoards which changes each time the USRP2 is reset. Is there a
finite
number of possibilities for that phase difference due to its PLL? How
many
are there?
2.) Does the PLL on the daughterboards uses the clock, generated on the
MBs
as a reference to lock the VCO signal used for downconversion? Or does
it
use the external 10MHz clock as the reference?
3.) If there is a finite number for the phase differences (N) between MB
clocks and these are used to produce the down-converter signal, which
can
also have a finite number of phase differences (M), this would imply
that we
can have NxM different phases, correct?

4.) Do the PLL’s on the daugherboard tune every time a C++ or Python
program
is run or every time the board is powered on? i.e. for phased arrays
will we
just need to calibrate every time the board is powered on or every time
we
take a given stream of data?
5.) How can we change the number of possible phases for the
daughterboard?
6.) Does reducing this number increase lock time?
7.) How can we tune so there is no ambiguity in the phase of the boards
like
you suggested?

Thanks,
Valentin

Matt E. wrote:

Figure 1.).
is
phases of the internally generated carriers are locked to one another,
ambiguity here.
that the relative phases don’t change with time. This means you can do

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/USRP-synchronization-tp27838821p27850577.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

On 03/10/2010 06:39 AM, ValentinG wrote:

Thanks a lot for the answers!

Yes all of our boards are USRP2s.

We do have a common PPS signal provided by the external signal generator. We
use code from the VRT branch and call set_time_at_next_pps for all 4 boards
to reset their times. Then we call start streaming for all 4 boards some
seconds later. This as we understand ensures the alignment of the samples
received.

OK, then you just have the RF phase issues.

We use RFX2400 daughterboards.

There are a few other questions we wanted to ask:

1.) We observe a phase shift between MB clocks on different USRP2
MotherBoards which changes each time the USRP2 is reset. Is there a finite
number of possibilities for that phase difference due to its PLL? How many
are there?

It depends where you are measuring. The main 100 MHz clock should
always come up with the same phase.

2.) Does the PLL on the daughterboards uses the clock, generated on the MBs
as a reference to lock the VCO signal used for downconversion? Or does it
use the external 10MHz clock as the reference?

It uses the clock from the motherboard, not the 10 MHz reference.

3.) If there is a finite number for the phase differences (N) between MB
clocks and these are used to produce the down-converter signal, which can
also have a finite number of phase differences (M), this would imply that we
can have NxM different phases, correct?

Basically, divisions produce ambiguity, multiplications remove it. To
take an example – assume you are using a 10 MHz reference and your
final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up
to 100 MHz, and will have no phase ambiguity. The 100 MHz is sent to
each daughterboard where it is divided by 16 to create the 6.25 MHz
compare frequency. This will have a 16-way ambiguity. This is then
multiplied up by 392 to get 2450. 16 is not a factor of 392, but 8 is.
So 16/8 = 2 and you get a 2-way ambiguity.

If, on the other hand, you choose 2456.25 MHz for your LO frequency, the
multiplication factor is 393, which shares no common factors with 16,
and so you have 16-way ambiguity. By judiciously choosing your R
divider and LO frequency, you can often get rid of the ambiguity.

I actually just thought of another possible way to do this which might
be even better, so let me think about that and I’ll get back to you.

4.) Do the PLL’s on the daugherboard tune every time a C++ or Python program
is run or every time the board is powered on? i.e. for phased arrays will we
just need to calibrate every time the board is powered on or every time we
take a given stream of data?

Every time you send the tune command. You should only send this when
you need to change frequency, not every time you start streaming.

5.) How can we change the number of possible phases for the daughterboard?
6.) Does reducing this number increase lock time?

Not a lot.

7.) How can we tune so there is no ambiguity in the phase of the boards like
you suggested?

Yes, you need to choose your factors carefully.

Matt

6

I’ll be away until the 22nd, but will give you an update on the possible
improved method when I get back.

Matt

7

Every time you send the tune command. You should only send this when
you need to change frequency, not every time you start streaming.

I have a special case. I want to transmit and then receive and then
transmit using xcvr2450. Will the phase of the transmitter be the same
during the first and second transmit ? I am assuming I call tune once,
and then receive and transmit on the same frequency.

BR/
Per

8

It depends where you are measuring. The main 100 MHz clock should
always come up with the same phase.

Ok we’ve found the problem, we were measuring a 10MHz signal on the test
pins which is derived from 100MHz, therefore has a 10-way ambiguity,
hence
different phases after power cycling… Checked the actual clock and
it’s
fine.

Basically, divisions produce ambiguity, multiplications remove it. To
take an example – assume you are using a 10 MHz reference and your
final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up
to 100 MHz, and will have no phase ambiguity. The 100 MHz is sent to
each daughterboard where it is divided by 16 to create the 6.25 MHz
compare frequency. This will have a 16-way ambiguity. This is then
multiplied up by 392 to get 2450. 16 is not a factor of 392, but 8 is.
So 16/8 = 2 and you get a 2-way ambiguity.

If, on the other hand, you choose 2456.25 MHz for your LO frequency, the
multiplication factor is 393, which shares no common factors with 16,
and so you have 16-way ambiguity. By judiciously choosing your R
divider and LO frequency, you can often get rid of the ambiguity.

In the example above you use the factor of 16 at the very start, where
does
it come from? Is it the decimation rate we use or it can be arbitrary?

I actually just thought of another possible way to do this which might
be even better, so let me think about that and I’ll get back to you.

Great!:slight_smile:

We have modified our c++ code to send all the configuration commands to
the
USRP2 boards (frequency, decimation, etc.) at the very start and pause.
Then
we perform 4 fetches of data, pausing after each one. 3 of those are
then
used to get calibration data, which is then used to refine the results
of
the 4th fetch. Is this a correct approach?

We have also tried sending all the configuration commands using a
separate
c++ script and then using a different script to perform the fetches, but
that doesn’t seem to work. Is that because every time the usrp2:make
command
is called it resets the configuration of the board?

Regards,
Valentin

Matt E. wrote:

boards

2.) Does the PLL on the daughterboards uses the clock, generated on the
can have NxM different phases, correct?
If, on the other hand, you choose 2456.25 MHz for your LO frequency, the
is run or every time the board is powered on? i.e. for phased arrays will
6.) Does reducing this number increase lock time?

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/USRP-synchronization-tp27838821p27869376.html
Sent from the GnuRadio mailing list archive at Nabble.com.

9

On 03/15/2010 10:24 PM, Per Z. wrote:

Every time you send the tune command. You should only send this when
you need to change frequency, not every time you start streaming.

I have a special case. I want to transmit and then receive and then
transmit using xcvr2450. Will the phase of the transmitter be the same
during the first and second transmit ? I am assuming I call tune once,
and then receive and transmit on the same frequency.

The XCVR2450 has one LO, and it runs continuously, whether or not you TX
or RX. So there won’t be phase discontinuities.

Matt

10

Hi Matt, hope you had a good trip.

We’ve managed to work around the ambiguity using calibration, but we are
still interested in that other technique that you’ve mentioned earlier.

Also we have trouble understanding the meanings of the phase ambiguities
we
are observing. We use a centre frequency of 2.45G which implies a 2-way
ambiguity, doesn’t this mean that 2 boards should have a phase of 0 or
180
with respect to each other? But we don’t observe this…

Kind regards,
Valentin

Matt E. wrote:

It depends where you are measuring. The main 100 MHz clock should
final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up

the
command

We

take an example – assume you are using a 10 MHz reference and your
divider and LO frequency, you can often get rid of the ambiguity.

just need to calibrate every time the board is powered on or every time
Not a lot.

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/USRP-synchronization-tp27838821p27990197.html
Sent from the GnuRadio mailing list archive at Nabble.com.