[USRP-users] Phase sync with different frequencies

John Shields john.shields at xtra.co.nz
Sat Nov 25 22:07:14 EST 2017

Hi Arjun,
             You mention that you have both units connected to ‘external PPS source, and have a MIMO cable between them’. Not sure where the Vref is coming from but I presume over the MIMO cable?

             I wonder how you are setting the clock and time source but I had an issue with my understanding of the behaviour of the MIMO cable in a configuration of 2xN200 each with an SBX.

             Firstly, while the documentation on MIMO doesn’t explicitly mention/highlight it, the PPS is not distributed over the MIMO cable – the RTC register of the master is copied to the slave which means that the slave doesn’t actually ‘see’ a PPS over the MIMO cable. This was not a big issue for me but it meant that operations such as get_last_pps and setting the ‘sync’ on the slave to ‘unknown PPS’ both fail though, get_time_now works, so your timed commands should be good.

             Secondly, while it is obvious when you think about it, if the slave is receiving Vref over the MIMO cable there will always be a fixed phase offset based, at a minimum, on the physical length of the MIMO so the Vref offset is a function of the frequency.

             Once I understood especially the second behaviour, my system performed as I would expect.

             I know that  your setup is different than mine (I was just supplying the same signal through a splitter to each USRP and measuring the phase offset), but wonder if this might explain your observations?

                     Kind Regards,



From: Bakshi, Arjun via USRP-users 
Sent: Sunday, November 26, 2017 10:28 AM
To: discuss-gnuradio at gnu.org ; usrp-users at lists.ettus.com 
Subject: [USRP-users] Phase sync with different frequencies

Hi all,

I'd like to use the phase resync freature on the SBX to get reliable phase alignment in the following setup:

link_freq1 = USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1
link_freq2 = USRP-B TX @ Freq2 ---> USRP-A RX @ Freq2

Where link_freq1 should always have phase X, and link_freq2 should always have phase Y. I measure the phase by first calculating the channel over a wire for that link. I then look at the phase of the channel.

The USRPs are connected to an external PPS source, and have a MIMO cable between them.

I've been able to use timed commands to get the same channel/phase every time (after multiple restarts) in a single link setup like:

USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1

But my code for phase sync in the 2-link setup doesn't seem to work(copied below). I understand that the phase of each link's channel may not be the same as the frequencies are different. However is it possible to set it up so that the phase/channel over wire in link_freq1 is always X and that in link_freq2 is always Y? Or is that impossible because of some hardware constraints?

Thank you,


code snippet:

## 2-channel usrp source and sink have been initialized, everything except 

## center feqs have been set

## uhd_usrp_source_0 is a  multi usrp source block

## uhd_usrp_sink_0 is a multi usrp sink block
## both blocks have device args set to : "addr0=, addr1="

## the following code is added in the init() function:


future_cmd_time = self.uhd_usrp_source_0.get_time_last_pps() + uhd.time_spec_t(1.0)

##My guess is that both physical USRPs should see this time since MIMO+same external PPS


self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf), 0)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf2), 1)

self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf2), 0)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf), 1)


This is in the init() function. I don't re-tune the frequencies again after this.

USRP-users mailing list
USRP-users at lists.ettus.com

This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171126/f2f97470/attachment-0002.html>

More information about the USRP-users mailing list