| USRP Hardware Driver and Device Manual Version: 4.10.0.0 UHD and USRP Manual |

Loading...
Searching...
No Matches
R&D Testing Procedures

All defined R&D test procedures are listed here. These tests are meant as a tool for Ettus R&D to enable faster and more reliable development. Note these tests are no replacement for manufacturing or production tests, and should not be treated as such. Instead, they are meant to catch common failure modes during development. As a result, test definitions are fairly light-weight.

# GPSDO Tests

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
GPS-X310-TCXO-v1 | USRP X310 | Jackson Labs TCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure
GPS-X310-OCXO-v1 | USRP X310 | Jackson Labs OCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure
GPS-X300-TCXO-v1 | USRP X300 | Jackson Labs TCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure
GPS-X300-OCXO-v1 | USRP X300 | Jackson Labs OCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure
GPS-B200-TCXO-v1 | USRP B200 | Jackson Labs TCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure
GPS-B210-TCXO-v1 | USRP B210 | Jackson Labs TCXO | GPSDO: Manual Test Procedure | GPSDO: Automatic Test Procedure

## Recommendations

For cursory testing, not all tests within a device family are required (e.g., only testing the OCXO on any X-Series, and testing the TCXO on any B-Series is sufficient).

The following tests are recommended for a minimum test (N stands for the latest version of this test):

- One of GPS-X310-OCXO-vN or GPS-X300-OCXO-vN
- One of GPS-B210-TCXO-vN or GPS-B200-TCXO-vN

## Requirements

All of these tests require a device that is GPSDO capable (e.g., X3x0, B2x0, N2x0). For those devices that have a separate GPS component (such as the Jackson Labs GPSDOs), this component is also required (called the "peripheral" in the following).

## GPSDO: Manual Test Procedure

1. Without connecting the peripheral to the device, run uhd_usrp_probe on the device and verify that the lack of GPSDO is correctly reported under "sensors". No warning or error must be printed.
2. This and the following tests are run with the peripheral connected: Run uhd_usrp_probe and verify that the GPSDO is correctly reported under "sensors". Power down the device before connecting the peripheral. The GPSDO must be reported found, and no error or warning must be printed.
3. OCXO only: Without connecting the GPS antenna input, run utils/query_gpsdo_sensors. To pass, it must report the GPSDO as found, lock to the external reference, but then report not being locked to GPS. The tool will report a valid GPS time, and a string such as "GPS and UHD Device time are aligned" in case of success.
4. Connect a GPS antenna to the input and make sure it is in a position to receive GPS satellite data. Confirm that GPS lock is reported by running utils/query_gpsdo_sensors within 20 minutes of connecting the antenna. The tool query_gpsdo_sensors will print a string such as "GPS Locked" in case of success.

All of these tests must pass for a 'pass' validation.

## GPSDO: Automatic Test Procedure

tbd

# Devtests

The devtests are device tests designed to verify the basic functionality of UHD devices. These unit tests can be used to ensure hardware components like clock, sensors, GPIO, etc are functioning correctly. They also validate basic UHD API functions and device communication. They are not meant to be exhaustive tests, but rather a quick way to verify that the device is operational. These tests are created in python and are located in the <local repo path>/host/tests/devtest/ directory. Refer devtest README for more information. The table below shows the list of devices and FPGA images that are being tested using the devtests.

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
DEVTEST-X310-XG-v1 | USRP X310 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X310-HG-v1 | USRP X310 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X300-XG-v1 | USRP X300 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X300-HG-v1 | USRP X300 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-E310-SG1-v1 | USRP E310-SG1 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-E310-SG3-v1 | USRP E310-SG3 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-E320-1G-v1 | USRP E320 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-B200-v1 | USRP B200 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-B210-v1 | USRP B210 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-B200m-v1 | USRP B200mini | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-B205m-v1 | USRP B205mini | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-B206m-v1 | USRP B206mini | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-N310-XG-v1 | USRP N310 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-N310-HG-v1 | USRP N310 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-N320-HG-v1 | USRP N320 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-N320-XG-v1 | USRP N320 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-N320-XQ-v1 | USRP N320 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X410-X4_200-v1 | USRP X410 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X410-UC_200-v1 | USRP X410 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X410-CG_400-v1 | USRP X410 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X420-X4_200-v1 | USRP X420 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X420-X4_1000-v1 | USRP X420 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X420-CG_1000-v1 | USRP X420 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X440-X4_200-v1 | USRP X440 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X440-X4_400-v1 | USRP X440 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X440-CG_400-v1 | USRP X440 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X440-X4_1600-v1 | USRP X440 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure
DEVTEST-X440-CG_1600-v1 | USRP X440 | None | Devtest: Manual Test Procedure | Devtest: Automatic Test Procedure

The devtests are hardware tests built in to the UHD make system. They can be run directly from the build directory and require no configuration. Devtests are designed to always run, regardless of the actual device configuration. This means, by definition, that devtests cannot require special cabling, specific daughtercards, etc.

Note: The actual devtests can change, since they're part of the code. This does not require a version bump on the test code.

## Requirements

Devtests are only defined for some devices. When running a devtest, all peripherals must be disconnected (e.g., no daughterboards on the X-Series, no GPSDOs on the B- and X-Series).

Running these tests requires the yaml package. On Ubuntu, run sudo apt-get install python3-yaml to install the Python 3 version of the YAML library. Follow steps in Building and Installing UHD from source to setup build environment.

Note: The devtests can be executed both on the host computer or on the embedded devices (x4xx, n3xx, e3xx) itself. In both cases, a build environment (build folder structure created when building uhd from source) is required. The below section Devtest: Manual Test Procedure shows the steps to execute the devtests on the device using host computer.

## Devtest: Manual Test Procedure

### Running devtest using UHD make

To run the devtests using UHD make, follow these steps:

1. Make sure no optional peripherals are connected to the device and remove all front panel connections, including from GPIO.
2. Connect the device to the host computer via the appropriate interface depending upon the FPGA image. Refer below table for some examples of test cases.
3. Run make test_<devtest-pattern> from the command line in the build directory (i.e. <local repo path>/host/build). Refer below table for the list of available <devtest-pattern>. By default, the devtest is executed on all the connected devices matching the <devtest-pattern>. To target a specific device use the argument EXTRA_DEV_ARGS and specify the device address or name. For example, to run devtest on a specific x410:
   <build_directory> make test_x410 EXTRA_DEV_ARGS="addr=10.2.161.10"
4. Devtest must report no failures for a 'pass' validation.

Device (type) | make test_<devtest-pattern> | FPGA Image | Interface | Testing
--- | --- | --- | --- | ---
X410 (x4xx) | make test_x410 | X4_200 | 4x10GbE | Test once on SFP0
X420 (x4xx) | make test_x420 | X4_200 | 4x10GbE | Test once on SFP0
X440 (x4xx) | make test_x440 | X4_400 | 4x10GbE | Test once on SFP0
X3x0 (x300) | make test_x3x0 | HG, XG | 1GbE, 10GbE | For HG, test once for each connection: 1GbE (SFP0) and 10GbE (SFP1). For XG, test once for either SFP0 or SFP1 is sufficient. In both cases, also test via PCIe.
N3xx (n3xx) | make test_n3x0 | HG, XG | 1GbE, 10GbE | For HG, test once for each connection: 1GbE (SFP0) and 10GbE (SFP1). For XG, test once for either SFP0 or SFP1 is sufficient.
B2xx (b200) | make test_b2xx | Default | USB | Test once via USB2 and USB3
E320 (e3xx) | make test_e320 | 1G, XG | 1GbE, 10GbE | Test once for each connection: 1GbE and 10GbE
E310 (e3xx) | make test_e3xx | sg3 | 1GbE | Test once using ethernet

### Running devtest using python test suite

As an alternative to running the devtests using UHD make system from the build directory, one can also directly execute the tests using run_testsuite.py. For example, in case of testing on an E320, run the following command (the environment variables need to point to the location of the devtest code, the location of the UHD build, and where you want to store log files, respectively) on the host computer (or on the embedded device with build environment set up):

$DEVTEST_DIR/run_testsuite.py --src-dir $DEVTEST_DIR \
--devtest-pattern e3xx \
--build-type na \
--build-dir $BUILD_DIR \
--args type=e3xx \
--log-dir $LOG_DIR

## Devtest: Automatic Test Procedure

As all these tests can be run unsupervised, they can be run automatically given the correct device setup. The return code of the tests can be used to check for pass/fail conditions (return code 0 means 'pass').

# FPGA: Testing through Simulations

Test benches provide a faster way to verify the design through simulations.

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
FPGATB-v1 | None | None | Manual Test Procedure | Automatic Test Procedure

## Requirements

These tests are simulations and do not need any device. Vivado 15.4 should be installed.

## Manual Test Procedure

1. Go to the fpga directory depending on which test needs to be run.
   1. NoC block test benches: Most of the NoC blocks have a test bench written in System Verilog that provides stimuli to the noc_block to verify it. The test bench for a block resides in <fpga-dir>/usrp3/lib/rfnoc/&zwj;*_tb.
   2. Running unit test benches: A few sub-blocks like noc-shell and sine_tone are used within the bigger noc_blocks. They have their own test benches. Their test benches reside in <fpga-dir>/usrp3/lib/sim/rfnoc/&zwj;*.
   3. Radio test bench: The radio test bench resides in <fpga-dir>/usrp3/lib/radio/noc_block_radio_core_tb/.
   4. Device specific test benches: IPs specific to a device have test benches that exist in <fpga-dir>/usrp3/top/x300/sim/\*. e.g. DMA testbench, PCIe, etc.
2. Setup the environment by running source <fpga-dir>/usrp3/top/<device>/setupenv.sh.
3. In the test bench directory and run the test bench by 'make xsim' or 'make vsim'.
4. All of these tests must report no failure with a 'PASS' validation. Example testbench output:

========================================================
TESTBENCH STARTED: noc_block_skeleton
========================================================
[TEST CASE 1] (t=000000000) BEGIN: Wait for Reset...
[TEST CASE 1] (t=000001002) DONE... Passed
[TEST CASE 2] (t=000001002) BEGIN: Check NoC ID...
Read Skeleton NOC ID: 1234000000000000
[TEST CASE 2] (t=000001238) DONE... Passed
[TEST CASE 3] (t=000001238) BEGIN: Connect RFNoC blocks...
Connecting noc_block_tb (SID: 1:0) to noc_block_skeleton (SID: 0:0)
Connecting noc_block_skeleton (SID: 0:0) to noc_block_tb (SID: 1:0)
[TEST CASE 3] (t=000005457) DONE... Passed
[TEST CASE 4] (t=000005457) BEGIN: Write / readback user registers...
[TEST CASE 4] (t=000006888) DONE... Passed
[TEST CASE 5] (t=000006888) BEGIN: Test sequence...
[TEST CASE 5] (t=000007403) DONE... Passed
========================================================
TESTBENCH FINISHED: noc_block_skeleton
- Time elapsed: 7500 ns
- Tests Expected: 5
- Tests Run: 5
- Tests Passed: 5
Result: PASSED
========================================================

Failing tests can be debugged by checking the waveform in a Vivado GUI by running 'make GUI=1 xsim'. More details on debugging: https://kb.ettus.com/Debugging_FPGA_images

## Automatic Test Procedure

Go to <fpga-dir>/usrp3/ and run 'build.py xsim all'. All tests should report 'PASS'.

# FPGA DSP Verification

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
FPGADSPVERIF-X310-HG-v1 | USRP X310 | 2x UBX | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-X310-XG-v1 | USRP X310 | 2x UBX | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-X300-HG-v1 | USRP X300 | 2x UBX | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-X300-XG-v1 | USRP X300 | 2x UBX | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-E310-SG1-v1 | USRP E310 SG1 | None | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-E310-SG3-v1 | USRP E310 SG3 | None | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure
FPGADSPVERIF-E320-v1 | USRP E320 | None | FPGA DSP Verification: Manual Test Procedure | FPGA DSP Verification: Automatic Test Procedure

## Requirements

- Signal generator and spectrum analyzer
- X300 & X310 with 2x UBX daughterboard
- E310 SG1 & SG3 with SSH access
- E320 with SSH access

## FPGA DSP Verification: Manual Test Procedure

This procedure tests the DDC and DUC signal quality and the block's capability to change sample rate while streaming.

### RX testing

1. Run calibration on device, if applicable
2. Using a signal generator, inject a sine tone into RX channel 0 at 915.5 MHz @ -40 dBm
3. Inspect the received spectrum using uhd_fft
   - X3x0: uhd_fft -f 915e6 -s 10e6 -g 10
   - E31x: uhd_fft -f 915e6 -s 2e6 -g 50
   - E320: uhd_fft -f 915e6 -s 15.36e6 -g 50
   - Embedded devices will require either using network mode or using X forwarding over ssh to run the app natively
4. In the GUI, inspect the spectrum. There should be a strong tone at the test tone frequency. There may be a small tone at the carrier frequency due to DC offset and a quadrature image due to IQ imbalance.
5. Check the input tone frequencies outlined below. The tone should shift from left to right as the frequency changes and may have some amplitude variation, especially at the band edges.
   - X3x0: 910 MHz to 920 MHz in 1 MHz steps
   - E3xx: 914 MHz to 916 MHz in 200 kHz steps
6. Set input tone back to 915.5 MHz. Check the sampling rate as outlined below. The spectrum should reflect the change in sample rate.
   - X3x0: 1, 5, 20, 33.333, 50, 66.666, 100, 200 MHz
   - E3x0: 0.1, 0.5, 1, 1.143, 1.684 MHz
7. Repeat on each RX channel of the device.
8. This test fails if:
   - DC offset and IQ imbalance tones are unusually large
   - There are any other strong tones or spectrum distortion
   - The spectrum changes significantly between frequencies or sample rates
     - An initial transient distortion is acceptable
     - Amplitude variation on the order of +/-10 dB is acceptable
   - Console reports any of the following:
     - Overruns 'O' if continuous and not due to host computer's lack of processing performance
     - Dropped packets 'D'
     - Sequence number errors 'S'
     - Timeouts

### TX testing

1. Run calibration on device, if applicable
2. Using uhd_siggen_gui, generate a sine tone TX channel 0 at 915.5 MHz:
   - X3x0: uhd_siggen_gui -f 915e6 -s 10e6 -g 10 -x 500e3 --sine
   - E31x: uhd_siggen_gui -f 915e6 -s 2e6 -g 50 -x 500e3 --sine
   - E320: uhd_siggen_gui -f 915e6 -s 15.36e6 -g 50 -x 500e3 --sine
3. Using a spectrum analyzer, inspect the output spectrum. There should be a strong tone at the test tone frequency. There may be a small tone at the carrier frequency due to DC offset and a quadrature image due to IQ imbalance.
4. Using the GUI, test the follow offset frequencies. The tone should shift from left to right as the frequency changes and may have some amplitude variation, especially at the band edges.
   - X3x0: -5 to +5 MHz in 1 MHz steps
   - E3xx: -1 to +1 MHz in 200 kHz steps
5. Set output tone offset back to 500e3. Change sampling rate as outlined below. The spectrum should not significantly differ between sample rates.
   - X3x0: 1, 5, 20, 33.333, 50, 66.666, 100, 200 MHz
   - E3xx: 0.1, 0.5, 1, 1.143, 1.684 MHz
6. Repeat on each TX channel of the device
7. This test fails if:
   - DC offset and IQ imbalance tones are unusually large
   - There are any other strong tones or spectrum distortion
   - The spectrum changes significantly between sample rates
     - An initial transient distortion is acceptable
   - Console reports any of the following:
     - Underruns 'U' if continuous and not due to host computer's lack of processing performance
     - Late packets 'L'
     - Sequence number errors 'S'

## FPGA DSP Verification: Automatic Test Procedure

tbd

# FPGA Functional Verification

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
FPGAFUNCVERIF-X310-HG-v1 | USRP X310 | 2x UBX | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-X310-XG-v1 | USRP X300 | 2x UBX | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-X300-HG-v1 | USRP X310 | 2x UBX | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-X300-XG-v1 | USRP X300 | 2x UBX | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-E310-SG1-v1 | USRP E310 SG1 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-E310-SG3-v1 | USRP E310 SG3 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N320-HG-v1 | USRP N320 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N320-XG-v1 | USRP N320 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N310-HG-v1 | USRP N310 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N310-XG-v1 | USRP N310 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N300-HG-v1 | USRP N300 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-N300-XG-v1 | USRP N300 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-E320-1G-v1 | USRP E320 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-E320-XG-v1 | USRP E320 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure
FPGAFUNCVERIF-E320-device-v1 | USRP E320 | None | FPGA Functional Verification: Manual Test Procedure | FPGA Functional Verification: Automatic Test Procedure

The FPGA functional verification tests exercise the Digital Downconverter (DDC), Digital Upconverter (DUC), and Radio Core RFNoC blocks.

## Requirements

- X300 & X310 with two daughterboards
  - 2x UBX recommended
  - HG tests require a single 10 GigE connection, XG requires two for the 2x RX 200 MSPS test
  - 1 GigE and PCIe adapters and cabling for optional tests
- E310: SG1 & SG3 with SSH access
- N310: No special requirements
- E320: SFP connection to run network mode

## FPGA Functional Verification: Manual Test Procedure

This procedure verifies that the DDC, DUC, and Radio Core can run at various sample rates and channel configurations without any data flow issues.

1. Run benchmark_rate using the parameters outlined in the tables below
2. Unless otherwise noted, to pass each test:
   - Benchmark rate must run without reporting any of the following:
     - Underruns 'U'
     - Overruns 'O'
     - Dropped packets 'D'
     - Sequence number errors 'S'
     - Late commands 'L'
     - Timeouts
   - Appropriate TX/RX LEDs must be illuminated
3. Unless specified in 'Notes' column, use default values for unlisted parameters
4. Example commands:
   - X3x0: benchmark_rate --tx_rate 1e6 --rx_rate 1e6 --channels 0,1 --duration 120
   - E3xx: benchmark_rate --args="master_clock_rate=10e6" --tx_rate 1e6 --rx_rate 1e6 --channels 0,1 --duration 120

### USRP X3x0: 10 GigE Interface

- Required images to test: X310 HG
- Optional images to test: X310 XG, X300 HG, X300 XG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

Channels | Sample Rates | Duration | Notes
--- | --- | --- | ---
1x RX | 10e6, 50e6, 100e6, 200e6 | 60 | Test both channels
2x RX | 10e6, 50e6, 100e6 | 60 |
2x RX | 200e6 | 60 | 2x 10G, XG only
1x TX | 10e6, 50e6, 100e6, 200e6 | 60 | Test both channels
2x TX | 10e6, 50e6, 100e6 | 60 |
1x RX & 1x TX | 10e6, 50e6, 100e6 | 60 | Test both channels
1x RX & 1x TX | 200e6 | 60 | Use channel 0
2x RX & 2x TX | 10e6, 50e6 | 60 |
1x RX & 1x TX | 200e6 | 600 | Use channel 1
2x RX & 2x TX | 100e6 | 600 |

### USRP X3x0: 1 GigE Interface

- Required images to test: None
- Optional images to test: X310 HG, X310 XG, X300 HG, X300 XG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

Channels | Sample Rates | Duration
--- | --- | ---
1x RX | 1e6, 10e6, 25e6 | 60
2x RX | 1e6, 10e6 | 60
1x TX | 1e6, 10e6, 25e6 | 60
2x TX | 1e6, 10e6 | 60
1x RX & 1x TX | 1e6, 10e6, 25e6 | 60
2x RX & 2x TX | 1e6, 10e6 | 60

### USRP X3x0: PCIe Interface

- Required images to test: None
- Optional images to test: X310 HG, X310 XG, X300 HG, X300 XG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

Channels | Sample Rates | Duration
--- | --- | ---
1x RX | 10e6, 50e6, 100e6, 200e6 | 60
2x RX | 10e6, 50e6, 100e6 | 60
1x TX | 10e6, 50e6, 100e6, 200e6 | 60
2x TX | 10e6, 50e6, 100e6 | 60
1x RX & 1x TX | 10e6, 50e6, 100e6 | 60
1x RX & 1x TX | 200e6 | 60
2x RX & 2x TX | 10e6, 50e6 | 60

Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

### USRP E3xx Device (Embedded Mode)

- E320 and E310 SG3 are required tests, E310 SG1 is optional

Channels | Master Clock Rate | Sample Rate | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 10e6 | 1e6 | 60 | Test both channels
1x RX | 61.44e6 | 3.84e6 | 60 | Test both channels
1x TX | 10e6 | 1e6 | 60 | Test both channels
1x TX | 61.44e6 | 3.84e6 | 60 | Test both channels
2x RX | 10e6 | 1e6 | 60 |
2x RX | 30.72e6 | 1.92e6 | 60 |
2x TX | 10e6 | 1e6 | 60 |
2x TX | 30.72e6 | 1.92e6 | 60 |
1x RX & 1x TX | 10e6 | 1e6 | 60 | Test both channels
1x RX & 1x TX | 30.72e6 | 3.84e6 | 60 | Use channel 1
2x RX & 2x TX | 10e6 | 1e6 | 60 |
2x RX & 2x TX | 30.72e6 | 1.92e6 | 60 |
1x RX & 1x TX | 30.72e6 | 3.84e6 | 600 | Use channel 0
2x RX & 2x TX | 30.72e6 | 1.92e6 | 600 |

### USRP E320: 1 GigE Interface

Channels | Master Clock Rate | Sample Rate | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 15.36e6 | 15.36e6 | 60 | Test both channels
1x RX | 61.44e6 | 3.84e6 | 60 | Test both channels
1x TX | 15.36e6 | 15.36e6 | 60 | Test both channels
1x TX | 61.44e6 | 3.84e6 | 60 | Test both channels
2x RX | 61.44e6 | 7.68e6 | 60 |
2x RX | 30.72e6 | 1.92e6 | 60 |
2x TX | 61.44e6 | 7.68e6 | 60 |
2x TX | 30.72e6 | 1.92e6 | 60 |
1x RX & 1x TX | 30.72e6 | 7.68e6 | 60 | Test both channels
1x RX & 1x TX | 61.44e6 | 1.92e6 | 60 | Use channel 1
2x RX & 2x TX | 30.72e6 | 3.84e6 | 60 |
2x RX & 2x TX | 30.72e6 | 1.92e6 | 60 |
1x RX & 1x TX | 30.72e6 | 3.84e6 | 600 | Use channel 0
2x RX & 2x TX | 30.72e6 | 1.92e6 | 600 |

### USRP E320: 10 GigE Interface

Channels | Master Clock Rate | Sample Rate | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 61.44e6 | 1.92e6, 61.44e6 | 60 | Test both channels
1x TX | 61.44e6 | 1.92e6, 61.44e6 | 60 | Test both channels
2x RX | 30.72e6 | 1.92e6, 30.72e6 | 60 |
2x TX | 30.72e6 | 1.92e6, 30.72e6 | 60 |
1x RX & 1x TX | 61.44e6 | 1.92e6, 30.72e6 | 60 | Test both channels
2x RX & 2x TX | 30.72e6 | 1.92e6, 30.72e6 | 60 |
1x RX & 1x TX | 61.44e6 | 1.92e6, 30.72e6 | 600 | Use channel 0
2x RX & 2x TX | 30.72e6 | 1.92e6, 30.72e6 | 600 |

### USRP N300/N310: 1 GigE Interface

- Required images to test: HG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

Channels | Master Clock Rate | Sample Rates | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 125e6 | 1.25e6 | 60 | One test each for all 4 channels
1x RX | 122.88e6 | 1.2288e6 | 60 | One test each for all 4 channels
1x RX | 153.6e6 | 1.536e6 | 60 | One test each for all 4 channels
1x TX | 125e6 | 1.25e6 | 60 | One test each for all 4 channels
1x TX | 122.88e6 | 1.2288e6 | 60 | One test each for all 4 channels
1x TX | 153.6e6 | 1.536e6 | 60 | One test each for all 4 channels
2/3/4x RX | 125e6 | 1.25e6 | 60 | 3 tests total
2/3/4x RX | 122.88e6 | 1.2288e6 | 60 | 3 tests total
2/3/4x RX | 153.6e6 | 1.536e6 | 60 | 3 tests total
2/3/4x TX | 125e6 | 1.25e6 | 60 | 3 tests total
2/3/4x TX | 122.88e6 | 1.2288e6 | 60 | 3 tests total
2/3/4x TX | 153.6e6 | 1.536e6 | 60 | 3 tests total
4x RX & 4x TX | 125e6 | 1.25e6 | 60 | Drop to 2 channels for N300
4x RX & 4x TX | 122.88e6 | 1.2288e6 | 60 | Drop to 2 channels for N300
4x RX & 4x TX | 153e6 | 1.536e6 | 60 | Drop to 2 channels for N300

### USRP N300/N310: 10 GigE Interface

- Required images to test: N310 HG + XG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test

Channels | Master Clock Rate | Sample Rates | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 125e6 | 1.25e6, 125e6 | 60 | One test each for all 4 channels
1x RX | 122.88e6 | 1.2288e6, 122.88e6 | 60 | One test each for all 4 channels
1x RX | 153.6e6 | 1.536e6, 153.6e6 | 60 | One test each for all 4 channels
1x TX | 125e6 | 1.25e6, 125e6 | 60 | One test each for all 4 channels
1x TX | 122.88e6 | 1.2288e6, 122.88e6 | 60 | One test each for all 4 channels
1x TX | 153.6e6 | 1.536e6, 153.6e6 | 60 | One test each for all 4 channels
2x RX | 125e6 | 1.25e6, 125e6 | 60 |
2x RX | 122.88e6 | 1.2288e6, 122.88e6 | 60 |
2x RX | 153.6e6 | 1.536e6 | 60 |
3x RX | 125e6 | 1.25e6 | 60 | N310 only
3x RX | 122.88e6 | 1.2288e6 | 60 | N310 only
3x RX | 153.6e6 | 1.536e6 | 60 | N310 only
2x TX | 125e6 | 1.25e6, 12.5e6 | 60 |
2x TX | 122.88e6 | 1.2288e6, 12.288e6 | 60 |
2x TX | 153.6e6 | 1.536e6, 15.36e6 | 60 |
3x TX | 125e6 | 1.25e6 | 60 | N310 only
3x TX | 122.88e6 | 1.2288e6 | 60 | N310 only
3x TX | 153.6e6 | 1.536e6 | 60 | N310 only
4x RX | 125e6 | 1.25e6, 62.5e6 | 60 | N310 only
4x TX | 125e6 | 1.25e6, 12.5e6 | 60 | N310 only
4x RX & 4x TX | 125e6 | 1.25e6, 62.5e6 | 60 | Drop to 2 channels for N300
4x RX & 4x TX | 122.88e6 | 1.2288e6, 61.44e6 | 60 | Drop to 2 channels for N300
4x RX & 4x TX | 153e6 | 1.536e6, 76.8e6 | 60 | Drop to 2 channels for N300
4x RX & 4x TX | 125e6 | 62.5e6 | 600 | Drop to 2 channels for N300
4x RX & 4x TX | 122.88e6 | 61.44e6 | 600 | Drop to 2 channels for N300
4x RX & 4x TX | 153e6 | 76.8e6 | 600 | Drop to 2 channels for N300
4x RX & 4x TX | 125e6 | 125e6 RX, 62.5e6 TX | 60 | Use dual 10GigE, N310 XG only
4x RX & 4x TX | 122.88e6 | 122.88e6 RX, 61.44e6 TX | 60 | Use dual 10GigE, N310 XG only
2x RX & 2x TX | 125e6 | 125e6 RX, 62.5e6 TX | 60 | Use dual 10GigE, N300 XG only
2x RX & 2x TX | 122.88e6 | 122.88e6 RX, 61.44e6 TX | 60 | Use dual 10GigE, N300 XG only
2x RX & 2x TX | 153e6 | 153e6 RX, 76.8e6 TX | 60 | Use dual 10GigE, N300 XG only

### USRP N320/N321: 1 GigE Interface

- Required images to test: HG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test
- Note: The following tests need to be completed only on either N320 OR N321

Channels | Master Clock Rate | Sample Rates | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 250e6 | 2.5e6 | 60 | One test each for both channels
1x RX | 245.76e6 | 2.4576e6 | 60 | One test each for both channels
1x RX | 200e6 | 2e6 | 60 | One test each for both channels
1x TX | 250e6 | 2.5e6 | 60 | One test each for both channels
1x TX | 245.76e6 | 2.4576e6 | 60 | One test each for both channels
1x TX | 200e6 | 2e6 | 60 | One test each for both channels
2x RX | 250e6 | 2.5e6 | 60 |
2x RX | 245.76e6 | 2.4576e6 | 60 |
2x RX | 200e6 | 2e6 | 60 |
2x TX | 250e6 | 2.5e6 | 60 |
2x TX | 245.76e6 | 2.4576e6 | 60 |
2x TX | 200e6 | 2e6 | 60 |
2x RX & 2x TX | 250e6 | 2.5e6 | 60 |
2x RX & 2x TX | 245.76e6 | 2.4576e6 | 60 |
2x RX & 2x TX | 200e6 | 2e6 | 60 |

### USRP N320/N321: 10 GigE Interface

- Required images to test: N320 HG + XG
- Note: On TX tests, initial Us within the first 5 seconds can be ignored and do not fail the test
- Note: The following tests need to be completed only on either N320 OR N321

Channels | Master Clock Rate | Sample Rates | Duration | Notes
--- | --- | --- | --- | ---
1x RX | 250e6 | 2.5e6 , 125e6 | 60 | One test each for both channels
1x RX | 245.76e6 | 2.4576e6, 122.88e6 | 60 | One test each for both channels
1x RX | 200e6 | 2e6 , 200e6 | 60 | One test each for both channels
1x TX | 250e6 | 2.5e6 , 125e6 | 60 | One test each for both channels
1x TX | 245.76e6 | 2.4576e6 , 122.88e6 | 60 | One test each for both channels
1x TX | 200e6 | 2e6 , 100e6 | 60 | One test each for both channels
2x RX | 250e6 | 2.5e6 , 125e6 | 60 |
2x RX | 245.76e6 | 2.4576e6, 122.88e6 | 60 |
2x RX | 200e6 | 2e6 , 100e6 | 60 |
2x TX | 250e6 | 62.5e6 | 60 |
2x TX | 245.76e6 | 61.44e6 | 60 |
2x TX | 200e6 | 100e6 | 60 |
2x RX & 2x TX | 250e6 | 2.5e6 | 60 |
2x RX & 2x TX | 245.76e6 | 2.4576e6 | 60 |
2x RX & 2x TX | 200e6 | 2e6 | 60 |
2x RX & 2x TX | 250e6 | 125e6 RX, 62.5e6 TX | 600 |
2x RX & 2x TX | 245.76e6 | 122.88e6 RX, 61.44e6 TX | 600 |
2x RX & 2x TX | 200e6 | 100e6 RX, 66.67e6 TX | 600 |
2x RX & 2x TX | 250e6 | 125e6 RX, 83.33e6 TX | 600 | Use dual 10GigE, N320/1 XG only
2x RX & 2x TX | 245.76e6 | 122.88e6 RX, 81.92e6 TX | 600 | Use dual 10GigE, N320/1 XG only
2x RX & 2x TX | 200e6 | 200e6 RX, 100e6 TX | 600 | Use dual 10GigE, N320/1 XG only
2x RX & 2x TX | 250e6 | 250e6 | 600 | Dual 10GigE, N320/1 XG, DPDK only
2x RX & 2x TX | 245.76e6 | 245.76e6 | 600 | Dual 10GigE, N320/1 XG, DPDK only
2x RX & 2x TX | 200e6 | 200e6 | 600 | Dual 10GigE, N320/1 XG, DPDK only

## FPGA Functional Verification: Automatic Test Procedure

In all cases, make sure UHD is compiled in 'Release' mode (highest optimization), and that all NIC and kernel are set to optimal (CPU governor, ring buffer settings, ...).

### X310/X300

The X310/X300 tests depend on the FPGA image to be tested.

#### HG

-Connect a 1GigE cable into port 0 and a 10GigE cable into port 1. -The following command must pass:

          $ usrp_fpga_funcverif x3x0hg -a 192.168.40.2 -2 192.168.10.2 -p /path/to/examples

#### XG

-Connect 10GigE cables to both ethernet ports. -The following command must pass:

          $ usrp_fpga_funcverif x3x0xg -a 192.168.40.2 -2 192.168.30.2 -p /path/to/examples

### N310/N300

The N310/N300 tests depend slightly on the type of FPGA image to be tested. All calls to usrp_fpga_funcverif.py need to be adapted to ensure the correct IP addresses and paths to the examples. Also, replace n310 with n300 where appropriate.

#### HG

- Connect a 1GigE cable on SFP0, and a 10 GigE cable on SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n310hg -a 192.168.20.2 -2 192.168.10.2 -p /path/to/examples

#### XG

- Connect a 10GigE cable on both SFP0 and SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n310xg -a 192.168.10.2 -2 192.168.20.2 -p /path/to/examples

#### HA

- Connect a 1GigE cable on SFP0
- The following command must pass:

         $ usrp_fpga_funcverif n310ha -2 192.168.10.2 -p /path/to/examples

#### XA

- Connect a 10GigE cable on SFP0
- The following command must pass:

         $ usrp_fpga_funcverif n310xa -a 192.168.10.2 -p /path/to/examples

#### WX

- Connect a 10GigE cable on SFP1
- The following command must pass:

         $ usrp_fpga_funcverif n310wx -a 192.168.20.2 -p /path/to/examples

### N320/N321

The N320/N321 tests depend slightly on the type of FPGA image to be tested. All calls to usrp_fpga_funcverif.py need to be adapted to ensure the correct IP addresses and paths to the examples. Also, the following test need to be run only on either N320 OR N321.

#### HG

- Connect a 1GigE cable on SFP0, and a 10 GigE cable on SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n320hg -a 192.168.20.2 -2 192.168.10.2 -p /path/to/examples

#### XG

- Connect a 10GigE cable on both SFP0 and SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n320xg -a 192.168.10.2 -2 192.168.20.2 -p /path/to/examples

#### XQ

- Connect a QSFP+ cable, carrying 2x10GigE, to the QSFP+ port
- The following command must pass:

         $ usrp_fpga_funcverif n320xq -a 192.168.10.2 -2 192.168.20.2 -p /path/to/examples

#### AQ

- Connect a 10GigE cable on both SFP0 and SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n320aq -a 192.168.10.2 -2 192.168.20.2 -p /path/to/examples

#### WX

- Connect a 10GigE cable on SFP1.
- The following command must pass:

         $ usrp_fpga_funcverif n320wx -a 192.168.20.2 -p /path/to/examples

### E310

The E310 tests need to be run on the device in the embedded mode.

#### Embedded mode

- Login into the device.
- The following command must pass:

         $ usrp_fpga_funcverif e3xxdev -a 127.0.0.1 -p /path/to/examples

### E320

The E320 tests depend on the FPGA image to be tested.

#### 1G

- Connect a 1GigE cable on the SFP port.
- The following command must pass:

         $ usrp_fpga_funcverif e3201g -a 192.168.10.2 -p /path/to/examples

#### XG

- Connect a 10GigE cable on the SFP port.
- The following command must pass:

         $ usrp_fpga_funcverif e320xg -a 192.168.10.2 -p /path/to/examples

#### Embedded mode

- Login into the device.
- The following command must pass:

         $ usrp_fpga_funcverif e3xxdev -a 127.0.0.1 -p /path/to/examples

# Phase alignment tests

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
PHASE-Twin-RX-v1 | 2xTwinRX | 1xX3x0 + LOSharing cables | X3x0 with TwinRX | Automatic phase alignment testing (Receiver)
PHASE-UBX-40-RX-v1 | 2xUBX-40 | 2xX3x0 | X3x0 with SBX or UBX | Automatic phase alignment testing (Receiver)
PHASE-UBX-160-RX-v1 | 2xUBX-160 | 2xX3x0 | X3x0 with SBX or UBX | Automatic phase alignment testing (Receiver)
PHASE-SBX-40-RX-v1 | 2xSBX-40 | 2xX3x0 | X3x0 with SBX or UBX | Automatic phase alignment testing (Receiver)
PHASE-SBX-120-RX-v1 | 2xSBX-120 | 2xX3x0 | X3x0 with SBX or UBX | Automatic phase alignment testing (Receiver)
PHASE-N2x0-MIMO-v1 | 2x N2x0 + MIMO cable | 2x SBX | N2x0 MIMO with SBX | Automatic phase alignment testing (Receiver)

Device | Frequency Range | Number of bands
--- | --- | ---
TwinRX | 10 - 6000 MHz | 12
UBX-{160, 40} | 10 - 6000 MHz | 12
SBX-{120, 40} | 400 - 4400 MHz | 7

Phase alignment testing is necessary to verify device synchronization across multiple daughter- and motherboards is working as expected for CBX, SBX and UBX daughterboards. To enable efficient Phase alignment testing a python based test script exists tools/usrptest. It is required for testing RX testcases and later may be required to perform TX testcases.

To test phase alignment we measure phase offset between DUTs at an offset of 2 MHz offset from the selected center frequency. The phase difference for a given center frequency has to stay the same across retunes and power cycles of the DUT.

Correct synchronization with PPS and 10 MHz references is required for these tests.

## Manual phase alignment testing (Receiver)

Equipment Required

- Octoclock-G
- Signal Generator
- 2-way splitter that covers frequency range for daughterboard (4-way for TwinRX)
- 5+ SMA Cables

Software Required

- UHD

## X3x0 with TwinRX

1. Make sure correct FPGA image is loaded on X3x0.
2. Place first daughterboard in slot A and second daughterboard in slot B.
3. Connect LO sharing cables between boards.
4. Connect host to device via 1 GbE, 10 GbE, or PCIe.
5. Connect 10 MHz and PPS from Octoclock-G to X3x0.
6. Connect Signal Generator to input of 4-way splitter and outputs of the splitter to the 2 RX ports on each daughterboard.
7. Set Signal Generator output power at -30 dBm.
8. From the top of the UHD source, run the command:
   - ./tools/usrptest/uhd_phase_alignment.py --spec "A:0 A:1 B:0 B:1" --channels 0,1,2,3 --sync pps --time-source external --clock-source external -s 5e6 -g 75 -f 10e6 --freq-bands 12 --start-freq 10e6 --stop-freq 6e9 --duration 2.0 --auto --lo-export True,False,False,False --lo-source internal,companion,external,external
9. At each frequency step, tune Signal Generator to the displayed frequency + 1 MHz and increase output power by 3 dB.
10. Analyze terminal output. The "run avg" across all runs should not deviate more than 1 degree and the "stddev" for any run should not deviate more than 1 degree.

## X3x0 with SBX or UBX

1. Set different IP addresses on each X3x0 and make sure correct FPGA image is loaded on each.
2. Place first daughterboard in slot A of first X3x0 and second daughterboard in slot A of second X3x0.
3. Connect host to both X3x0s.
4. Connect 10 MHz and PPS from Octoclock-G to both X3x0s.
5. Connect Signal Generator to input of splitter and outputs of the splitter to the RX2 port on each daughterboard.
6. Set Signal Generator output power at -35 dBm for UBX and -29 dBm for SBX.
7. From the top of the UHD source, run the command:
   - ./tools/usrptest/uhd_phase_alignment.py --args "addr0=<first X3x0 IP addr>,addr1=<second X3x0 IP addr>,dboard_clock_rate=20e6" --clock-source external --time-source external --sync pps --spec "A:0" --channels 0,1 -s 10e6 -g \<33 if UBX 37.5 if SBX\> -f \<lowest DB freq\> --freq-bands \<# frequency bands\> --start-freq \<lowest freq\> --stop-freq \<highest freq\> --duration 2.0 --auto
8. At each frequency step, tune Signal Generator to the displayed frequency + 1 MHz and increase output power by 1dB.
9. Analyze terminal output. The "run avg" across all runs should not deviate more than 2 degrees and the "stddev" for any run should not deviate more than 2 degrees.

## N2x0 MIMO with SBX

1. Set different IP addresses on each N2x0 and make sure correct FPGA image and firmware are loaded.
2. Connect MIMO cable between devices.
3. Connect host to master device via 1 GbE.
4. Connect 10 MHz and PPS from Octoclock-G to master device only.
5. Connect Signal Generator to input of splitter and outputs of the splitter to the RX2 port on each daughterboard.
6. Set Signal Generator output power at -36 dBm.
7. From the top of the UHD source, run the command:
   - ./tools/usrptest/usrp_phase_alignment.py --args "addr0=<IP address of master>,addr1=<IP address of slave>" --clock-source external,mimo --time-source external,mimo --sync default --channels 0,1 -s 10e6 -f 400e6 -g 31.5 --freq-bands 7 --start-freq 400e6 --stop-freq 4400e6 --duration 2.0 --auto
8. At each frequency step, tune Signal Generator to the displayed frequency + 1 MHz and increase output power by 2 dB.
9. Analyze terminal output. The "run avg" across all runs should not deviate more than 2 degrees and the "stddev" for any run should not deviate more than 5 degrees.

## Automatic phase alignment testing (Receiver)

tbd

# BISTs

Test Code | Device | Peripherals | Manual Test Procedure | Automatic Test Procedure
--- | --- | --- | --- | ---
BIST-N310-v1 | 1xN310 | DB-15 GPIO Loopback | N300/N310 Manual Procedure | N300/N310 Automatic Procedure
BIST-N300-v1 | 1xN300 | DB-15 GPIO Loopback | N300/N310 Manual Procedure | N300/N310 Automatic Procedure
BIST-E320-v1 | 1xE320 | Type C HDMI Cable + Breakout board with GPIO Loopback | E320 Manual Procedure | E320 Automatic Procedure

Some of our devices have built-in self-tests (BISTs).

## N300/N310 Manual Procedure

Note: The N300 and N310 have identical BISTs.

1. Connect the front-panel GPIO loopback to the front panel (see DB15 GPIO Loopback)
2. Execute the following commands:

        $ n3xx_bist standard # Note: This will run multiple tests
        $ n3xx_bist gpio

1. Load the AA image from a host computer. Adapt the following command to your system:

        $ uhd_image_loader --args type=n3xx,addr=ni-n3xx-$SERIAL --fpga-path=/path/to/usrp_n310_fpga_AA.bit

1. The final BIST is the SFP test, and there are three valid ways of executing them. For the purpose of running the test, only one of these needs to be run, and can be chosen based on the available peripherals. a. Connect an SFP loopback module to both SFP0 and SFP1. Run the command n3xx_bist sfp0_loopback sfp1_loopback. b. If only one SFP loopback module is available, connect the loopback module to SFP0 and run n3xx_bist sfp0_loopback. Then, connect the loopback module to SFP1 and run the command n3xx_bist sfp1_loopback. c. If no SFP loopback module is available, connect an SFP cable to both SFP0 and SFP1, and run the command n3xx_bist sfp_loopback. Note while this option is a legitimate substitute to the previous two options, it is of limited use when trying to debug actual SFP issues.

Every test will produce a JSON-serialized dictionary. All tests have passed if the "status" key is "true", or the return code for n3xx_bist is 0.

Note: Keep in mind that after the test, an Aurora image is loaded. If this is not desired, re-run uhd_image_loader to load whatever image is requested.

## N300/N310 Automatic Procedure

Note: The N300 and N310 have identical BISTs.

Assuming the peripherals described in N300/N310 Manual Procedure are all plugged in, the test can trivially be executed automatically by running

        $ n3xx_bist standard
        $ n3xx_bist gpio
        $ n3xx_bist sfp_loopback # Or sfp0_loopback and sfp1_loopback

and making sure that all return values are 0.

# Required Peripherals

# DB15 GPIO Loopback

This is a cable or breakout board which connects to the DB15 connector and loops back the following pins:

- 0<->6
- 1<->7
- 2<->8
- 3<->9
- 4<->10
- 5<->11

## E320 Manual Procedure

1. Connect the front-panel GPIO loopback to the front panel (see GPIO Loopback)
2. Execute the following commands:

        $ e320_bist standard # Note: This will run multiple tests
        $ e320_bist gpio

1. The final BIST is the SFP test. Connect an SFP loopback module to the SFP port. Run the command:

        $ e320_bist sfp_loopback

Every test will produce a JSON-serialized dictionary. All tests have passed if the "status" key is "true", or the return code for e320_bist is 0.

## E320 Automatic Procedure

Assuming the peripherals described in E320 Manual Procedure are all plugged in, the test can trivially be executed automatically by running

        $ e320_bist standard
        $ e320_bist gpio
        $ e320_bist sfp_loopback

and making sure that all return values are 0.

# Required Peripherals

# GPIO Loopback

1. Type C to Type A HDMI Cable
2. Breakout Board which connects to the connector and loops back the following pins:

- 0<->4
- 1<->5
- 2<->6
- 3<->7

# Defining R&D Tests

Tests can be added any time to define procedures for pass/fail validation. Any test must include the following:

- An unambiguous test code. This code consists of three characters that identify the test, a short description of the devices required, and a version suffix. Example: GPS-X310-OCXO-v1 is a GPS-related test, requires an X310 and an OCXO to run, and is version 1 of this test.
- A manual testing procedure. This must unambiguously define a set of tasks, and clearly identify whether or not a test has failed or passed. Tests do not require any other defined outcome other than 'pass' and 'fail'.
- Optional, but highly recommended: An automatic test procedure. This must consist of a command, or a script, or a set of commands that can be automatically executed, and that will report a failure condition by means of returning a non-zero return value.

Basic understanding of the operation of USRPs by the test operator should be assumed when authoring test procedures. The descriptions should be as short as possible to fully describe, unambiguously, how to reach a pass/fail conclusion.

Test procedures may be updated at any time. If this happens, a new test code must be generated, with the version number increased. Old test codes are considered deprecated (if there exists a version 2 of a test, version 1 should not be run any more).