docs: Add X420 documentation

This adds the documentation for the 20 GHz USRP X420.

host/docs/02_devices.dox

@@ -36,6 +36,7 @@ __Daughterboards__
 \li \subpage page_dboards
 \li \ref page_twinrx
 \li \ref page_zbx
+\li \ref page_hbx
 \li \ref page_fbx
 
 __OctoClock__

host/docs/devices/dboards.dox

@@ -558,11 +558,24 @@ Features:
 - Frequency Range: 1 MHz to 8 GHz
 - Relative Gain Range: 0 - 60 dB (RX gain range reduced below 500 MHz)
 
-The ZBX daughterboard only works with the X410 motherboard.
+The ZBX daughterboard is part of the Ettus USRP X410.
 
 More information:
 \li \subpage page_zbx
 
+\subsection dboards_hbx HBX XCVR board
+
+Features:
+- Single channel transceiver
+- TX/RX 0 and RX 1 antenna ports
+- Frequency Range: 10 MHz to 20 GHz
+- Relative gain range: 0 - 68 dB (TX), 0 - 48 dB (RX) - exact ranges depend on frequency band
+
+The HBX daughterboard is part of the Ettus USRP X420.
+
+More information:
+\li \subpage page_hbx
+
 \subsection dboards_fbx FBX XCVR board
 
 Features:
@@ -571,7 +584,7 @@ Features:
 - Frequency Range: 30 MHz to 4 GHz
 - Relative Gain Range: 0 dB (no gain control)
 
-The FBX daughterboard only works with the X440 motherboard.
+The FBX daughterboard is part of the Ettus USRP X440.
 
 More information:
 \li \subpage page_fbx

host/docs/devices/hbx.dox

@@ -0,0 +1,401 @@
+/*! \page page_hbx HBX Daughterboard
+
+\tableofcontents
+
+\section hbx_overview Overview
+
+The HBX daughterboard is a one-channel transceiver based primarily on direction conversion,
+addressing 5G NR FR3 and X-/KU-Band needs for research and prototyping in a frequency range of
+10 MHz up to 20 GHz. It supports analog bandwidths of up to 1 GHz.
+
+The HBX daughterboard is the daughterboard of the Ettus USRP X420.
+
+Feature list:
+- Frequency range (Tx and Rx): 10 MHz - 20 GHz
+- Number of channels: 1
+- Maximum analog bandwidth: 
+  - 200 MHz between 10 MHz and 2.2 GHz center frequency
+  - 1 GHz between 2.2 GHz and 20 GHz center frequency
+
+See the RF section in the <a href="https://www.ni.com/docs/bundle/usrp-x420-specs/page/specs.html">Ettus
+USRP X420 Specification</a> for a comprehensive HBX daughterboard specification list.
+
+\section hbx_too Theory of Operation
+
+The HBX daughterboard has one transceiver chain. The following simplified block
+diagram shows the structure:
+
+\image html hbx_simplified_blockdiagram.svg "HBX block diagram" width=80%
+
+The HBX daughterboard is a direct sampling transceiver in the frequency range of 10 MHz
+to 500 MHz, and a direct conversion transceiver in the frequency range of >500 MHz
+to 20 GHz.
+On the TX side, bands 0 to 3 are used to create the output signal: 
+- Band 0: 10 MHz to 500 MHz
+  - Direct sampling, no LO used
+- Band 1: > 500 MHz to 6 GHz
+  - LO used directly
+- Band 2: > 6 GHz to 9 GHz
+  - LO multiplied by 2
+  - TX Mixer in bypass mode for gain selection only
+- Band 3: > 9 GHz to 20 GHz
+  - LO multiplied by 4
+  - Upconverter chip used for mixing and gains
+
+On the RX side, bands 0 to 2 are used to receive the input signal:
+- Band 0: 10 MHz to 500 MHz
+  - Direct sampling, no LO used
+- Band 1: > 500 MHz to 9 GHz
+  - LO used directly until 6 GHz, then multiplied by 2
+  - Downconverter chip in bypass mode for gain selection only
+- Band 2: > 9 GHz to 20 GHz
+  - LO multiplied by 4
+  - RX Mixer used for mixing and gains
+
+The LO synthesizers in TX and RX are identical (LMX2572) but independent. When tuning
+to a frequency in band 0, the LO will remain at its last set frequency and its output
+power will be set to the minimum. The various gain stages are spread out along the TX
+and RX paths - see also \ref hbx_gain_control for more details.
+
+\subsection hbx_too_cpld Digital Control
+
+For digital controls, the HBX daughterboard includes a CPLD. The CPLD is controlled via registers. Its
+register space is exposed as a subset of the RFNoC radio blocks' register space (starting
+at address 0x80000). The CPLD is used to control all switches, DSAs, amplifiers, LEDs, LO
+synthesizers and power rails. The CPLD also controls state-dependent behavior of the HBX daughterboard
+(i.e., behavior depending on the RX/TX state). For this purpose, ATR signals from the
+FPGA are routed to the CPLD. Parts of the CPLD feature set are also described in 
+\ref hbx_gain_control.
+
+\subsection hbx_too_lo_control LO Control
+
+The normal operation of the HBX daughterboard is to simply tune it to a desired center
+frequency, and UHD will internally determine the frequency for the corresponding LO.
+However, when using the LO sharing feature it is important to understand what the LO
+is set to and how to use it.
+Firstly, both in TX and RX the LO is only used at frequencies above 500 MHz. Between
+500 MHz and 6 GHz, the LO is used directly. The LO frequency equals the center 
+frequency, in that case. Between 6 GHz and 9 GHz, the LO is multiplied by 2. The
+LO frequency is half of the center frequency in that case. Above 9 GHz, the LO is multiplied by 4,
+so the LO frequency is a quarter of the center frequency.
+If the LO is shared between two or more X420 devices, setting the same TX/RX frequency
+for all channels involved will work as expected, as the LO will be set to the correct
+frequency for all channels.
+
+Nevertheless, the state of the individual LOs can be queried and configured independently.
+Use the following API calls to do so:
+- multi_usrp API:
+  - uhd::usrp::multi_usrp::get_rx_lo_freq()
+  - uhd::usrp::multi_usrp::get_rx_lo_freq_range()
+  - uhd::usrp::multi_usrp::set_rx_lo_freq()
+  - uhd::usrp::multi_usrp::get_tx_lo_freq()
+  - uhd::usrp::multi_usrp::get_tx_lo_freq_range()
+  - uhd::usrp::multi_usrp::set_tx_lo_freq()
+- RFNoC API:
+  - uhd::rfnoc::radio_control::get_rx_lo_freq()
+  - uhd::rfnoc::radio_control::get_rx_lo_freq_range()
+  - uhd::rfnoc::radio_control::set_rx_lo_freq()
+  - uhd::rfnoc::radio_control::get_tx_lo_freq()
+  - uhd::rfnoc::radio_control::get_tx_lo_freq_range()
+  - uhd::rfnoc::radio_control::set_tx_lo_freq()
+
+The name of the LOs will always be "HBX_LO", regardless of RX or TX direction. 
+Note that manually modifying LOs is considered an advanced operation, and may result in
+a bad state of the device. To undo manual changes, use the regular API calls to set
+a center frequency again.
+
+\subsection hbx_too_lo_sharing LO Sharing
+
+The HBX daughterboard supports sharing the LO between multiple X420 channels. LO sharing
+requires external cabling between the LO connectors. One channel acts as the LO master
+and exports the LO, while all other channels import that same LO signal.
+
+As mentioned in \ref hbx_too_lo_control, TX and RX LOs are independent. Therefore,
+LO sharing must be configured separately for TX and RX.
+
+\image html hbx_lo_sharing_1-1_cascaded_lo.svg "LO sharing between two channels (direct channel-to-channel cabling)" width=45%
+
+\image html hbx_lo_sharing_1-2_cascaded_lo_with_external_splitter.svg "Recommended two-channel topology: LO master also imports its exported LO via an external splitter" width=45%
+
+\image html hbx_lo_sharing_1-8_cascaded_lo_with_distribution_module.svg "Multi-device topology using an external LO distribution module" width=80%
+
+The second topology is the recommended setup for two channels: The LO master also imports
+its own exported LO, so all channels see comparable external path delay. This helps avoid
+phase offsets due to asymmetric routing.
+
+For sharing across more than two channels (or across multiple devices), use an external
+LO distribution and amplifier module. 
+
+The following example shows how to set up TX LO sharing, as shown in the second diagram above, 
+where the LO master exports its LO and both channels import this LO, so that both channels 
+see the same external path delay:
+
+~~~{.cpp}
+// Assumption: 'usrp' is a multi_usrp object
+// Export the TX LO (known as "HBX_LO") of channel 0
+usrp->set_tx_lo_export_enabled(true, "HBX_LO", 0);
+// Import the exported LO again to account for external path lengths
+usrp->set_tx_lo_source("external", "HBX_LO", 0);
+// Make the TX LO (also known as "HBX_LO") of channel 1 use the external LO input
+usrp->set_tx_lo_source("external", "HBX_LO", 1);
+~~~
+
+The frequency of an externally-provided LO signal, necessary to get to a target 
+center frequency, can be determined by setting the desired center frequency on 
+the USRP using set_*x_frequency(), and then querying the LO frequency.
+If the LO is shared among multiple X420 channels, it is sufficient to tune them all
+to the same frequency, and the LO will be set to the correct frequency for all channels.
+
+By default, the output power of the exported LO signal will be close to 0 dBm.  If more power
+is required, the LO power can be adjusted by using the \ref hbx_gain_control to set
+the "LO_PWR_EXT" gain stage. This setting controls the output power of the LMX2572
+LO synthesizer. 
+
+The expected input power level at the LO input connector is 0 dBm for best performance as well.
+To read back the LO power going into the chain (after the "LO_DSA" stage), use the
+"lo_pd" sensor described in \ref hbx_sensors. The "lo_pd" readback value is expected to
+vary with frequency, temperature, and voltage, and should therefore be used
+as an uncalibrated reference (not as an absolute calibrated power measurement).
+
+To match an externally-provided LO signal to the internal LO conditions, first measure the 
+internal LO power using the "lo_pd" sensor at your target operating frequency (for example, 
+-10 dBm). Then adjust the external LO power and/or the "LO_DSA" gain stages until "lo_pd"
+reports a similar value at the same frequency. This ensures comparable LO drive levels.
+
+To adjust the "LO_DSA" gain stage, use the manual gain profile (see \ref hbx_gain_manual).
+Note that higher "LO_DSA" gain index values result in more LO power in the RF chain.
+
+\section hbx_ant_ports Antenna Ports
+
+The HBX daughterboard has two physical SMA antenna ports called "TX/RX0"
+and "RX1".
+
+In UHD, antenna values select the different antenna configurations. The supported values are:
+- "TX/RX0": Uses the shared TX/RX0 antenna port,
+- "RX1": Uses the RX1 antenna port,
+- "CAL_LOOPBACK": Loops the TX path into the RX path internally (this is required for calibration purposes),
+- "TERMINATION": Terminates the RX path internally,
+- "SYNC_INT": Feeds a 5 MHz square wave into the ADC for internal reference.
+
+Use the uhd::usrp::multi_usrp::get_rx_antennas() or uhd::usrp::multi_usrp::get_tx_antennas()
+API calls to enumerate the valid antenna names. When using the RFNoC API, use the 
+uhd::rfnoc::radio_control::get_rx_antennas() and uhd::rfnoc::radio_control::get_tx_antennas()
+calls, respectively.
+
+\section hbx_leds Status LEDs
+
+The HBX daughterboard is equipped with four LEDs: 
+- One for "TX/RX0",
+- one for "RX1",
+- one for the TX LO,
+- and one for the RX LO.
+
+The LEDs indicate the status of the corresponding components, providing visual feedback on
+the operation of the HBX daughterboard:
+
+| LED State | TX/RX0               | RX1               |
+|-----------|----------------------|-------------------|
+| Off       | Port is inactive     | Port is inactive  |
+| Green     | Port is receiving    | Port is receiving |
+| Red       | Port is transmitting | N/A               |
+
+| LED State | TX LO               | RX LO               |
+|-----------|---------------------|---------------------|
+| Off       | No LO sharing       | No LO sharing       |
+| Green     | External LO is used | External LO is used |
+| Red       | LO is exported      | LO is exported      |
+
+\section hbx_pwr_cal Power Calibration
+
+The HBX daughterboard supports the UHD power API. To use this, the device needs to be calibrated manually
+as described in \ref page_power.
+
+\section hbx_sensors Sensors
+
+Every channel has two sensors for the LO stages ("lo_locked" and "nco_locked").
+The "lo_locked" sensor indicates whether the LO synthesizer is locked to the desired
+frequency. The "NCO lock" sensor is a special case: The NCO is not located on the daughterboard but on the motherboard's RFSoC FPGA.
+To simplify the API, it was placed together with the
+LO lock sensors. Unlike the (analog) synthesizers on the daughterboard, the NCO "unlock"
+is not used to signify a loss of reference lock, but to signal that the NCO is
+still in reset.
+
+Additionally, the HBX daughterboard has a temperature sensor called "temperature" which returns
+the mean value of the temperature sensors that are placed on the top and the bottom of the dauhterboard. Top and bottom sensors
+can be accessed with "temperature_top" and "temperature_bottom", respectively.
+While the UHD API allows addressing a sensor based on direction (RX/TX) and 
+channel, the return value will be the same regardless of which channel or
+direction is selected.
+
+Furthermore, the HBX daughterboard has a "lo_pd" sensor which gives access to the LO power
+detector. Depending on if the internal LO or an external LO is used, the 
+returned value will be the power of the internal or the external LO, respectively.
+
+The following API calls can be used to enumerate available sensors, and query
+their values:
+- multi_usrp API:
+  - uhd::usrp::multi_usrp::get_rx_sensor_names()
+  - uhd::usrp::multi_usrp::get_rx_sensor()
+  - uhd::usrp::multi_usrp::get_tx_sensor_names()
+  - uhd::usrp::multi_usrp::get_tx_sensor()
+- RFNoC API:
+  - uhd::rfnoc::radio_control::get_rx_sensor_names()
+  - uhd::rfnoc::radio_control::get_rx_sensor()
+  - uhd::rfnoc::radio_control::get_tx_sensor_names()
+  - uhd::rfnoc::radio_control::get_tx_sensor()
+
+\section hbx_gain_control Gain Control
+
+The HBX daughterboard has a sophisticated gain control, capable of controlling either an overall
+gain, or manually controlling its individual gain stages. 
+
+Depending on the frequency band, different gain stages are active. In the RX bands
+from 10 MHz up to 2.9 GHz the gain is controlled by two low-frequency DSAs. In the bands
+above, one RF DSA and a cascade of DSAs in the mixer chip are used. On the TX side below
+6 GHz, the gain is controlled by a single RF DSA. Above 6 GHz, this RF DSA is used
+together with the gain stages in the TX mixer. Refer to the HBX block diagram
+at \ref hbx_too for a visual representation of the gain stages in the signal path.
+
+To switch between gain profiles, use the uhd::usrp::multi_usrp::set_tx_gain_profile()
+or uhd::usrp::multi_usrp::set_rx_gain_profile() API calls. When using the RFNoC
+API, use the uhd::rfnoc::radio_control::set_tx_gain_profile() or
+uhd::rfnoc::radio_control::set_rx_gain_profile() API calls. The main difference
+between these APIs is that the multi_usrp API calls allow a default channel
+value, which the RFNoC API calls do not.
+
+As with all other devices, the following API calls set or query gain values:
+- Multi USRP:
+  - uhd::usrp::multi_usrp::set_tx_gain()
+  - uhd::usrp::multi_usrp::get_tx_gain()
+  - uhd::usrp::multi_usrp::set_rx_gain()
+  - uhd::usrp::multi_usrp::get_rx_gain()
+- RFNoC
+  - uhd::rfnoc::radio_control::set_tx_gain()
+  - uhd::rfnoc::radio_control::get_tx_gain()
+  - uhd::rfnoc::radio_control::set_rx_gain()
+  - uhd::rfnoc::radio_control::get_rx_gain()
+
+These API calls come in different flavours, with an optional "gain name" argument.
+Note the multi_usrp API calls default to setting the overall gain value, which
+is not allowed in all gain profiles. All API calls have a corresponding API call
+to query the supported gain range.
+
+\subsection hbx_gain_default Default Gain Profile
+
+This gain profile is active by default. It allows setting a single, scalar gain 
+value. UHD will internally use a gain table to linearize the overall gain, meaning
+that a 1 dB gain increase will also increase the transmit or receive power by 1 dB.
+Since the RF DSA that is used in the TX path between 10 MHz and 6 GHz only has a step
+width of 2 dB, only every second gain index step will result in an increase of 2 dB
+in power in those bands.
+The UHD-internal gain table is not calibrated per-device, nor does it take 
+into account temperature or other changes. The gain index values that can
+be set via the API are mapped in a way that for the same gain index, across all bands,
+the frequency response will be rather flat. However, this means that while the overall
+gain range is given by the API, the effective gain range may vary across the full
+frequency range depending on the band. For consistency reasons, the API will
+still report values for the full gain range, as changing frequencies could result
+in a changed gain index otherwise.
+
+In this gain profile, it is not possible to set the individual gain stages directly, but
+it is possible to read them back. This may be helpful when trying to fine-tune gain
+settings in software.
+
+~~~{.cpp}
+// Assumption: 'usrp' is a multi_usrp object
+usrp->set_tx_gain_profile("default"); // Only necessary if the gain profile was set to something else before
+usrp->set_tx_gain(50); // Will set the gain to 50 dB on all associated daughterboards
+std::cout << usrp->get_tx_gain() << std::endl; // Should print "50"
+usrp->set_tx_gain(0, "RF_DSA"); // Will cause an exception
+// Individual DSAs may still be queried. Note that even though this is an
+// attenuator, the return value is a gain (higher values mean more TX power):
+auto rf_dsa_gain = usrp->get_tx_gain("RF_DSA");
+~~~
+
+The individual gain names for the individual DSAs can be read out by using the manual gain
+profile. 
+
+<b>ATR Behaviour:</b> The gains will apply to their respective ATR state, i.e.,
+RX gains will be applied to both the RX and full-duplex state, and TX gains will
+be applied to the TX and full-duplex state. In the idle state, gains are set to
+minimum gain.
+
+\subsection hbx_gain_manual Manual Gain Profile
+
+\b Note: The gain tables for the default gain profile have been defined to prevent
+any damage to the device as long as the input signal power level is below the specified maximum input level. However, when
+using the manual gain profile, it is possible to set gain values that could lead to
+device damage, even if the input signal power level is below the specified maximum input power level. It is a good practice
+to first set the desired center frequency and (maximum) gain index using the default gain
+profile, and then switch to the manual gain profile to read out the gain values for the
+individual stages as baseline, and to modify them if desired. 
+
+When more control is desired, the manual gain profile can be applied. Here, it is no longer
+possible to request an overall gain value. However, it is now possible to set the DSA values
+directly.
+
+~~~{.cpp}
+usrp->set_tx_gain_profile("manual");
+usrp->set_tx_gain(30); // ERROR: Now, we have to specify a name
+auto gain_names = usrp->get_tx_gain_names(0); // Returns a list of all TX gain names for channel 0
+// From that list, pick the desired gain stage, e.g. RF_DSA
+usrp->set_tx_gain(5, "RF_DSA"); // Set RF_DSA to 5 dB gain (equals 26 dB attenuation)
+// The following line will return an undefined value and print a warning, but
+// will not throw an exception. That's because calling the overall gain is a common API call
+// done by many utilities, and this behaviour is considered most backward compatible.
+std::cout << usrp->get_tx_gain() << std::endl;
+std::cout << usrp->get_tx_gain("RF_DSA") << std::endl; // Should print '5'
+~~~
+
+\section hbx_atr Auto-Transmit-Receive Registers (ATR)
+
+Like other USRPs, the X420 provides GPIOs to the daughterboards that communicate
+the RX/TX state. The HBX daughterboard is, by default, configured to switch settings based on
+the current state (idle, RX, TX, full duplex). For example, the TX/RX antenna
+is switched between the TX and RX channels depending on the state. A total of 2
+GPIOs between the motherboard FPGA and the daughterboard CPLD are used for this
+purpose.
+
+HBX uses these pins to select between different RF control values
+(e.g., the aforementioned TX/RX antenna switch position; this also includes the
+front-panel LEDs) as well as DSA controls (e.g., when doing RX only, the TX gain
+stages can be set to zero to minimize leakage). Internally, this works by
+converting the ATR pins into a control word. This control word is used to index
+tables that contain different values for RF control/LEDs as well as DSAs.
+
+Example: Assume the device is transmitting, but not receiving, on channel 0. The
+FPGA will set the ATR pins for channel 0 to a binary value of 0b10, which equals
+a decimal value of 2. The transmit gain is controlled by DSA values that are
+stored in tables called e.g. RF_DSA. For the duration of the transmission, the
+DSA values at table position RF_DSA[2] will thus be used.
+Similarly, tables for RF path control and LEDs are used to
+configure those. This mode of using the ATR pins is called the "classic ATR" mode
+and is the default behaviour.
+
+The HBX daughterboard provides one additional mode of utilizing those pins, the
+"Software Defined" mode: In this mode, the ATR pins are ignored. The control word
+is derived from another register. In this case, changing the table index
+requires another register write as opposed to the almost instantaneous tracking
+of the ATR state in the other mode.
+
+Usage of this mode is considered highly advanced usage of HBX. The "Software
+Defined" mode is not supported by UHD without custom modifications (it is
+possible, however, to manually write to the appropriate registers to use this
+mode).
+
+~~~{.cpp}
+// Assumption: 'radio' is a radio_control object
+// Set the software defined mode. This will affect TX and RX channels of the
+// same daughterboard.
+radio->poke32(0x810a4, 0); // Set the ATR mode to "Software Defined" (0)
+// E.g. set receive state (states are: 0: idle, 1: RX, 2: TX, 3: TRX)
+radio->poke32(0x810a0, 1); // Set the control word to 1 for RX
+// Return to classic ATR:
+radio->poke32(0x810a4, 1); // Set the ATR mode to "Classic" (1)
+~~~
+
+For detailed information about the register
+layout and addresses, refer to the <a href="https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x400/doc/X420/X420_FPGA.htm">X420 FPGA register map documentation</a>.
+
+*/
+// vim:ft=doxygen:

host/docs/devices/usrp_x4xx.dox

@@ -35,38 +35,44 @@
   - USRP X410: 4x full-duplex RF channels with a maximum analog bandwidth of
     400 MHz, tunable from 1 MHz - 7.2 GHz center frequency (tunable to 8 GHz)
     using \subpage page_zbx
+  - USRP X420: 2x full-duplex RF channels with a maximum analog bandwidth of
+    1000 MHz, tunable from 10 MHz - 20 GHz center frequency, support for external
+    LOs and LO sharing between multiple devices, using \subpage page_hbx
   - USRP X440: 8x full-duplex direct-sampling channels, configurable center
     frequencies 30 MHz - 4 GHz (tunable 1 MHz - 4 GHz), with a maximum sampling
     rate of 2048 Msps, using \subpage page_fbx
 
 \section x4xx_overview Overview and Features
 
-The X4x0 series of USRPs comes in two variants: The USRP X410, and the USRP X440.
-Both variants share the same enclosure and motherboard, and are collectively
-referred to as X4x0.
+The X4x0 series of USRPs comes in three variants: The USRP X410, the USRP X420,
+and the USRP X440. All three variants share the same enclosure and motherboard,
+and are collectively referred to as X4x0.
 
 \image html x410.png "Ettus USRP X410" width=50%
+\image html x420.png "Ettus USRP X420" width=50%
 \image html x440.png "Ettus USRP X440" width=50%
 
 The Ettus USRP X4x0 is a fourth-generation Software Defined Radio (SDR) out of the USRP
 family of SDRs. Depending on the variant, it contains either two
 \ref page_zbx "ZBX Daughterboards" for a total of 4 channels at up to 400 MHz of
-analog bandwidth each, or two \ref page_fbx "FBX Daughterboards" for a total of
-8 channels at up to 1.6 GHz of analog bandwidth.
-The analog features of the \ref page_zbx and the \ref page_fbx are described in
-a separate manual page.
+analog bandwidth each, two \ref page_hbx "HBX Daughterboards" for a total of 2 channels
+at up to 1000 MHz of analog bandwidth each, or two \ref page_fbx "FBX Daughterboards"
+for a total of 8 channels at up to 1.6 GHz of analog bandwidth.
+The analog features of the \ref page_zbx, \ref page_hbx, and the \ref page_fbx are
+described in a separate manual page.
 
 The USRP X4x0 features a Xilinx RFSoC, running an embedded Linux system. Like
 other USRPs, it is addressable through a 1 GbE RJ45 connector, which allows full
 access to the embedded Linux system, as well as data streaming at low rates. In
 addition, it features two QSFP28 connectors, which allow for up to 4x10 GbE or
-1x100 GbE connections each. The RFSoC used on the USRP X410 is a ZU28DR speed grade 1,
-on the USRP X440 the ZU28DR speed grade 2.
+1x100 GbE connections each. The RFSoC used on the USRP X410 and USRP X420 is a
+ZU28DR speed grade 1, on the USRP X440 the ZU28DR speed grade 2.
 
-The front panel provides access to the RF connectors (SMA for X410, MMPX for
-X440), Tx/Rx status LEDs, programmable GPIOs, and the power button. The rear
-panel is where the power and data connections go (Ethernet, USB) as well as
-time/clock reference signals and GPS antenna.
+The front panel provides access to the RF connectors (SMA for X410 and X420, MMPX for
+X440), Tx/RX LO input and output connectors (SMA, X420 only), Tx/Rx status LEDs,
+programmable GPIOs, and the power button. The rear panel is where the power and
+data connections go (Ethernet, USB) as well as time/clock reference signals and
+GPS antenna.
 
 \subsection x4xx_overview_rfsoc The RFSoC CPU/FPGA and Host Operating System
 
@@ -97,6 +103,9 @@ respectively).
 The X4x0 has a higher maximum analog bandwidth than previous USRPs. The USRP X410
 can provide rates up to 500 Msps, resulting in a usable analog bandwidth of up to 400 MHz.
 
+The USRP X420 can, depending on the FPGA image used, provide up to 1250 Msps of
+sampling rate, resulting in a usable analog bandwidth of up to 1 GHz on two channels.
+
 The USRP X440 can, depending on the FPGA image used, provide up to 2048 Msps of
 sampling rate, resulting in a usable analog bandwidth of up to 1.6 GHz on two
 channels, or 8 channels at 500 Msps.
@@ -110,9 +119,14 @@ See the DPDK page for details on how it can improve streaming, and how to use it
 The Ettus USRP X410 contains two ZBX daughterboards. To find out more about the
 capabilities of these analog front-end cards, see \ref page_zbx.
 
+\subsection x4xx_overview_x420_dboards USRP X420 Daughterboard Connectivity
+
+The Ettus USRP X420 contains two HBX daughterboards. To find out more about the
+capabilities of these analog front-end cards, see \ref page_hbx.
+
 \subsection x4xx_overview_x440_dboards USRP X440 Daughterboard Connectivity
 
-The Ettus USRP X440 contains two FBX daughterboards. Unlike the ZBX daughterboards,
+The Ettus USRP X440 contains two FBX daughterboards. Unlike the ZBX and HBX daughterboards,
 they have no analog mixers or filters, but directly connect the converters to the
 RF connectors. To find out more about the
 capabilities of these analog front-end cards, see \ref page_fbx.
@@ -125,6 +139,12 @@ The X410 front panel provides access to the RF ports and status LEDs of the \ref
 It also provides access to the front-panel GPIO connectors (2x HDMI) and the
 power button.
 
+\image html x420_front_panel.png "Ettus USRP X420 Front Panel" width=90%
+
+The X420 front panel provides access to the RF ports, LO ports and status LEDs of
+the \ref page_hbx. It also provides access to the front-panel GPIO connectors (2x HDMI)
+and the power button.
+
 \image html x440_front_panel.png "Ettus USRP X440 Front Panel" width=90%
 
 The X440 front panel provides access to the RF ports and status LEDs of the \ref page_fbx.
@@ -180,9 +200,11 @@ for whatever reason.
 
 \subsection x4xx_overview_storage eMMC Storage
 
-The main non-volatile storage of the USRP is a 16 GB eMMC storage. This storage
+The main non-volatile storage of the USRP is a 32 GB eMMC storage*. This storage
 can be made accessible as a USB Mass Storage device through the USB-OTG connector
-on the back panel.
+on the back panel. 
+
+\* USRP X410 up until revision H had an NVM storage of 16 GB only.
 
 The entire root file system (Linux kernel, libraries) and any user data are
 stored on the eMMC. It is partitioned into four partitions:
@@ -224,7 +246,7 @@ The DRAM can be run at up to 2.4 GT/s but is clocked at 2.0 GT/s on X410 by
 default to ease FPGA timing closure.
 
 The FPGA memory controller exposes each bank of DRAM as a 512-bit interface,
-which is clocked at 300 MHz for X440 and 250 MHz on X410. This interface is
+which is clocked at 300 MHz for X440 and at 250 MHz for X410 and X420. This interface is
 then presented to RFNoC as multiple AXI interfaces (one interface for each RF
 channel). Each AXI interface is sized in order to match the expected throughput
 for a single channel. For example, on X410 200 MHz images, each AXI interface
@@ -358,6 +380,7 @@ a step-by-step guide is available at \ref page_build_guide.
 The following minimum UHD versions are required:
 
 - The USRP X410 requires UHD version 4.1 or above.
+- The USRP X420 requires UHD version 4.10 or above.
 - The USRP X440 requires UHD version 4.5 or above.
 
 It is generally recommended to use the latest UHD version.
@@ -369,14 +392,15 @@ It is generally recommended to use the latest UHD version.
 <br/>
 \image html x4x0_KitContents.svg "Ettus USRP X4x0 Kit contents" width=50%
 
-1. Ettus USRP X410/X440
+1. Ettus USRP X410/X420/X440
 2. Cat 5E Ethernet Cable
 3. USB-A (m) to USB-C (m) with Jack Screw Cable
 4. Power supply
-5. Ettus USRP X410/X440 Documentation Note
-6. Ettus USRP X410/X440 Safety, Environmental and Regulatory Information
+5. Ettus USRP X410/X420/X440 Documentation Note
+6. Ettus USRP X410/X420/X440 Safety, Environmental and Regulatory Information
 
-Refer the product page [X410](https://www.ettus.com/all-products/usrp-x410/)/
+Refer to the product page [X410](https://www.ettus.com/all-products/usrp-x410/) /
+[X420](https://www.ettus.com/all-products/usrp-x420/) /
 [X440](https://www.ettus.com/all-products/usrp-x440/) for recommended accessories.
 
 Inside the kit you will find the X4x0 and an X4x0 power supply. Plug these in,
@@ -393,7 +417,7 @@ Host system requirements:
 <b>For Network Mode:</b> A host computer with at least one 10 or one 100 Gigabit 
 Ethernet interface available for sample streaming. In addition to the Ethernet interface 
 used for sample streaming, your host computer will require a separate 1 Gigabit 
-Ethernet interface for command and control streaming. Th exact interface requirement 
+Ethernet interface for command and control streaming. The exact interface requirement 
 varies based on the FPGA image from \ref x4xx_updating_fpga_types loaded to the device.
 
 <b>For Stand-Alone Mode:</b> A host computer with an available 1 Gigabit Ethernet 
@@ -409,7 +433,7 @@ subnet network.
 
 <br/>
 \image html x4x0_NetworkMode.svg "Ettus USRP X4x0 Connections (UHD)" width=50%
-1. Ettus USRP X410/X440
+1. Ettus USRP X410/X420/X440
 2. Network Switch (optional)
 3. Host PC
 4. 100 G Ethernet Network Card
@@ -474,7 +498,7 @@ Verify the serial number printed on the devices matches the corresponding
 device serial number returned by the command. 
 
 All X4x0 variants will report their `type` as 'x4xx'. The `product` key can be
-used to identify the X410/X440 variant.
+used to identify the X410/X420/X440 variant.
 
 If a firewall is enabled on the host computer, allow UDP port 49600 to detect X4x0 devices. 
 On a Linux host, add a new bi-directional rule under iptables.
@@ -578,6 +602,14 @@ As of UHD 4.5, the following USRP X410 images flavors are shipped with UHD:
 | UC_200            | 4 (2 per ZBX)         | 200 MHz                  | Unused                  | 100 GbE                 | Yes     | Yes (4 GiB, 4-Ch Replay)   |
 | CG_400            | 4 (2 per ZBX)         | 400 MHz                  | 100 GbE                 | 100 GbE                 | No      | No                         |
 
+As of UHD 4.10, the following USRP X420 images flavors are shipped with UHD:
+
+| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM                      |
+|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|---------|---------------------------|
+| X4_200            | 2 (1 per HBX)         | 200 MHz                  | 4x 10 GbE (All Lanes)   | Unused                  | Yes     | Yes (8 GiB, 2-Ch Replay)  |
+| X4_1000           | 2 (1 per HBX)         | 1000 MHz                 | 4x 10 GbE (All Lanes)   | Unused                  | No      | Yes (8 GiB, 2-Ch Replay)  |
+| CG_1000           | 2 (1 per HBX)         | 1000 MHz                 | 100 GbE                 | 100 GbE                 | No      | Yes (8 GiB, 2-Ch Replay)  |
+
 As of UHD 4.6, the following USRP X440 images flavors are shipped with UHD:
 
 | FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM                      |
@@ -588,12 +620,12 @@ As of UHD 4.6, the following USRP X440 images flavors are shipped with UHD:
 | X4_1600           | 2 (1 per FBX)         | 1600 MHz                 | 4x 10 GbE (All Lanes)   | Unused                  | No      | Yes (8 GiB, 2-Ch Replay)  |
 | CG_1600           | 2 (1 per FBX)         | 1600 MHz                 | 100 GbE                 | 100 GbE                 | No      | No                        |
 
-* (Implemented as two separate 4-Ch Replay blocks)
+\* (Implemented as two separate 4-Ch Replay blocks)
 
 The following list shows some potential use-cases for different FPGA images:
 
-- `X4_200` or `UC_200`: On X410, 200 MHz analog bandwidth per channel, or below
-  (using RFNoC DDC/DUCs), streaming between the X410 and an external host
+- `X4_200` or `UC_200`: On X410 and X420, 200 MHz analog bandwidth per channel, or below
+  (using RFNoC DDC/DUCs), streaming between the X410/X420 and an external host
   computer, or streaming to/from on-board DRAM using the RFNoC Record/Replay
   block. For more on DRAM, refer \ref x4xx_pl_dram.
 - `X4_200`: On X440, 200 MHz analog bandwidth per channel, or below (using
@@ -612,6 +644,14 @@ The following list shows some potential use-cases for different FPGA images:
   block 1. Cross-connections Record/Replay0 <-> Radio1 and Record/Replay1 <->
   Radio0 are not supported by default.
   (For USRP X410 this design is available as source, and not shipped as precompiled bitfile)
+- `X4_1000`: (USRP X420 only): 1000 MHz analog bandwidth streaming per channel to/from 
+  on-board DRAM using the RFNoC Record/Replay block. Up to 4 x 10 GbE connections may be
+  used to access the DRAM from an external host computer. Note that 10 GbE is
+  not fast enough for continuous full-rate streaming at this rate.
+  Additionally, this image can also be used with master clock rates of 245.76 MHz,
+  250 MHz and 491.52 MHz.
+- `CG_1000`: (USRP X420 only): Like the X4_1000, but with 2x 100 GbE connections
+  for streaming to/from an external host computer. 
 - `CG_1600` (USRP X440 only): Highest bandwidth streaming between the X440 and 
   an external host computer. Streaming requires one 100 GbE connections per 
   channel. Due to the available FPGA bandwidth only 2 channels are enabled,
@@ -630,7 +670,7 @@ experimental (unsupported).</blockquote>
 The analog bandwidth determines the available master clock rates. See section
 \ref x4xx_usage_mcrs for more information on available master clock rates.
 
-Applications that require 200 MHz bandwidth or less (X410 only)
+Applications that require 200 MHz bandwidth or less, 
 should use the 200 MHz images and make use of the DDC/DUC for lower rates. 
 Applications that require higher bandwidth and use limited signal durations 
 should use the DRAM enabled X4_xxx images to ease streaming requirements.
@@ -674,6 +714,10 @@ X410:
 
     uhd_image_loader --args "type=x4xx,mgmt_addr=127.0.0.1,fpga=X4_200"
 
+X420:
+
+    uhd_image_loader --args "type=x4xx,mgmt_addr=127.0.0.1,fpga=X4_1000"
+
 X440:
 
     uhd_image_loader --args "type=x4xx,mgmt_addr=127.0.0.1,fpga=X4_400"
@@ -910,6 +954,16 @@ You can now use existing UHD examples or applications (such as
 rx_sample_to_file, rx_ascii_art_dft, or tx_waveforms) or other UHD-compatible
 applications to start receiving and transmitting with the device. 
 
+\subsection x4xx_getting_started_iq_dc IQ & DC Offset Correction (X420 only)
+
+The USRP X420 comes with separate I and Q signal paths and dedicated converters
+for each path. This architecture, however, is prone to IQ impairments. Additionally,
+due to the direct conversion architecture, there is LO leakage in the uncorrected
+spectrum. These impairments can be corrected with an FIR filter structure in the FPGA. The
+filter coefficients need to be determined with a measurement procedure that is
+implemented in a Python script. Refer to \ref calibration_iq_dc_utils for more
+details on the correction procedure.
+
 \subsection x4xx_getting_started_handling Proper Care and Handling
 All Ettus Research products are individually tested before shipment. The USRP is guaranteed to be functional 
 at the time it is received by the customer. Improper use or handling of the USRP can cause the device to 
@@ -925,6 +979,8 @@ become non-functional. Take the following precautions to prevent damage to the u
 <b> Caution! X410: Never feed a signal at power levels exceeding {+14 dBm continuous <=3GHz, +17 dBm continuous >3GHz, 
 or +20dBm for longer than 5 minutes >3GHz} into any RF input. </b>
 
+<b> Caution! X420: Never feed a signal at power levels exceeding {0 dBm} into any RF input.</b>
+
 <b> Caution! X440: Never feed a signal at power levels exceeding {+13 dBm continuous <=2.5GHz, +17 dBm continuous between 
 2.5GHz and 3.6 GHz, or +20dBm continuous between 3.6 GHz and 4 GHz} into any RF input. </b>
 
@@ -1236,7 +1292,7 @@ reboot.
 
 \section x4xx_troubleshooting Troubleshooting
 
-Refer [Ettus USRP X410/X440 Getting Started Guide](https://kb.ettus.com/USRP_X410/X440_Getting_Started_Guide) 
+Refer [Ettus USRP X410/X420/X440 Getting Started Guide](https://kb.ettus.com/USRP_X410/X440_Getting_Started_Guide) 
 for Support, Legal Considerations and T&C.
 
 \subsection x4xx_network_troubleshooting Network Troubleshooting
@@ -1261,8 +1317,13 @@ then you will need to download a UHD-compatible FPGA image as described in
 \ref x4xx_updating_fpga or using the following command (it assumes that FPGA
 images have been downloaded previously using uhd_images_downloader, or that the
 command is run on the device itself):
+
 X410:
    uhd_image_loader --args "type=x4xx,addr=<ip address>,fpga=X4_200"
+
+X420:
+   uhd_image_loader --args "type=x4xx,addr=<ip address>,fpga=X4_1000"
+
 X440:
    uhd_image_loader --args "type=x4xx,addr=<ip address>,fpga=X4_400"
 
@@ -1417,6 +1478,7 @@ The available master clock rates (MCR) depend on the FPGA image flavor that is
 currently installed on the device (see \ref x4xx_updating_fpga_types).
 
 \subsubsection x410_usage_mcrs USRP X410
+
 The USRP X410 has a few fixed MCR available for every image type:
 The 200 MHz images allow master clock rates of 245.76 MHz or 250 MHz. The 400
 MHz images allow master clock rates of 491.52 MHz or 500 MHz. Typically it is 
@@ -1424,6 +1486,19 @@ sufficient to open a UHD session without the master_clock_rate argument as UHD
 will pick a rate that fits the FPGA image loaded. If a non-valid MCR is chosen,
 the session will error out.
 
+\subsubsection x420_usage_mcrs USRP X420
+
+The USRP X420 has a default master clock rate of 1250 MHz for the xx_1000 images, 
+and 250 MHz for the X4_200 image. To accommodate a wider range of applications,
+the X420 also supports a few additional MCRs as listed in the table below.
+
+| Master Clock \n Rate (MCR) | Converter \n Rate (Fc) | RFDC Divider | Digital Bandwidth \n (0.8 * MCR) | Available in\n Default Bitfile |
+|:--:|:--:|:--:|:--:|:--:|
+245.76 MHz | 1966.08 MHz | 8 | 196.608 MHz | X4_200, xx_1000 |
+250 MHz | 2000 MHz | 8 | 200 MHz | X4_200, xx_1000 |
+491.52 MHz| 3932.16 MHz | 8 | 393.216 MHz | xx_1000 |
+1250 MHz (default)| 2500 MHz | 2 | 1000 MHz | xx_1000 |
+
 \subsubsection x440_usage_mcrs USRP X440
 
 \paragraph x440_usage_mcr_general General
@@ -1432,7 +1507,7 @@ The USRP X440 has a much broader range of available master clock rates, and
 supports a fixed set of rates between 125 Msps and 2 Gsps. The maximum available 
 MCR is further dependent on the FPGA image type. The master clock rate depends 
 on the converter rate (Fc) and selected RFDC divider, and in the absence of 
-further digital down or up conversation, equals to the IQ sample rate. 
+further digital down or up conversion, equals to the IQ sample rate. 
 \n Simplified signal path block diagram for X440
 ```
 
@@ -1441,7 +1516,7 @@ further digital down or up conversation, equals to the IQ sample rate.
   ┌─────────────┐      ┌───────────────────────────────────────────┐  │  ┌─────────────┐  │
   │             │      │    Xilinx RFDC (RF Digital Converter)     │  │  │             │  │  ┌──────────────────┐
   │             │      │┌─────────┐   ┌─────────┐  ┌──────────────┐│  V  │    RFNoC    │  V  │   Transport      │
-  │ FPX (Balun) │──────││   ADC   │___|   IQ    │__│ Decimation   ││─────│    Radio    │─────│      with        │
+  │ FBX (Balun) │──────││   ADC   │___|   IQ    │__│ Decimation   ││─────│    Radio    │─────│      with        │
   │             │      ││   DAC   │   │  Mixer  │  │ Interpolation││     │    Block    │     │ Data Rate [Bit/s]│
   │             │      │└─────────┘   └─────────┘  └──────────────┘│     │             │     └──────────────────┘
   └─────────────┘      └─────^────────────^────────────────────────┘     └─────────────┘
@@ -1577,9 +1652,10 @@ prevent any unexpected side-effects.
 The USRP X4x0 series can execute \ref page_timedcmds the same way as other USRPs,
 with the following restrictions:
 
-- Timed tuning is not supported (to be accurate, timed tuning of the RFSoC NCO
-  is not supported)
-- The USRP X440 only (this does not apply to the USRP X410!) has two timekeepers
+- Timed tuning is not supported on X410/X440 (to be accurate, timed tuning of
+  the RFSoC NCO is not supported)
+- Timed tuning is supported in X420 for frequencies > 500 MHz.
+- The USRPs X420 and X440 (this does not apply to the USRP X410!) have two timekeepers
   instead of the usual single timekeeper.
   - Timekeeper 0 manages the time for daughterboard 0, timekeeper 1 manages the
     time for daughterboard 1.
@@ -1673,6 +1749,14 @@ DB 0 / RF 1 | A:1
 DB 1 / RF 0 | B:0
 DB 1 / RF 1 | B:1
 
+For X420, the RF ports on the front panel of the X420 correspond to the following
+subdev specifications:
+
+Label       | Subdev Spec
+------------|------------
+DB 0 / RF 0 | A:0
+DB 1 / RF 0 | B:0 
+
 The RF ports on the front panel of the X440 + FBX (xx_400 images) correspond 
 to the following subdev specifications:
 
@@ -1920,21 +2004,26 @@ converter rates are identical and use the same RFDC decimation/interpolation
 settings.
 
 \subsubsection x410_too_convrate USRP X410
-The USRP X410 only supports a few fixed master clock rates (see \ref x4xx_usage_mcrs), 
+The USRP X410 only supports a few fixed master clock rates (see \ref x410_usage_mcrs), 
 with predefined converter rates around 3 GHz, and uses in addition to the RFDC 
 decimation/interpolation block also a 3/2 decimation (2/3 interpolation) block 
 implemented in FPGA fabric.
 
+\subsubsection x420_too_convrate USRP X420
+
+The USRP X420 was designed and tested with a limited number of master clock rates
+and converter rates as described in \ref x420_usage_mcrs.
+
 \subsubsection x440_too_convrate USRP X440
 The USRP X440 supports a large, finite number of master clock rates (see
-\ref x4xx_usage_mcrs), and utilizes converter rates between 1GHz and the maximum 
+\ref x440_usage_mcrs), and utilizes converter rates between 1GHz and the maximum 
 supported converter rate of 4.096 GHz. The resulting master clock rates are
 derived by decimating by 8, 4 or 2 and vice versa. The smallest possible master
 clock rate is thus 125 Msps (1 GHz resampled by eight), and the maximum possible
 master clock rate is 2.048 Gsps (4.096 GHz resampled by two).
 \n By default, UHD will choose the largest converter rate available. This can 
 be overridden by specifying the `converter_rate` device argument (see also 
-\ref x4xx_usage_args).
+\ref x4xx_usage_args). 
 
 After opening a UHD session the current converter rate can be read from the 
 rfdc_rate sensor. Example:

host/docs/driver_usage/calibration.dox

@@ -37,6 +37,11 @@ utilities:
 -   OBX Series transceiver boards
 -   USRP N320
 
+The **USRP X420** with its large bandwidth of 1 GHz is not supported by
+the aforementioned calibration utilities. For this device, the
+`uhd_iq_dc_correction.py` utility needs to be used for both IQ imbalance
+and DC offset correction.
+
 \subsection calibration_self_utils Calibration Utilities
 
 UHD software installs the calibration utilities into
@@ -58,6 +63,28 @@ daughterboard's EEPROM:
 
     <install dir>/lib/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args>
 
+\subsection calibration_iq_dc_utils IQ Imbalance and DC Offset Correction Utilities
+
+Currently, for X420 only, UHD installs the **uhd_iq_dc_correction.py**
+utility into `<Python path>/site-packages/uhd/utils/`. In addition to
+the requirements of UHD, this script requires the Python packages
+`scipy` and `tqdm`. As with the other calibration utilities, it is
+recommended to disconnect any external signals from the RF antenna
+ports before running the utility and to let the device warm up for
+a few minutes. By default, the utility will perform an RX IQ imbalance and DC Offset
+correction only. By adding the `--tx` argument, TX IQ imbalance and DC offset corrections can be enabled
+as well. The utility will take several minutes to complete. See the output
+given by `--help` for more advanced options, such as manually choosing
+the frequency range and step size for the sweeps or switching to a
+different than the default master clock rate.
+
+    python3 uhd_iq_dc_correction.py --args=<optional device args> -c <chan> [--tx --sample_rate=<rate>]
+
+It is recommended to perform the corrections using a 10 or 100 GbE connection between USRP and host computer to minimize
+the measurement time. If that is not possible, the corrections can still be executed using
+the 1 GbE connection, too, but the additional --rj45 parameter must be
+added to disable optimizations that are specific to higher-speed connections.
+
 \subsection calibration_data Calibration Data
 
 By default, calibration files are stored in the user's home/application
@@ -88,7 +115,7 @@ https://google.github.io/flatbuffers/.
 Once installed, `.cal` files can be converted to JSON using
 
 	flatc --strict-json -t <install dir>/share/uhd/cal/<foo>_cal.fbs -- <data>.cal
-	
+
 where `<foo>_cal.fbs` is the scheme file used for the data,
 e.g. `pwr_cal.fbs` for power calibration. `data.cal` is a calibration file in
 your working directory. This will generate a `<data>.json` in the same
@@ -97,10 +124,10 @@ directory.
 The JSON data can be converted back to binary using
 
 	flatc -b <install dir>/include/uhd/cal/<foo>_cal.fbs <data>.json
-	
+
 This generates a `<data>.cal` that can be read by the calibration routines
 of UHD.
-	
+
 \subsection calibration_data_csv Converting UHD 3.x calibration data to UHD 4
 
 Older versions of UHD used a CSV-based format for storing calbration data for
@@ -157,7 +184,8 @@ reason, the DC offset compensation consists of a simple adder. The calibration
 tool `uhd_cal_tx_dc_offset` will estimate the value D' which minimizes the DC
 offset for various frequencies (i.e., D' is approximately equal to -D).
 
-To program the adder, set the DC offset correction value using these API calls:
+To program the adder, set the DC offset correction value using these API calls
+(all USRPs, except USRP X420):
 
 - uhd::usrp::multi_usrp::set_tx_dc_offset()
 - uhd::usrp::multi_usrp::set_rx_dc_offset()
@@ -176,7 +204,7 @@ following difference equation:
 The values for \f$\alpha\f$ are device-dependent, but the default value is \f$2^{-20}\f$.
 
 To enable the automatic DC offset correction, call one of these API calls with
-an argument of 'true':
+an argument of 'true' (all USRPs, except USRP X420):
 
 - uhd::usrp::multi_usrp::set_rx_dc_offset()
 - uhd::rfnoc::radio_control::set_rx_dc_offset()
@@ -189,7 +217,13 @@ interest if the LO is within the band of interest.
 Superheterodyne receivers such as the TwinRX do usually not require DC offset
 correction values.
 
-\subsection calibration_fe_corr_iq_offset Single-Point IQ offset compensation
+Because IQ impairments and DC offset measurements are similar in the way how
+they are measured, **in X420**, the same utility is used for both. The API
+calls described above do not apply to X420. Instead, after running the
+`uhd_iq_dc_correction.py` utility, the correction values are automatically applied
+at runtime. Passing them manually is not possible.
+
+\subsection calibration_fe_corr_iq_offset Single-Point IQ offset correction
 
 In order to correct IQ imbalance, the user can specify two real values A and B.
 In the FPGA, the complex signal is modified according to the following equation:
@@ -237,5 +271,45 @@ receiver being slightly different in amplitude as well as their phase not being
 exactly 90 degrees apart (due to analog components). It is therefore not
 required for superheterodyne architectures like the TwinRX.
 
+\subsection calibration_fe_dc_iq DC Offset and IQ Imbalance Correction (X420)
+
+The calibration files generated from the uhd_iq_dc_correction utility are
+compensating the DC offset as described in \ref calibration_fe_corr_dc_offset.
+
+The IQ imbalance correction is based on the single-point method described before with an additional compensation of the
+time delay of the Q channel.
+
+The time delay is compensated using a fractional-delay FIR filter.
+The coefficients \f$h\f$ are calculated from the following equation, where \f$d\f$ is the
+desired group delay of the filter (centered by the number of coefficients) and
+\f$F_s\f$ is the sample rate.
+
+\f[
+h(i) = sinc((i-d) - t_{offset} * F_s)
+\f]
+
+The single point IQ correction is using the formula below, where the linear
+gain is \f$g\f$ and the phase skew is \f$\phi\f$.
+
+\f[
+\begin{pmatrix}
+I' \\
+Q'
+\end{pmatrix}
+=
+\begin{pmatrix}
+1 & 0 \\
+-tan(\phi) & \frac{1}{g \cdot cos(\phi)}\\
+\end{pmatrix}
+\begin{pmatrix}
+I \\
+Q
+\end{pmatrix}
+\f]
+
+For the Q inline path
+(\f$Q \rightarrow Q'\f$) the respective factor from the correction matrix and the coefficients \f$h\f$  from the
+FIR filter above are combined into a single FIR filter.
+
 */
 // vim:ft=doxygen: