 |
USRP Hardware Driver and USRP Manual
Version: 003.010.001.HEAD-0-gc705922a
UHD and USRP Manual
|
|
|
USRP Hardware Driver and USRP Manual
Version: 003.010.001.HEAD-0-gc705922a
UHD and USRP Manual
|
|
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.
| 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 |
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):
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).
uhd_usrp_probe on the device and verify that the lack of GPSDO is correctly reported. No warning or error must be printed.uhd_usrp_probe and verify that the GPSDO is correctly reported. Power down the device before connecting the peripheral. The GPSDO must be reported found, and no error or warning must be printed.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.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.
tbd
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.
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).
make test_x3x0 from the command line in the build directory. Multiple devices connected will all get tested, there is no requirement to only connect a single device at a time (because devtest will run sequentially anyway).Note: The test codes with an 'm' suffix refer to B200mini and B205mini, respectively.
make test_b2xxmake test_e3xx is sufficient.$DEVTEST_DIR/run_testsuite.py --src-dir $DEVTEST_DIR \
--devtest-pattern e3xx \
--build-type na \
--build-dir $EXAMPLES_DIR \
--device-filter e3x0 \
--log-dir $LOG_DIR
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').
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 |
These tests are simulations and do not need any device. Vivado 15.4 should be installed.
[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...
TESTBENCH FINISHED: noc_block_skeleton
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
Go to <fpga-dir>/usrp3/ and run 'build.py xsim all'. All tests should report 'PASS'.
Tests can be added any time to define procedures for pass/fail validation. Any test must include the following:
GPS-X310-OCXO-v1 is a GPS-related test, requires an X310 and an OCXO to run, and is version 1 of this test.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).
| 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 GNU Radio Out-of-Tree module gr-usrptest exists in tools/gr-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.
./usrp_phasealignment.py
--s 10e6 -runs 10 --duration 2.0 --plot --auto \
--sync pps --time-source external --clock-source external \
--args "addr0=<address first X3x0>,addr1=<address second X3x0>" \
--channels <first channel, second channel (e.g. 0,2)> \
-f <frequency> \
--freq-bands <# frequency bands> \
--start-freq <lowest daughterboard frequency> --stop-freq <highest daughterboard frequency> \
tbd
Phase alignment testing with TwinRX works as described above with additional test cases and commandline options. TwinRX offers LO sharing inside one board and across boards. For uhd_app and derived applications involving our tools and GNU Radio we have introduced --lo-source {internal, companion, external} and --lo-export {True, False} arguments to apply LO sharing feartures on TwinRX daughterboards. Two testcases have to pass:
When testing TwinRX put 2 daughterboards in separate motherboards and connect LO sharing cables. Setup USRPs in a similar fashion as described above. Supply additional commandline arguments to ./usrp_phasealignment.py. Use four receive channels --channels 0,1,2,3 and therefore specify --spec "A:0 A:1 B:0 B:1" to address both receiver channels on each daughterboard. Also supply --lo-export True,False,False,False and --lo-source internal,companion,external,external if your LO sharing setup exports LOs from the first motherboard to the second otherwise adjust lo sharing arguments.
Phase alignment testing with N210 and MIMO cable works like in the case with X3x0 devices but no Octoclock is needed for device synchronization. Instead two N210 devices are connected with a MIMO cable and only one N210 is connected with an ethernet cable to the host computer. Supply --time-source internal,mimo and --clock-source internal,mimo on the commandline to instruct the N2x0s to share time and clock over the MIMO cable.
1.8.13