USRP Hardware Driver and USRP Manual: Device Synchronization

| USRP Hardware Driver and USRP Manual Version: 4.8.0.makepkg-0-g308126a4 UHD and USRP Manual |

Loading...
Searching...
No Matches
Device Synchronization

The following application notes explain how to synchronize multiple USRP devices with the goal of transmitting or receiving time-aligned samples for MIMO or other applications requiring multiple USRP devices operating synchronously.

Note: The following synchronization notes do not apply to USRP1, which does not support the advanced features available in newer products.

# Common Reference Signals

USRP devices take two reference signals in order to synchronize clocks and time:

- A 10 MHz reference to provide a single frequency reference for all devices (in some devices, other reference frequencies than 10 MHz are also supported).
- A pulse-per-second (PPS) to synchronize the sample time across devices.

The way these reference signals are provided to the devices varies.

## External PPS and 10 MHz reference signals

Most USRPs have SMA connnectors on the front- or back-panel to provide these signals (10 MHz reference and PPS). These signals could be provided by an OctoClock, an external/third-party GPSDO, a measurement device's reference outputs, or some other clock-generating device.

Connect these SMA connectors to the reference sources. In your software, select the external reference inputs as clock and time sources:

usrp->set_clock_source("external");
usrp->set_time_source("external");

Note: For users generating their own signals for the external SMA connectors, the PPS should be clocked from the 10 MHz reference. See the application notes for your device for specific signal requirements (e.g., voltage).

Note (N200/N210 and B100 only): Sometimes the delay on the PPS signal will cause it to arrive inside the timing margin of the FPGA sampling clock, causing PPS edges to be separated by less or more than 100 million cycles of the FPGA clock.

If this is the case, you can change the edge reference of the PPS signal with this parameter:

usrp->set_time_source("_external_");

## MIMO cable reference signals (N200-Series, USRP2)

Use the MIMO expansion cable to share reference sources (USRP2 and N200-Series only). The MIMO cable can be used to synchronize one device to another device. Users of the MIMO cable may use Method 1 (explained below) to synchronize multiple pairs of devices.

usrp->set_clock_source("mimo");
usrp->set_time_source("mimo");

# Synchronizing the Device Time

The purpose of the PPS signal is to synchronously latch a time into the device. You can use the uhd::usrp::multi_usrp::set_time_next_pps() function to either initialize the sample time to 0 or an absolute time, such as GPS time or UTC time. For the purposes of synchronizing devices, it doesn't matter what time you initialize to when using uhd::usrp::multi_usrp::set_time_next_pps().

## Method 1 - poll the USRP time registers

One way to initialize the PPS edge is to poll the "last PPS" time from the USRP device. When the last PPS time increments, the user can determine that a PPS has occurred:

const uhd::time_spec_t last_pps_time = usrp->get_time_last_pps();
while (last_pps_time == usrp->get_time_last_pps()){
//sleep 100 milliseconds (give or take)
}
// This command will be processed fairly soon after the last PPS edge:
usrp->set_time_next_pps(uhd::time_spec_t(0.0));
uhd::time_spec_t
Definition time_spec.hpp:31

## Method 2 - query the GPSDO for seconds

Most GPSDOs can be configured to output a NMEA string over the serial port once every PPS. The user can wait for this string to determine the PPS edge, and the user can also parse this string to determine GPS time:

//call user's function to wait for NMEA message...
usrp->set_time_next_pps(uhd::time_spec_t(0.0));
-- OR --
//call user's function to wait for NMEA message...
//call user's function to parse the NMEA message...
gps_time = VALUE_IN_NMEA_MESSAGE;
// At the next PPS edge, set the device time to the GPS time:
usrp->set_time_next_pps(uhd::time_spec_t(gps_time+1));
// Now the device time should be in sync with the GPS time.

Take a look at the `sync_to_gps` example for more detail.

## Method 3 - MIMO cable

Note: This only applies to USRP2 and N200/N210. This method does not require a separate PPS input to the devices, but it is limited to a total of 2 USRPs.

A USRP2 device can synchronize its time to another USRP device via the MIMO cable. Unlike the other methods, this does not use a real "pulse per second". Rather, the USRP device sends an encoded time message over the MIMO cable. The slave device will automatically synchronize to the time on the master device. See Using the MIMO Cable for more detail.

# Synchronizing Channel Phase

## Align CORDICs in the DSP

In order to achieve phase alignment between USRP devices, the CORDICS in both devices must be aligned with respect to each other. This is easily achieved by issuing stream commands with a time spec property, which instructs the streaming to begin at a specified time. Since the devices are already synchronized via the 10 MHz and PPS inputs, the streaming will start at exactly the same time on both devices. The CORDICs are reset at each start-of-burst command, so users should ensure that every start-of-burst also has a time spec set.

For receive, a burst is started when the user issues a stream command. This stream command should have a time spec set:

uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = samps_to_recv;
stream_cmd.stream_now = false;
stream_cmd.time_spec = time_to_recv;
usrp->issue_stream_cmd(stream_cmd);
uhd::stream_cmd_t
Definition stream_cmd.hpp:40
uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
@ STREAM_MODE_NUM_SAMPS_AND_DONE
Definition stream_cmd.hpp:44

For transmit, a burst is started when the user calls send(). The metadata should have a time spec set: :

uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = time_to_send;
//send a single packet
size_t num_tx_samps = tx_streamer->send(buffs, samps_to_send, md);
uhd::tx_metadata_t
Definition metadata.hpp:163
uhd::tx_metadata_t::end_of_burst
bool end_of_burst
Set end of burst to true for the last packet in the chain.
Definition metadata.hpp:178
uhd::tx_metadata_t::start_of_burst
bool start_of_burst
Set start of burst to true for the first packet in the chain.
Definition metadata.hpp:175
uhd::tx_metadata_t::time_spec
time_spec_t time_spec
When to send the first sample.
Definition metadata.hpp:172
uhd::tx_metadata_t::has_time_spec
bool has_time_spec
Definition metadata.hpp:169

## Align LOs in the front-end (SBX, UBX)

Using timed commands, multiple frontends can be tuned at a specific time. This timed-tuning ensures that the phase offsets between VCO/PLL chains will remain constant after each re-tune. See notes below:

- Phase synchronization with the UBX is only supported on the X3x0 Series
- Phase synchronization with the SBX works on both N2x0 and X3x0 Series
- There is a random phase offset between any two frontends
- This phase offset is different for different LO frequencies
- This phase offset remains constant after retuning
- This phase offset will drift over time due to thermal and other characteristics
- Periodic calibration will be necessary for phase-coherent applications

Code snippet example, tuning with timed commands:

//we will tune the frontends in 100ms from now
uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
//sets command time on all devices
//the next commands are all timed
usrp->set_command_time(cmd_time);
//tune channel 0 and channel 1
usrp->set_rx_freq(1.03e9, 0); // Channel 0
usrp->set_rx_freq(1.03e9, 1); // Channel 1
//end timed commands
usrp->clear_command_time();

## Align LOs in the front-end (others)

After tuning the RF front-ends, each local oscillator may have a random phase offset due to the dividers in the VCO/PLL chains. This offset will remain constant after the device has been initialized, and will remain constant until the device is closed or re-tuned. This phase offset is typically removed by the user in MIMO applications, using a training sequence to estimate the offset. It will be necessary to re-align the LOs after each tune command.