Difference between revisions of "E310/E312"

Revision as of 15:03, 25 June 2017

Device Overview

The USRP E310 offers a portable stand-alone SDR platform designed for field deployment. The flexible 2x2 MIMO AD9361 transceiver from Analog Devices provides up to 56 MHz of instantaneous bandwidth and spans frequencies from 70 MHz – 6 GHz to cover multiple bands of interest.

Key Features

E310

Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 667 MHz dual-core processor Analog Devices AD9361 RFIC direct-conversion transceiver Frequency range: 70 MHz - 6 GHz Up to 56 MHz of instantaneous bandwidth 2x2 MIMO transceiver Up to 10 MS/s sample data transfer rate to ARM processor RX, TX filter banks Integrated GPS receiver 9-axis inertial measurement unit RF Network on Chip (RFNoC™) FPGA development framework support

E312

Battery Operated Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 866 MHz dual-core processor Analog Devices AD9361 RFIC direct-conversion transceiver Frequency range: 70 MHz - 6 GHz Up to 56 MHz of instantaneous bandwidth 2x2 MIMO transceiver Up to 10 MS/s sample data transfer rate to ARM processor RX, TX filter banks Integrated GPS receiver 9-axis inertial measurement unit RF Network on Chip (RFNoC™) FPGA development framework support

Daughterboard Specifications

E310 MIMO XCVR board

The USRP E310 MIMO XCVR daughterboard features an integrated MIMO capable RF frontend.

Tuning

The RF frontend has individually tunable receive and transmit chains. Both transmit and receive can be used in a MIMO configuration. For the MIMO case, both receive frontends share the RX LO, and both transmit frontends share the TX LO. Each LO is tunable between 50 MHz and 6 GHz.

Gains

All frontends have individual analog gain controls. The receive frontends have 76 dB of available gain; and the transmit frontends have 89.5 dB of available gain. Gain settings are application specific, but it is recommended that users consider using at least half of the available gain to get reasonable dynamic range.

LO lock status

The frontends provide a lo-locked sensor that can be queried through the UHD API.

// assumes 'usrp' is a valid uhd::usrp::multi_usrp::sptr instance
// get status for rx frontend
usrp->get_rx_sensor("lo-locked");
// get status for tx frontend
usrp->get_tx_sensor("lo-locked");

Filter and Antenna Switches

The transmit and receive filter banks uses switches to select between the available filters. These paths are also dependent on the antenna switch settings. Incorrectly setting the switches generally results in attenuated input / output power. Receive filters are band pass (series high & low pass filters), transmit filters are low pass.

Source code related to controlling the filter band and antenna switches resides in e300_impl.c. Specifically, refer to methods e300_impl::_update_bandsel, e300_impl::_update_atrs, e300_impl::_update_gpio, and e300_impl::_update_enables. Generally, these methods set the switches depending on the state of transmit and receive streams.

The following sections provide switch setting tables for antenna and filter selection for frontends A & B receive and transmit paths. For futher details refer to the schematics.

Side A Filter and Antenna Switches

Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care. Filter range A – B will be selected if A <= freq < B.

Receive

Transmit

Note: Although the transmit filters are low pass, this table describes UHD's tuning range for selecting each filter path. The table also includes the required transmit enable state.

Side B Filter and Antenna Switches

Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care. Filter range A – B will be selected if A <= freq < B.

Receive

Transmit

Note: Although the transmit filters are low pass, the following table describes UHD's tuning range for selecting each filter path. The table also includes the required transmit enable states.

RF Specifications

RF Performance

• SSB/LO Suppression -35/50 dBc
• Phase Noise 3.5 GHz 1.0 deg RMS
• Phase Noise 6 GHz 1.5 deg RMS
• Power Output >10dBm
• IIP3 (@ typ NF) -20dBm
• Typical Noise Figure <8dB

Input/Output Impedance

• All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.

Hardware Specifications

• Ettus Research recommends to always use the latest stable version of UHD

E310

• Current Hardware Revision: 1
• Minimum version of UHD required: 3.8.0
• Required version on the host computer must match what is running on the E310

E312

• Current Hardware Revision: 1
• Minimum version of UHD required: 3.8.5
• Required version on the host computer must match what is running on the E312

Physical Specifications

Dimensions

• 133 x 68 x 26.4 mm

Environmental Specifications

Operating Temperature Range

• E310 0-40 °C
• E312 0-40 °C

Operating Humidity Range

• 10% to 90% non-condensing

Schematics

E310

E310 Schematics

E310 DB

E310 Architecture

Key Component Datasheets

Request a detailed whitepaper covering features and components from info@ettus.com

Mechanical Information

Weight

• Partial Enclosure 225 g
• Full Enclosure 375 g

Drawings

E310

• File:E310 Dimensional Sketches.pdf
• File:cu e310 motherboard cca.pdf
• File:cu E310 daughtercard cca.pdf
• File:cu usrp-e310.pdf

E312

• File:cu e312 motherboard cca.pdf
• File:cu e312 daughtercard cca.pdf
• File:cu ettus-e312.pdf

FPGA

• Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4 and was taken directly from Xilinx Vivado 2014.4.

E310/E312

1. Slice Logic
--------------

+----------------------------+-------+-----------+-------+
|          Site Type         |  Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs                 | 36203 |     53200 | 68.05 |
|   LUT as Logic             | 28108 |     53200 | 52.83 |
|   LUT as Memory            |  8095 |     17400 | 46.52 |
|     LUT as Distributed RAM |   870 |           |       |
|     LUT as Shift Register  |  7225 |           |       |
| Slice Registers            | 36562 |    106400 | 34.36 |
|   Register as Flip Flop    | 36562 |    106400 | 34.36 |
|   Register as Latch        |     0 |    106400 |  0.00 |
| F7 Muxes                   |   376 |     26600 |  1.41 |
| F8 Muxes                   |   125 |     13300 |  0.93 |
+----------------------------+-------+-----------+-------+

3. Memory
---------

+-------------------+------+-----------+-------+
|     Site Type     | Used | Available | Util% |
+-------------------+------+-----------+-------+
| Block RAM Tile    |   97 |       140 | 69.28 |
|   RAMB36/FIFO*    |   90 |       140 | 64.28 |
|     RAMB36E1 only |   90 |           |       |
|   RAMB18          |   14 |       280 |  5.00 |
|     RAMB18E1 only |   14 |           |       |
+-------------------+------+-----------+-------+
* Note: Each Block RAM Tile only has one FIFO logic available and therefore can accommodate only one FIFO36E1 or one FIFO18E1. However, if a FIFO18E1 occupies a Block RAM Tile, that tile can still accommodate a RAMB18E1


4. DSP
------

+----------------+------+-----------+-------+
|    Site Type   | Used | Available | Util% |
+----------------+------+-----------+-------+
| DSPs           |  120 |       220 | 54.54 |
|   DSP48E1 only |  120 |           |       |
+----------------+------+-----------+-------+

Interfaces and Connectivity

• 10/100/1000 BASE-T Ethernet
• Stereo audio out, mono mic in
• Integrated GPS receiver
• Host USB support
• 9-axis IMU

Front Panel

RF A Group TX/RX LED: Indicates that data is streaming on the TX/RX channel on frontend side A RX2 LED: Indicates that data is streaming on the RX2 channel on frontend side A RF B Group TX/RX LED: Indicates that data is streaming on the TX/RX channel on frontend B RX2 LED: Indicates that data is streaming on the RX2 channel on frontend B PWR: Power switch with integrated status LED, for status description see below. SYNC: Input port for external PPS signal GPS: Connection for the GPS antenna AUDIO: Audio input / output The status LED in the power switch indicates the power and charge status. It's behavior is firmware version dependent. Version 1 (original E310) Off: Indicates device is off and not charging Solid Red: Indicates device is charging Solid Green: Indicates device is on Fast Blinking Red: Indicates an error code 1 - Low voltage error 2 - Regulator low voltage error 3 - FPGA power error 4 - DRAM power error 5 - 1.8V rail power error 6 - 3.3V rail power error 7 - Daughterboard / TX power error 9 - Temperature error Version 2 (E312 and upgraded E310) Off: Indicates device is off and not charging Slow Blinking Green: Indicates device is off and charging Fast Blinking Green: Indicates device is on and charging Solid Green: Indicates device is on (and not charging, if E312) Solid Orange: Indicates device is on and discharging Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge Fast Blinking Red: Indicates an error code 1 - Low voltage error 2 - Regulator low voltage error 3 - FPGA power error 4 - DRAM power error 5 - 1.8V rail power error 6 - 3.3V rail power error 7 - Daughterboard / TX power error 8 - Charger error 9 - Charger temperature error 10 - Battery low error 11 - Fuel Gauge temperature error 12 - Global (case) temperature error

Rear Panel

PWR: Locking connector (Kycon KLDHCX-0202-A-LT) for the USRP-E Series power supply 1G ETH: RJ45 port for Ethernet interfaces USB: USB 2.0 Port SERIAL: Micro USB connection for serial uart console

GPIO

Pin Mapping Pin 1: +3.3V Pin 2: Reserved Pin 3: Data[5] Pin 4: Reserved Pin 5: Data[4] Pin 6: Data[0] Pin 7: Data[3] Pin 8: Data[1] Pin 9: 0V Pin 10: Data[2]

• Please see the E3x0/X3x0 GPIO API for information on configuring and using the GPIO bus.

Audio

The E3x0 2.5 mm Audio Jack TRRS pins are assigned as follows: Tip=Mic, Ring1=Right, Ring2=Left, Sleeve=GND. The Left/Right audio outputs are compatible with typical low-impedance headphones (16 to 32 Ohms). The Microphone pin provides approximately 2 mA bias at 2.2 V when not suspended. A variety of pin configurations can be found on commonly available headsets, so an adapter may be required.

E312 Battery

The USRP E312 is equipped with an integrated 3.7V, 3200mAh lithium­ion battery cell. After unboxing the USRP E312 , plug in the power adapter to an AC power source and fully charge the battery. This process with take approximately 2 hours. Do not leave the USRP E312 unit plugged in for more than 24 hours.

The status LED in the power button indicates the power and charge status of the battery:

Off: Indicates device is off and not charging.

• Slow Blinking Green: Indicates device is off and charging.
• Fast Blinking Green: Indicates device is on and charging.
• Solid Green: Indicates device is on and not charging (Battery is finished charging).
• Solid Orange: Indicates device is on and discharging.
• Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.
• Fast Blinking Red: Indicates an error code:

1. Low Voltage Error
2. Regulator Low Voltage Error
3. FPGA Power Error
4. DRAM Power Error
5. 1.8V Power Rail Error
6. 3.3V Power Rail Error
7. Daughterboard / TX Power Error
8. Charger Error
9. Charger Temperature Error
10. Battery Low Error
11. Fuel Gauge Temperature Error
12. Global (Enclosure) Temperature Error

The battery life of the USRP E312 in idle mode is approximately 5 1/2 hours. The battery will enable the USRP E312 to operate for approximately 2 hours 20 minutes, when transmitting and receiving on both channels (2x2 MIMO), with maximum gain settings, at 5 GHz center frequency, and 1 MS/s sample rate. When the power button status LED is in the “Fast Blinking Orange” mode, plug the USRP E312 into an AC power source as soon as possible to recharge the battery.

If the power button status LED indicates a “Low Voltage Error” (codes 1, 2, 3, 4, 5, 6, 7) or a “Battery Low Error” (code 10), plug the USRP E312 into an AC power source as soon as possible to recharge the battery.

When the power button status LED indicates at “Temperature Error” or “Charger Error” (codes 8, 9, 11, or 12), power off the USRP E312 unit and allow it to cool down to room temperature. Then, plug in the USRP E312 to and AC power source and fully charge the battery.

If error codes persist after cooling down and/or recharging the USRP E312, please contact support@ettus.com.

You can purchase a replacement battery for the E312 at https://www.ettus.com/product/details/E312-battery.

An Application Note covering the replacement of the E312 battery can be found at USRP E312 Battery Replacement Instructions.

Certifications

RoHS

As of December 1st, 2010 all Ettus Research products are RoHS compliant unless otherwise noted. More information can be found at http://ettus.com/legal/rohs-information

Certificate of Volatility

E310

• Media:volatility USRP E310 r1.pdf

E312

• Media:USRP E31x CoV.pdf

SD Card Images

• http://files.ettus.com/e3xx_images/

This folder linked above contains SD card images and the SDK (OE cross-compiler build environment) for the USRP E310 and E312. There is a manifest file that shows which packages, and which versions, are included in the OE build within each folder.

The "alpha", "beta", "e3xx-release-001", "e310-release-002", "e3xx-release-3" folders contain older versions which are currently obsolete. We do not suggest that customers use these files. These versions are no longer supported. They are provided here for archival purposes only.

The current version is Release 4, which located in the "e3xx-release-4" folder. We recommend the customers use this version. It is fine if you are already successfully using an older version, but at some point it is recommended that you upgrade to this current version so that you benefit from the latest bug fixes, new features, stability improvements, and other enhancements.

The Release 4 image includes UHD 3.9.2 and GNU Radio 3.7.9, and also includes the corresponding FPGA image file.

Note: An 8 GB SD card is required for the Release 4 image.

The SD card image contains both the FPGA image and the OS for the E310/E312. The FPGA images are located in the file system of the E310/E312 in the /usr/local/share/uhd/images folder.

There are two SD card image files for each version of the image, which include the text "-dev" and "-demo" in the filename. The "-dev" flavor lacks some graphical packages, such as X Windows and QT, which the "-demo" flavor includes. The two flavors are otherwise functionally equivalent, although the "-demo" flavor takes some additional space on the SD card and some additional memory to run.

The Release 4 image comes in two varieties. The variety that you will need depends on the product number of your E310 or E312, which is printed on the bottom of the device.

For the E310, the product number will be 156333X-01L, where X is a letter from A to Z. For devices where X is A, B, C, D, the images under the "ettus-e3xx-sg1" folder should be used. For devices where X is E or later, the images under the "ettus-e3xx-sg3" folder should be used. You must use the appropriate image for your specific device. The incorrect image will not work, and will only boot as far as the U-Boot boot loader before stopping.

For the E312, the product number will be 140605X-01L, where X is a letter from A to Z. The images under the "ettus-e3xx-sg3" folder should be used for all E312 devices.

You can burn the image to an SD card using either the "dd" or the "bmaptool" tool. Instructions on how to use these tools are at the links below.

• http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card

• https://gnuradio.org/redmine/projects/gnuradio/wiki/Copy_an_image_file_to_the_SD_card

The SD image files have an *.xz extension, as they are compressed using the LZMA/LZMA2 compression algorithms. You can uncompress these files with tools such as 7-Zip and the XZ Utils. Please see the links below for further information.

7-Zip

• http://www.7-zip.org/
• https://en.wikipedia.org/wiki/7-Zip

XZ Utils

• http://tukaani.org/xz/
• https://en.wikipedia.org/wiki/XZ_Utils

The folder structure is listed below.

.
|-- alpha
|   |-- dizzy-test
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   |   |-- sdimage-gnuradio-demo.direct.xz
|   |   `-- sdimage-gnuradio-dev.direct.xz
|   |-- fido-rfnoc-test
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   |   |-- sdimage-gnuradio-demo.direct.xz
|   |   |-- sdimage-gnuradio-demo.direct.xz.md5
|   |   |-- sdimage-gnuradio-dev.direct.xz
|   |   `-- sdimage-gnuradio-dev.direct.xz.md5
|   |-- fido-test
|   |   |-- ettus-e3xx-sg1
|   |   |   |-- sdimage-gnuradio-demo.direct.xz
|   |   |   |-- sdimage-gnuradio-demo.direct.xz.md5
|   |   |   |-- sdimage-gnuradio-dev.direct.xz
|   |   |   `-- sdimage-gnuradio-dev.direct.xz.md5
|   |   |-- ettus-e3xx-sg3
|   |   |   |-- sdimage-gnuradio-demo.direct.xz
|   |   |   |-- sdimage-gnuradio-demo.direct.xz.md5
|   |   |   |-- sdimage-gnuradio-dev.direct.xz
|   |   |   `-- sdimage-gnuradio-dev.direct.xz.md5
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |   `-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   `-- fosphor-testing
|       |-- fosphor.direct.xz
|       |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.host.manifest
|       |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|       |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.target.manifest
|       |-- sdimage-gnuradio-demo.direct.xz
|       |-- sdimage-gnuradio-demo.direct.xz.md5
|       |-- sdimage-gnuradio-dev.direct.xz
|       `-- sdimage-gnuradio-dev.direct.xz.md5
|-- beta
|   |-- dizzy-test
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   |   |-- sdimage-gnuradio-demo.direct.xz
|   |   `-- sdimage-gnuradio-dev.direct.xz
|   `-- dizzy-test-wifi
|       `-- sdimage-gnuradio-dev.direct.xz
|-- e310-release-002
|   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   |-- sdimage-gnuradio-demo.direct.xz
|   |-- sdimage-gnuradio-demo.direct.xz.md5sum
|   |-- sdimage-gnuradio-dev.direct.xz
|   `-- sdimage-gnuradio-dev.direct.xz.md5sum
|-- e3xx-release-001
|   |-- e300-gnuradio-dev-image-release1.bz
|   `-- nodistro-eglibc-x86_64-gnuradio-dev-image-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|-- e3xx-release-3
|   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
|   |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
|   |-- sdimage-gnuradio-demo.direct.xz
|   `-- sdimage-gnuradio-dev.direct.xz
`-- e3xx-release-4
    |-- ettus-e3xx-sg1
    |   |-- sdimage-gnuradio-demo.direct.xz
    |   |-- sdimage-gnuradio-demo.direct.xz.md5
    |   |-- sdimage-gnuradio-dev.direct.xz
    |   `-- sdimage-gnuradio-dev.direct.xz.md5
    |-- ettus-e3xx-sg3
    |   |-- sdimage-gnuradio-demo.direct.xz
    |   |-- sdimage-gnuradio-demo.direct.xz.md5
    |   |-- sdimage-gnuradio-dev.direct.xz
    |   `-- sdimage-gnuradio-dev.direct.xz.md5
    |-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
    `-- oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh

Security Notes

The OpenEmbedded project reported a security vulnerability for OE-Core (http://lists.openembedded.org/pipermail/openembedded-architecture/2017-June/000638.html). If you are an USRP E-Series user that is building binary ipkgs which you then distribute to your customers, you may be affected by this issue. No other workflows are impacted.

The vulnerability is documented as CVE-2017-9731 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9731). The specific issue is that information in the SRC_URI for software repositories used by OE recipes is "leaked" by binary ipkgs. For example, if you are using the E-Series OE-generated SDK to build binary ipkgs, and the URI you use for your source code repository contains sensitive information (e.g., https://github.com/company-name/secret-project-name, or local-server.internal.com?USER=admin&PASSWORD=password), then that information will be leaked in the Source: field of the ipkg.

The OpenEmbedded team has merged a fix for this into OE-Core master, and backported the change to previous versions of OpenEmbedded. Generally, including sensitive information in the SRC_URIs is not a good idea, and we highly recommend users avoid doing this in their build process. Some recommendations provided on the OpenEmbedded discussion list:

• Use non-confidential path names (i.e., don’t include confidential customer or project names in build paths).
• Change or manage the host name of your build system so that it is non-confidential, like build-1 instead of secret-product.my-company.internal.com.
• Use a "build user" who does not have network credentials to access sensitive machines during the build process.

If you have any questions about this, or need help determining if this issue affects you, please let us know by contacting support@ettus.com.

Additional Resources

• COMPASS HEADING USING MAGNETOMETERS

Downloads

FPGA Images

FPGA Images Read Me

FPGA Resources

UHD Stable Binaries

UHD Source Code on Github