root / host / docs / sync.rst @ 725f72a4
History | View | Annotate | Download (7.2 KB)
| 1 |
======================================================================== |
|---|---|
| 2 |
UHD - Synchronization Application Notes |
| 3 |
======================================================================== |
| 4 |
|
| 5 |
.. contents:: Table of Contents |
| 6 |
|
| 7 |
The following application notes explain how to synchronize multiple USRPs |
| 8 |
with the goal of transmitting or receiving time-aligned samples for MIMO |
| 9 |
or other applications requiring multiple USRPs operating synchronously. |
| 10 |
|
| 11 |
**Note:** The following synchronization notes do not apply to USRP1, |
| 12 |
which does not support the advanced features available in newer products. |
| 13 |
|
| 14 |
------------------------------------------------------------------------ |
| 15 |
Common reference signals |
| 16 |
------------------------------------------------------------------------ |
| 17 |
USRPs take two reference signals in order to synchronize clocks and time: |
| 18 |
|
| 19 |
* A 10MHz reference to provide a single frequency reference for both devices, and |
| 20 |
* A pulse-per-second (1PPS) to synchronize the sample time across devices. |
| 21 |
|
| 22 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 23 |
Provide reference signals |
| 24 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 25 |
USRPs have two primary means of providing synchronization: |
| 26 |
|
| 27 |
**Method 1:** |
| 28 |
Connect the front panel SMA connectors to the reference sources. |
| 29 |
Typically, these signals are provided by an external GPSDO. |
| 30 |
However, some USRP models can provide these signals from an optional internal GPSDO. |
| 31 |
|
| 32 |
**Method 2:** |
| 33 |
Use the MIMO Expansion cable to share reference sources (USRP2 and N-Series). |
| 34 |
The MIMO cable can be used synchronize one device to another device. |
| 35 |
Users of the MIMO cable may use method 1 to synchronize multiple pairs of devices. |
| 36 |
|
| 37 |
**Note:** |
| 38 |
For users generating their own signals for the external SMA connectors, |
| 39 |
the pulse-per-second should be clocked from the 10MHz reference. |
| 40 |
See the application notes for your device for specific signal requirements. |
| 41 |
|
| 42 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 43 |
Set the clock configuration |
| 44 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 45 |
In order to synchronize to an external clock, |
| 46 |
configure the USRP device using the "external" clock configuration: |
| 47 |
|
| 48 |
:: |
| 49 |
|
| 50 |
usrp->set_clock_config(uhd::clock_config_t::external()); |
| 51 |
|
| 52 |
Sometimes the delay on the PPS signal will cause it to arrive inside the timing |
| 53 |
margin the FPGA sampling clock, causing PPS edges to be separated by less or |
| 54 |
more than 100million cycles of the FPGA clock. If this is the case, |
| 55 |
you can change the edge reference of the PPS clock with the clock_config_t: |
| 56 |
|
| 57 |
:: |
| 58 |
|
| 59 |
uhd::clock_config_t clock_config = uhd::clock_config_t::external(); |
| 60 |
clock_config.pps_polarity = uhd::clock_config_t::PPS_NEG; |
| 61 |
usrp->set_clock_config(clock_config); |
| 62 |
|
| 63 |
------------------------------------------------------------------------ |
| 64 |
Synchronizing the device time |
| 65 |
------------------------------------------------------------------------ |
| 66 |
The purpose of the PPS signal is to synchronously latch a time into the device. |
| 67 |
You can use the set_time_next_pps(...) function to either initialize the sample time to 0, |
| 68 |
or to an absolute time such as GPS time or UTC time. |
| 69 |
For the purposes of synchronizing devices, |
| 70 |
it doesn't matter what time you initialize to when using set_time_next_pps(...). |
| 71 |
|
| 72 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 73 |
Method 1 - poll the USRP time registers |
| 74 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 75 |
One way to initialize the PPS edge is to poll the "last PPS" time from the USRP device. |
| 76 |
When the last PPS time increments, the user can determine that a PPS has occurred: |
| 77 |
|
| 78 |
:: |
| 79 |
|
| 80 |
const uhd::time_spec_t last_pps_time = usrp->get_time_last_pps(); |
| 81 |
while (last_pps_time == usrp->get_time_last_pps()){
|
| 82 |
//sleep 100 milliseconds (give or take) |
| 83 |
} |
| 84 |
usrp->set_time_next_pps(uhd::time_spec_t(0.0)); |
| 85 |
|
| 86 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 87 |
Method 2 - query the GPSDO for seconds |
| 88 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 89 |
Most GPSDO can be configured to output a NMEA string over the serial port once every PPS. |
| 90 |
The user can wait for this string to determine the PPS edge, |
| 91 |
and the user can also parse this string to determine GPS time: |
| 92 |
|
| 93 |
:: |
| 94 |
|
| 95 |
//call user's function to wait for NMEA message... |
| 96 |
usrp->set_time_next_pps(uhd::time_spec_t(0.0)); |
| 97 |
|
| 98 |
-- OR -- |
| 99 |
|
| 100 |
//call user's function to wait for NMEA message... |
| 101 |
//call user's function to parse the NMEA message... |
| 102 |
usrp->set_time_next_pps(uhd::time_spec_t(gps_time+1)); |
| 103 |
|
| 104 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 105 |
Method 3 - internal GPSDO |
| 106 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 107 |
USRPs with internal GPSDOs properly configured will automatically |
| 108 |
configure themselves to set the VITA time to current UTC time. |
| 109 |
See the `GPSDO Application Notes <./gpsdo.html>`_ for more details. |
| 110 |
|
| 111 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 112 |
Method 4 - MIMO cable |
| 113 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 114 |
A USRP can synchronize its time to another USRP via the MIMO cable. |
| 115 |
Unlike the other methods, this does not use a real "pulse per second". |
| 116 |
Rather, the USRP sends an encoded time message over the MIMO cable. |
| 117 |
The slave device will automatically synchronize to the time on the master device. |
| 118 |
See the `MIMO Cable Application Notes <./usrp2.html#using-the-mimo-cable>`_ for more detail. |
| 119 |
|
| 120 |
------------------------------------------------------------------------ |
| 121 |
Synchronizing channel phase |
| 122 |
------------------------------------------------------------------------ |
| 123 |
|
| 124 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 125 |
Align CORDICs in the DSP |
| 126 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 127 |
In order to achieve phase alignment between USRPs, the CORDICS in both |
| 128 |
devices must be aligned with respect to each other. This is easily achieved |
| 129 |
by issuing stream commands with a time spec property, which instructs the |
| 130 |
streaming to begin at a specified time. Since the devices are already |
| 131 |
synchronized via the 10MHz and PPS inputs, the streaming will start at exactly |
| 132 |
the same time on both devices. The CORDICs are reset at each start-of-burst |
| 133 |
command, so users should ensure that every start-of-burst also has a time spec set. |
| 134 |
|
| 135 |
For receive, a burst is started when the user issues a stream command. This stream command should have a time spec set: |
| 136 |
:: |
| 137 |
|
| 138 |
uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); |
| 139 |
stream_cmd.num_samps = samps_to_recv; |
| 140 |
stream_cmd.stream_now = false; |
| 141 |
stream_cmd.time_spec = time_to_recv; |
| 142 |
usrp->issue_stream_cmd(stream_cmd); |
| 143 |
|
| 144 |
For transmit, a burst is started when the user calls send(). The metadata should have a time spec and start of burst set: |
| 145 |
:: |
| 146 |
|
| 147 |
uhd::tx_metadata_t md; |
| 148 |
md.start_of_burst = true; |
| 149 |
md.end_of_burst = false; |
| 150 |
md.has_time_spec = true; |
| 151 |
md.time_spec = time_to_send; |
| 152 |
|
| 153 |
//send a single packet |
| 154 |
size_t num_tx_samps = usrp->get_device()->send( |
| 155 |
buffs, samps_to_send, md, |
| 156 |
uhd::io_type_t::COMPLEX_FLOAT32, |
| 157 |
uhd::device::SEND_MODE_ONE_PACKET, timeout |
| 158 |
); |
| 159 |
|
| 160 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 161 |
Align LOs in the front-end |
| 162 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 163 |
After tuning the RF front-ends, |
| 164 |
each local oscillator may have a random phase offset due to the dividers |
| 165 |
in the VCO/PLL chains. This offset will remain constant after the device |
| 166 |
has been initialized, and will remain constant until the device is closed |
| 167 |
or re-tuned. This phase offset is typically removed by the user in MIMO |
| 168 |
applications, using a training sequence to estimate the offset. It will |
| 169 |
be necessary to re-align the LOs after each tune command. |