diff options
Diffstat (limited to 'host/docs')
| -rw-r--r-- | host/docs/gpsdo.rst | 87 | ||||
| -rw-r--r-- | host/docs/identification.rst | 130 | ||||
| -rw-r--r-- | host/docs/usrp1.rst | 111 | ||||
| -rw-r--r-- | host/docs/usrp2.rst | 474 | ||||
| -rw-r--r-- | host/docs/usrp_x3x0.dox | 2 |
5 files changed, 803 insertions, 1 deletions
diff --git a/host/docs/gpsdo.rst b/host/docs/gpsdo.rst new file mode 100644 index 000000000..5afd9d78d --- /dev/null +++ b/host/docs/gpsdo.rst @@ -0,0 +1,87 @@ +======================================================================== +UHD - Internal GPSDO Application Notes (USRP-N2x0/E1X0 Models) +======================================================================== + +.. contents:: Table of Contents + +This application note describes the use of integrated GPS-disciplined oscillators (GPSDOs) for +the USRP N-Series and E1xx. For information regarding the GPSDO that is compatible with +the USRP X-Series, please see: + +`USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_ + +======= + +------------------------------------------------------------------------ +Specifications +------------------------------------------------------------------------ +* **Receiver type**: 50 channel with WAAS, EGNOS, MSAS +* **10MHz ADEV**: 1e-11 over >24h +* **1PPS RMS jitter**: <50ns 1-sigma +* **Holdover**: <11us over 3h +* **Phase noise**: + + * **1Hz:** -80 dBc/Hz + * **10Hz:** -110 dBc/Hz + * **100Hz:** -135 dBc/Hz + * **1kHz:** -145 dBc/Hz + * **10kHz:** <-145 dBc/Hz + +**Antenna Types:** + +The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas. + +------------------------------------------------------------------------ +Installation Instructions +------------------------------------------------------------------------ +Instructions for mounting the GPSDO kit onto your USRP device can be found here: +`http://www.ettus.com/content/files/gpsdo-kit_2.pdf <http://www.ettus.com/content/files/gpsdo-kit_2.pdf>`_ + +******************************************** +Post-installation Task (N-Series only) +******************************************** + +**Note:** The following instructions are only necessary for UHD 3.4.* and below. + +This is necessary if you require absolute GPS time in your application +or need to communicate with the GPSDO to obtain location, satellite info, etc. +If you only require 10 MHz and PPS signals for reference or MIMO use +(see the `Synchronization Application Notes <./sync.html>`_), +it is not necessary to perform this step. + +To configure the USRP to communicate with the GPSDO, use the +**usrp_burn_mb_eeprom** utility: + +:: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --values="gpsdo=internal" + + -- restore original setting -- + ./usrp_burn_mb_eeprom --args=<optional device args> --values="gpsdo=none" + +------------------------------------------------------------------------ +Using the GPSDO in Your Application +------------------------------------------------------------------------ +By default, if a GPSDO is detected at startup, the USRP will be configured +to use it as a frequency and time reference. The internal VITA timestamp +will be initialized to the GPS time, and the internal oscillator will be +phase-locked to the 10 MHz GPSDO reference. If the GPSDO is not locked to +satellites, the VITA time will not be initialized. + +GPS data is obtained through the **mboard_sensors** interface. To retrieve +the current GPS time, use the **gps_time** sensor: + +:: + + usrp->get_mboard_sensor("gps_time"); + +The returned value will be the current epoch time, in seconds since +January 1, 1970. This value is readily converted into human-readable +format using the **time.h** library in C, **boost::posix_time** in C++, etc. + +Other information can be fetched as well. You can query the lock status +with the **gps_locked** sensor, as well as obtain raw NMEA sentences using +the **gps_gprmc**, and **gps_gpgga** sensors. Location +information can be parsed out of the **gps_gpgga** sensor by using **gpsd** or +another NMEA parser. diff --git a/host/docs/identification.rst b/host/docs/identification.rst new file mode 100644 index 000000000..65b4e5e99 --- /dev/null +++ b/host/docs/identification.rst @@ -0,0 +1,130 @@ +================================= +UHD - Device Identification Notes +================================= + +.. contents:: Table of Contents + +------------------------ +Identifying USRP Devices +------------------------ +Devices are addressed through key/value string pairs. +These string pairs can be used to narrow down the search for a specific device or group of devices. +Most UHD utility applications and examples have an **--args** parameter that takes a device address, which is expressed as a delimited string. + +See the documentation in **types/device_addr.hpp** for reference. + +^^^^^^^^^^^^^^^^^^^^^^^^^ +Common device identifiers +^^^^^^^^^^^^^^^^^^^^^^^^^ +Every device has several ways of identifying it on the host system: + ++------------+----------+-----------------------------------------------------------+------------------------------- +| Identifier | Key | Notes | Example ++============+==========+===========================================================+=============================== +| Serial | serial | globally unique identifier | 12345678 ++------------+----------+-----------------------------------------------------------+---------------------------- +| Address | addr | unique identifier on a network | 192.168.10.2 ++------------+----------+-----------------------------------------------------------+------------------------------- +| Resource | resource | unique identifier for USRP RIO devices (over PCI Express) | RIO0 ++------------+----------+-----------------------------------------------------------+------------------------------- +| Name | name | optional user-set identifier | my_usrp1 (User-defined value) ++------------+----------+-----------------------------------------------------------+---------------------------- +| Type | type | hardware series identifier | usrp1, usrp2, ++------------+----------+-----------------------------------------------------------+---------------------------- + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Device discovery via command line +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Devices attached to your system can be discovered using the **uhd_find_devices** program. +This program scans your system for supported devices and prints +out an enumerated list of discovered devices and their addresses. +The list of discovered devices can be narrowed down by specifying device address args. + +:: + + uhd_find_devices + +Device address arguments can be supplied to narrow the scope of the search. + +:: + + uhd_find_devices --args="type=usrp1" + + -- OR -- + + uhd_find_devices --args="serial=12345678" + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Device discovery through the API +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The **device::find()** API call searches for devices and returns a list of discovered devices. + +:: + + uhd::device_addr_t hint; //an empty hint discovers all devices + uhd::device_addrs_t dev_addrs = uhd::device::find(hint); + +The **hint** argument can be populated to narrow the scope of the search. + +:: + + uhd::device_addr_t hint; + hint["type"] = "usrp1"; + uhd::device_addrs_t dev_addrs = uhd::device::find(hint); + + -- OR -- + + uhd::device_addr_t hint; + hint["serial"] = "12345678"; + uhd::device_addrs_t dev_addrs = uhd::device::find(hint); + +^^^^^^^^^^^^^^^^^ +Device properties +^^^^^^^^^^^^^^^^^ +Properties of devices attached to your system can be probed with the **uhd_usrp_probe** program. +This program constructs an instance of the device and prints out its properties, +such as detected daughterboards, frequency range, gain ranges, etc... + +**Usage:** + +:: + + uhd_usrp_probe --args <device-specific-address-args> + +-------------------- +Naming a USRP Device +-------------------- +For convenience purposes, users may assign a custom name to their USRP device. +The USRP device can then be identified via name, rather than a difficult to remember serial or address. + +A name has the following properties: + +* is composed of ASCII characters +* is 0-20 characters +* is not required to be unique + +^^^^^^^^^^^^^^^^^ +Set a custom name +^^^^^^^^^^^^^^^^^ + +Run the following commands: + +:: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --values="name=lab1_xcvr" + +^^^^^^^^^^^^^^^^^^ +Discovery via name +^^^^^^^^^^^^^^^^^^ + +The keyword **name** can be used to narrow the scope of the search. +Example with the find devices utility: + +:: + + uhd_find_devices --args="name=lab1_xcvr" + + -- OR -- + + uhd_find_devices --args="type=usrp1, name=lab1_xcvr" diff --git a/host/docs/usrp1.rst b/host/docs/usrp1.rst new file mode 100644 index 000000000..ecf90502b --- /dev/null +++ b/host/docs/usrp1.rst @@ -0,0 +1,111 @@ +======================================================================== +UHD - USRP1 Device Manual +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Comparative features list +------------------------------------------------------------------------ + +**Hardware Capabilities:** + * 2 transceiver card slots + * 64 MHz fixed clock rate + +**FPGA Capabilities:** + * 2 RX DDC chains in FPGA + * 2 TX DUC chains in FPGA (no TX CORDIC -> uses DAC) + * sc16 sample modes - RX & TX + + - Up to 8 MHz of RF BW with 16-bit samples + + * sc8 sample mode - RX only + + - Up to 16 MHz of RF BW with 8-bit samples + +------------------------------------------------------------------------ +Specify a Non-standard Image +------------------------------------------------------------------------ +The standard USRP1 images installer comes with two FPGA images: + * **usrp1_fpga.rbf:** 2 DDCs + 2 DUCs + * **usrp1_fpga_4rx.rbf:** 4 DDCs + 0 DUCs + +By default, the USRP1 uses the FPGA image with 2 DDCs and 2 DUCs. +However, a device address parameter can be used to override +the FPGA image selection to use an alternate or a custom FPGA image. +See the images application notes for installing custom images. + +Example device address string representations to specify non-standard firmware and/or FPGA images: + +:: + + fpga=usrp1_fpga_4rx.rbf + + -- OR -- + + fw=usrp1_fw_custom.ihx + + -- OR -- + + fpga=usrp1_fpga_4rx.rbf, fw=usrp1_fw_custom.ihx + +------------------------------------------------------------------------ +Missing and Emulated Features +------------------------------------------------------------------------ +The USRP1 FPGA does not have the necessary space to support the advanced +streaming capabilities that are possible with the newer USRP devices. +Some of these features are emulated in software to support the API. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +List of emulated features +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* Setting the current device time +* Getting the current device time +* Transmitting at a specific time +* Transmitting a specific number of samples +* Receiving at a specific time +* Receiving a specific number of samples +* End of burst flags for transmit/receive +* Notification on late stream command +* Notification on late transmit packet +* Notification on underflow or overflow +* Notification on broken chain error + +**Note:** +These emulated features rely on the host system's clock for timed operations +and therefore may not have sufficient precision for the application. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +List of missing features +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* Start of burst flags for transmit/receive + +------------------------------------------------------------------------ +Hardware Setup Notes +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +External clock modification +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The USRP device can be modified to accept an external clock reference instead of the 64MHz onboard reference. + * Solder SMA (**LTI-SASF54GT**) connector to **J2001**. + * Move 0 ohm 0603 resistor **R2029** to **R2030**. + * Move 0.01uF 0603 capacitor **C925** to **C926**. + * Remove 0.01uF 0603 capacitor **C924**. + +The new external clock needs to be a square wave between +7dBm and +15dBm + +After the hardware modification, +the user should burn the setting into the EEPROM, +so UHD software can initialize with the correct clock rate. +Run the following commands to record the setting into the EEPROM: +:: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --values="mcr=<rate>" + +The user may override the clock rate specified in the EEPROM by using a device address: +Example: +:: + + uhd_usrp_probe --args="mcr=52e6" diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst new file mode 100644 index 000000000..1070a23fc --- /dev/null +++ b/host/docs/usrp2.rst @@ -0,0 +1,474 @@ +======================================================================== +UHD - USRP2 and N2x0 Series Device Manual +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Comparative features list +------------------------------------------------------------------------ + +**Hardware Capabilities:** + * 1 transceiver card slot + * External PPS reference input + * External 10 MHz reference input + * MIMO cable shared reference + * Fixed 100 MHz clock rate + * Internal GPSDO option (N2x0 only) + +**FPGA Capabilities:** + * 2 RX DDC chains in FPGA + * 1 TX DUC chain in FPGA + * Timed commands in FPGA (N2x0 only) + * Timed sampling in FPGA + * 16-bit and 8-bit sample modes (sc8 and sc16) + + * Up to 25 MHz of RF BW with 16-bit samples + * Up to 50 MHz of RF BW with 8-bit samples + +------------------------------------------------------------------------ +Load the Images onto the SD card (USRP2 only) +------------------------------------------------------------------------ +**Warning!** +Use **usrp2_card_burner** with caution. If you specify the wrong device node, +you could overwrite your hard drive. Make sure that **--dev=** specifies the SD card. + +**Warning!** +It is possible to use 3rd party SD cards with the USRP2. +However, certain types of SD cards will not interface with the CPLD: + +* Cards can be SDHC, which is not a supported interface. +* Cards can have unexpected timing characteristics. + +For these reasons, we recommend that you use the SD card that was supplied with the USRP2. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the card burner tool (UNIX) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + sudo <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py + + -- OR -- + + cd <install-path>/lib/uhd/utils + sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fpga=<path_to_fpga_image> + sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fw=<path_to_firmware_image> + +Use the **--list** option to get a list of possible raw devices. +The list result will filter out disk partitions and devices too large to be the sd card. +The list option has been implemented on Linux, Mac OS X, and Windows. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the card burner tool (Windows) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + <path_to_python.exe> <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py + +------------------------------------------------------------------------ +Load the Images onto the On-board Flash (USRP-N Series only) +------------------------------------------------------------------------ +The USRP-N Series can be reprogrammed over the network to update or change the firmware and FPGA images. +When updating images, always burn both the FPGA and firmware images before power cycling. +This ensures that when the device reboots, it has a compatible set of images to boot into. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the net burner tool +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + Use default images: + usrp_n2xx_simple_net_burner --addr=<IP address> + + Use custom-built images: + usrp_n2xx_simple_net_burner --addr=<IP address> --fw=<firmware path> --fpga=<FPGA path> + +**Note:** +Different hardware revisions require different FPGA images. +Determine the revision number from the sticker on the rear of the chassis. +Use this number to select the correct FPGA image for your device. + +For users who would prefer a graphical utility, a Python-based alternative exists. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the graphical net burner tool (Linux) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the graphical net burner tool (Windows) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + <path_to_python.exe> <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Device recovery and bricking +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Its possible to put the device into an unusable state by loading bad images. +Fortunately, the USRP-N Series can be booted into a safe (read-only) image. +Once booted into the safe image, the user can once again load images onto the device. + +The safe-mode button is a pushbutton switch (S2) located inside the enclosure. +To boot into the safe image, hold-down the safe-mode button while power-cycling the device. +Continue to hold-down the button until the front-panel LEDs blink and remain solid. + +When in safe-mode, the USRP-N device will always have the IP address **192.168.10.2**. + +------------------------------------------------------------------------ +Setup Networking +------------------------------------------------------------------------ +The USRP2 only supports Gigabit Ethernet +and will not work with a 10/100 Mbps interface. +However, a 10/100 Mbps interface can be connected indirectly +to a USRP2 through a Gigabit Ethernet switch. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Setup the host interface +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The USRP2 communicates at the IP/UDP layer over the gigabit ethernet. +The default IP address of the USRP2 is **192.168.10.2**. +You will need to configure the host's Ethernet interface with a static IP +address to enable communication. An address of **192.168.10.1** and a subnet +mask of **255.255.255.0** is recommended. + +On a Linux system, you can set a static IP address very easily by using the +'ifconfig' command: +:: + + sudo ifconfig <interface> 192.168.10.1 + +Note that **<interface>** is usually something like **eth0**. You can discover the +names of the network interfaces in your computer by running **ifconfig** without +any parameters: +:: + + ifconfig -a + +**Note:** +When using UHD software, if an IP address for the USRP2 is not specified, +the software will use UDP broadcast packets to locate the USRP2. +On some systems, the firewall will block UDP broadcast packets. +It is recommended that you change or disable your firewall settings. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Multiple devices per host +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For maximum throughput, one Ethernet interface per USRP2 is recommended, +although multiple devices may be connected via a Gigabit Ethernet switch. +In any case, each Ethernet interface should have its own subnet, +and the corresponding USRP2 device should be assigned an address in that subnet. +Example: + +**Configuration for USRP2 device 0:** + +* Ethernet interface IPv4 address: **192.168.10.1** +* Ethernet interface subnet mask: **255.255.255.0** +* USRP2 device IPv4 address: **192.168.10.2** + +**Configuration for USRP2 device 1:** + +* Ethernet interface IPv4 address: **192.168.20.1** +* Ethernet interface subnet mask: **255.255.255.0** +* USRP2 device IPv4 address: **192.168.20.2** + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Change the USRP2's IP address +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +You may need to change the USRP2's IP address for several reasons: + +* to satisfy your particular network configuration +* to use multiple USRP2s on the same host computer +* to set a known IP address into USRP2 (in case you forgot) + +**Method 1:** +To change the USRP2's IP address, +you must know the current address of the USRP2, +and the network must be setup properly as described above. +Run the following commands: +:: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --values="ip-addr=192.168.10.3" + +**Method 2 (Linux Only):** +This method assumes that you do not know the IP address of your USRP2. +It uses raw Ethernet packets to bypass the IP/UDP layer to communicate with the USRP2. +Run the following commands: +:: + + cd <install-path>/lib/uhd/utils + sudo ./usrp2_recovery.py --ifc=eth0 --new-ip=192.168.10.3 + +------------------------------------------------------------------------ +Communication Problems +------------------------------------------------------------------------ +When setting up a development machine for the first time, +you may have various difficulties communicating with the USRP device. +The following tips are designed to help narrow down and diagnose the problem. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +RuntimeError: no control response +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This is a common error that occurs when you have set the subnet of your network +interface to a different subnet than the network interface of the USRP device. For +example, if your network interface is set to **192.168.20.1**, and the USRP device is +**192.168.10.2** (note the difference in the third numbers of the IP addresses), you +will likely see a 'no control response' error message. + +Fixing this is simple - just set the your host PC's IP address to the same +subnet as that of your USRP device. Instructions for setting your IP address are in the +previous section of this documentation. + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Firewall issues +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +When the IP address is not specified, +the device discovery broadcasts UDP packets from each ethernet interface. +Many firewalls will block the replies to these broadcast packets. +If disabling your system's firewall +or specifying the IP address yields a discovered device, +then your firewall may be blocking replies to UDP broadcast packets. +If this is the case, we recommend that you disable the firewall +or create a rule to allow all incoming packets with UDP source port **49152**. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Ping the device +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The USRP device will reply to ICMP echo requests. +A successful ping response means that the device has booted properly +and that it is using the expected IP address. + +:: + + ping 192.168.10.2 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Monitor the serial output +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Read the serial port to get debug verbose output from the embedded microcontroller. +The microcontroller prints useful information about IP addresses, +MAC addresses, control packets, fast-path settings, and bootloading. +Use a standard USB to 3.3v-level serial converter at 230400 baud. +Connect **GND** to the converter ground, and connect **TXD** to the converter receive. +The **RXD** pin can be left unconnected as this is only a one-way communication. + +* **USRP2:** Serial port located on the rear edge +* **N210:** Serial port located on the left side + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Monitor the host network traffic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use Wireshark to monitor packets sent to and received from the device. + +------------------------------------------------------------------------ +Addressing the Device +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Single device configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In a single-device configuration, the USRP device must have a unique IPv4 +address on the host computer. The USRP can be identified through its IPv4 +address, resolvable hostname, or by other means. See the application notes on +`device identification <./identification.html>`_. Please note that this +addressing scheme should also be used with the **multi_usrp** interface. + +Example device address string representation for a USRP2 with IPv4 address **192.168.10.2**: + +:: + + addr=192.168.10.2 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Multiple device configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In a multi-device configuration, +each USRP device must have a unique IPv4 address on the host computer. +The device address parameter keys must be suffixed with the device index. +Each parameter key should be of the format <key><index>. +Use this addressing scheme with the **multi_usrp** interface. + +* The order in which devices are indexed corresponds to the indexing of the transmit and receive channels. +* The key indexing provides the same granularity of device identification as in the single device case. + +Example device address string representation for 2 USRP2s with IPv4 addresses **192.168.10.2** and **192.168.20.2**: +:: + + addr0=192.168.10.2, addr1=192.168.20.2 + +------------------------------------------------------------------------ +Using the MIMO Cable +------------------------------------------------------------------------ +The MIMO cable allows two USRP devices to share reference clocks, +time synchronization, and the Ethernet interface. +One of the devices will sync its clock and time references to the MIMO cable. +This device will be referred to as the slave, and the other device, the master. + +* The slave device acquires the clock and time references from the master device. +* The master and slave may be used individually or in a multi-device configuration. +* External clocking is optional and should only be supplied to the master device. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Shared Ethernet mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In shared Ethernet mode, +only one device in the configuration can be attached to the Ethernet. + +* Clock reference, time reference, and data are communicated over the MIMO cable. +* Master and slave must have different IPv4 addresses in the same subnet. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Dual Ethernet mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In dual Ethernet mode, +both devices in the configuration must be attached to the Ethernet. + +* Only clock reference and time reference are communicated over the MIMO cable. +* The master and slave must have different IPv4 addresses in different subnets. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Configuring the slave +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In order for the slave to synchronize to the master over MIMO cable, +the following clock configuration must be set on the slave device: +:: + + usrp->set_time_source("mimo", slave_index); + usrp->set_clock_source("mimo", slave_index); + + +------------------------------------------------------------------------ +Alternative stream destination +------------------------------------------------------------------------ +It is possible to program the USRP device to send RX packets to an alternative IP/UDP destination. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set the subnet and gateway +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To use an alternative streaming destination, +the device needs to be able to determine if the destination address +is within its subnet, and ARP appropriately. +Therefore, the user should ensure that subnet and gateway addresses +have been programmed into the device's EEPROM. + +Run the following commands: +:: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --values="subnet=255.255.255.0,gateway=192.168.10.1" + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Create a receive streamer +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set the stream args "addr" and "port" values to the alternative destination. +Packets will be sent to this destination when the user issues a stream command. + +:: + + //create a receive streamer, host type does not matter + uhd::stream_args_t stream_args("fc32"); + + //resolvable address and port for a remote udp socket + stream_args.args["addr"] = "192.168.10.42"; + stream_args.args["port"] = "12345"; + + //create the streamer + uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args); + + //issue stream command + uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); + stream_cmd.num_samps = total_num_samps; + stream_cmd.stream_now = true; + usrp->issue_stream_cmd(stream_cmd); + +**Note:** +Calling recv() on this streamer object should yield a timeout. + +------------------------------------------------------------------------ +Hardware Setup Notes +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Front panel LEDs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The LEDs on the front panel can be useful in debugging hardware and software issues. +The LEDs reveal the following about the state of the device: + +* **LED A:** transmitting +* **LED B:** MIMO cable link +* **LED C:** receiving +* **LED D:** firmware loaded +* **LED E:** reference lock +* **LED F:** CPLD loaded + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Ref Clock - 10 MHz +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Using an external 10 MHz reference clock, a square wave will offer the best phase +noise performance, but a sinusoid is acceptable. The reference clock requires the following power level: + +* **USRP2** 5 to 15 dBm +* **N2XX** 0 to 15 dBm + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +PPS - Pulse Per Second +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Using a PPS signal for timestamp synchronization requires a square wave signal with the following amplitude: + +* **USRP2** 5Vpp +* **N2XX** 3.3 to 5Vpp + +Test the PPS input with the following app: + +* **<args>** are device address arguments (optional if only one USRP device is on your machine) + +:: + + cd <install-path>/lib/uhd/examples + ./test_pps_input --args=<args> + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Internal GPSDO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Please see the `Internal GPSDO Application Notes <./gpsdo.html>`_ +for information on configuring and using the internal GPSDO. + +------------------------------------------------------------------------ +Miscellaneous +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Available Sensors +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The following sensors are available for the USRP2/N-Series motherboards; +they can be queried through the API. + +* **mimo_locked** - clock reference locked over the MIMO cable +* **ref_locked** - clock reference locked (internal/external) +* other sensors are added when the GPSDO is enabled + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Multiple RX channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +There are two complete DDC chains in the FPGA. +In the single channel case, only one chain is ever used. +To receive from both channels, +the user must set the **RX** subdevice specification. +This hardware has only one daughterboard slot, +which has been aptly named slot **A**. + +In the following example, a TVRX2 is installed. +Channel 0 is sourced from subdevice **RX1**, +and channel 1 is sourced from subdevice **RX2** (**RX1** and **RX2** +are the antenna ports on the TVRX2 daughterboard): + +:: + + usrp->set_rx_subdev_spec("A:RX1 A:RX2"); diff --git a/host/docs/usrp_x3x0.dox b/host/docs/usrp_x3x0.dox index 7996bc7e1..42574334b 100644 --- a/host/docs/usrp_x3x0.dox +++ b/host/docs/usrp_x3x0.dox @@ -91,7 +91,7 @@ number, you will have to update the FPGA image before you can start using your U usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path <path_to_images>/usrp_x310_fpga_HGS.bit - The process of updating the FPGA will take several minutes. Make sure the process of flashing the image does not get interrupted. + The process of updating the FPGA image will take several minutes. Make sure the process of flashing the image does not get interrupted. See \ref x3x0_flash for more details. |