Octo-clock synchronization to multiple X310s contain a constant but random phase shift --why is it?

Question

I am using multiple X300/X310s to do a receive beamforming operation with synchronization to both Tx and all Rx devices with Octo-Clock. However I am seeing a constant but random phase shift across different USRPs, such phase shift is random upon each start-up/data collection but remains constant until I turn off the operation.

I had doubled checked that my Octo-clock is functioning properly. I am using GNU radio to drive my devices, and for my USRP source I am having the following set-ups:

Sync: to PC clock after next PPS (I also tried "unknown PPS" and it behaves the same)

Mbx Clock Source: External

Mbx Time Source: External

I am using an ethernet switch to run all my USRPs using 1 PC. My Tx daughter board is SBX and Rx daughter boards are UBXs.

This post describes a very similar situation:

With all of the above synchronization there will be a random amount of constant phase offset between the channels, as documented in figure 6 of: http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf This could be responsible for your consistent fractional offset. These needs to be signal processed to ensure alignment.

Unfortunately, the link referring to the answer does not exist anymore and I would like to know the reason and a possible direction to the solution. My array is built on a flexible substrate so it is hard to compensate without knowing more information.

Thanks in advance

I sent a pilot tone of 5kHz with 2.45GHz carrier. At the receiver, I captured the raw data from USRP and directly saves into a file which I process it using MATLAB.

Answer 1

I'm not personally informed about this subject, but I remember it being discussed on the discuss-gnuradio mailing list, in July 2016. A relevant excerpt:

Modern synthesizers use a technique called fractional-N synthesis. One of the side effects of this is that you can't predict where the LO will "lock" with respect to the reference clock. So, any two PLL synthesizers, even when feed an identical reference clock, will not have the same phase offset with respect to one another. It's the "physics" of fractional-N PLL synthesis.

SO, if you're using GRC to generate you flows, you'll have to modify the generated code, and wrap set_command_time()/clear_command_time() around the place in the code where it tunes the radios.

Clearly, if this depends on TIME, then all radios involved need to agree on the current time, to high precision, hence the related requirement for set_time_unknown_pps(), which uses the 1PPS signal to trigger loading of the time-of-day clocks on each USRP in the multi_usrp object.

There are more messages in the thread discussing some further details and troubleshooting the poster's setup, but I hope this is sufficient to explain why it happens, and what kind of fix you will need.

Answer 2

I had similar question here: Are the 4 Rx channels, organized by two B210s, synchronous?

Between different radios there is phase and time differense.

Even though two radios have same 10 MHz referense, this is only reference, it is NOT their local oscilator. So every local oscilator will locks on the referense 10 MHz signal but with different phase. This diference could be measured after start and compensate. But every timen when radio starts the loacal's oscilator phase will be different.

Other source for misalingment between streams from different radios is the time when different streams start. PPS does not guarenteed that both streams will start together. There is a need of special care, something called timed commands (as it is mentioned in the old post). In GNU radio it is achieved by python snippet block. Other way is writing dedicated C++ program. In uhd-host there is examples of timed commands written on C++.