XTRX is the smallest easily embeddable software-defined radio (SDR). It is both affordable and high-performance. XTRX is designed to enable the next generation of wireless solutions, from prototype to production.
LTE modems and GPS receivers are commodity parts easily bought in any electronic components store and added to your project. On the other hand, everyone designing an SDR-based product had to spend precious time and money on a custom design — until XTRX.
Don’t waste your time designing yet another SDR. Embedding XTRX into your product is easy, freeing you up to focus on what your customers really need.
XTRX is the best platform available today for building SDR-based products. We designed it with demanding embedded applications in mind:
XTRX isn’t for everyone. We expect most people interested in XTRX to already have some experience with SDRs. If you’ve never used an SDR before, XTRX might be a bit overwhelming for you. XTRX might be right for you if you have:
If this describes you, or you are looking for a better SDR, fear not and read on!
XTRX revision 3 (top)
Here are just a few of the things you could use XTRX for:
XTRX boards can share the same sampling and reference clocks, which makes it easy to build a massive multiple input, multiple output (MIMO) system.
With synchronized clocks, multiple XTRX boards can collectively monitor very large chunks of the RF spectrum. For example, eight synchronized XTRX boards could monitor nearly 1 GHz of bandwidth.
The combination of XTRX’s accurate, stable clock, on-board GPSDO, and low-latency PCIe bus makes LTE possible out of the box.
When inserted into a Mini PCIe slot reserved for cellular modems, XTRX appears as a USB SIM card reader.
Power consumption, weight, size, and performance all matter when it comes to drones and embedded systems. XTRX’s Mini PCIe form factor and GPIO enable you to interface with a wide variety of single board computers, sensors, and actuators.
You can use the FPGA to accelerate your real-time signal processing; the high-speed, low-latency PCIe bus allows shuttling data back and forth between the host CPU and XTRX’s FPGA.
XTRX revision 3 (bottom)
We’re publishig all XTRX-related code under the
xtrx-sdr GitHub organization. The most important repositories to note:
|XTRX CS||XTRX Pro||USRP B2x0||bladeRF||LimeSDR||LimeSDR Mini||RTL-SDR|
|Tuning range||30 MHz - 3.7 GHz||30 MHz - 3.7 GHz||70 MHz - 6 GHz||300 MHz - 3.8 GHz||30 MHz - 3.8 GHz||10 MHz - 3.5 GHz||22 MHz - 2.2 GHz|
|Duplex||Full MIMO||Full MIMO||Full MIMO||Full SISO||Full MIMO||Full SISO||RX only|
|Max sampling rate||120 MSPS SISO / 90 MSPS MIMO||120 MSPS SISO / 90 MSPS MIMO||61.44 MSPS||40 MSPS||61.44 MSPS||30.72 MSPS||3.2 MSPS|
|Max RF bandwidth||120 MHz||120 MHz||56 MHz||28 MHz||61.44 MHz||30.72 MHz||3.2 Mhz|
|Channels||2||2||1 (2 for B210)||1||2||1||1|
|Transmit power||0 to 10dBm (depending on frequency)||0 to 10dBm (depending on frequency)||10dBm+||6dBm||0 to 10dBm (depending on frequency)||0 to 10dBm (depending on frequency)||none|
|RF chipset||LMS7002M||LMS7002M||AD9364 or AD9361||LMS6002M||LMS7002M||LMS7002M||RTL2832U|
|FPGA||Xilinx Artix7 35T||Xilinx Artix7 50T||Xilinx Spartan 6 XC6SLX75||Altera 40KLE/115KLE Cyclone 4||Altera 40KLE Cyclone 4||Altera MAX 10||none|
|Industrial temperature range||no||yes||no||Optional||no||no||no|
|Frequency stability||±0.5 ppm w/o GPS lock, <±0.01 ppm w/ GPS lock||±0.1 ppm w/o GPS lock, <±0.01 ppm w/ GPS lock||±2 ppm||±1 ppm||±2.5 ppm||±2.5 ppm||±25 ppm|
|GPS synchronization||on board||on board||Addon (+$636)||no||no||no||no|
|Bus/interface||PCIe x2, USB 3 adapter, and more (FPGA based)||PCIe x2, USB 3 adapter, and more (FPGA based)||USB 3||USB 3||USB 3||USB 3||USB 2|
|Raw bus bandwidth||10 Gbit/s||10 Gbit/s||5 Gbit/s||5 Gbit/s||5 Gbit/s||5 Gbit/s||480 Mbit/s|
|Dimensions||30 × 51 mm||30 × 51 mm||97 x 155 mm||87 x 131 mm||100 x 60 mm||69 x 31.4 mm||40 x 60 mm|
|Extra features||GPIO, GPS, SIM card interface||GPIO, GPS, SIM card interface||GPIO||GPIO||GPIO||GPIO||none|
|Multiple boards synchronization||Sample clock and timestamps||Sample clock and timestamps||Sample clock and timestamps||Sample clock and timestamps||Sample clock||Sample clock||no|
|Price||$260||$599||$686 - $1,119 + $636 (for GPSDO)||$415||$299||$139||$10+|
|Price per channel||$130||$245||$560 - $715 + $636 (for GPSDO)||$415||$150||$139||$10+|
Conceptual plot of XTRX's market position
Answering the simply stated question, "how much bandwidth can I capture with XTRX," is surprisingly difficult. Without going into too much detail, the two most important parameters which affect the answer are the RF frontend filter width and the ADC/DAC sampling rate.
In a quadrature sampling architecture, the ADC/DAC sampling rate equals the maximum theoretical RF bandwidth. So, if your XTRX is sampling at 90 million samples per second (MSPS) then your maximum theoretical RF bandwidth is 90 MHz. If your XTRX is sampling at 10 MSPS, the maximum theoretical RF bandwidth it can handle is 10 MHz. On the receive side, all frequency components of the signal outside of this sampled RF bandwidth will "alias," thus distorting the sampled digital signal.
To avoid aliasing, XTRX has built-in analog low-pass filters (LPFs) ranging from 1.4 MHz to 130 MHz (see the LMS7002M datasheet for the details). To capture the largest amount of radio spectrum, you should select the largest LPF filter which is still less than about ~80% of your sampling rate, or disable the built-in filter and use an external bandpass analog filter. For example, for 90 MSPS you would use 70 MHz, which would be how much of the RF bandwidth you actually receive.
Another important thing to keep in mind is that both channels of an XTRX unit can only be tuned to a single frequency - though independently for receive and transmit. For example, if you tune an XTRX to transmit at 1800 MHz and receive at 1900 MHz, both Tx channels will transmit at 1800 MHz, and both Rx channels will receive at 1900 MHz. This is an inherent limitation of the LMS7002M RF chipset we’re using since it has only one PLL shared by both transmit channels and one PLL shared by both receive channels.
As explained above, the sampling rate directly affects how much RF bandwidth you can work with. So, what limits the maximum sampling rate you can achieve with your XTRX?
Putting aside implementation-specific limitations, there are three parts of the PCIe standard which affect maximum data throughput:
Given that XTRX supports PCIe 1.0 and PCIe 2.0, and can work with x1 or x2 PCIe lanes, the maximum data throughput depends on the exact PCIe configuration, as shown in the table below.
|PCIe configuration||Clock speed||Raw data speed||128b TLP throughput||Large data blocks throughput|
|PCIe 1.0 x1||2.5 GT/s||2.0 Gbps||1,760 Mbps||1,750 Mbps|
|PCIe 2.0 x1 or PCIe 1.0 x2||5.0 GT/s||4.0 Gbps||3,520 Mbps||3,500 Mbps|
|PCIe 2.0 x2||10.0 GT/s||8.0 Gbps||7,040 Mbps||7,000 Mbps|
XTRX has 12 bits of ADC/DAC resolution, so the samples can be transferred over PCIe in three different formats: as-is (12 bits), cut down to 8 bits, or expanded to 16 bits. Each of these methods has its own advantages and disadvantages, as shown in the table below.
|Bits per sample||Maintains precision?||Easy to process on the CPU?||Bandwidth efficient?|
Since we need to transfer two samples (I and Q) for each of either one (SISO) or two (MIMO) channels, we arrive at the following table of maximum sampling rates we can (theoretically) transfer over different PCIe bus configurations. Green cells indicate combinations of sample rate and PCIe bus configuration where the sampling rate is not limited by the PCIe bus but is rather limited by the XTRX itself.
|Mode||IQ x Ch x bits||Total bits/sample||PCIe 1.0 x1 (max 1,750 Mbps)||PCIe 2.0 x1 or PCIe 1.0 x2 (max 3,500 Mbps)||PCIe 2.0 x2 (max 7,000 Mbps)|
|8-bit SISO||2 x 1 x 8||16 bits||109 Msps||219 Msps||438 Msps|
|12-bit SISO||2 x 1 x 12||24 bits||73 Msps||146 Msps||292 Msps|
|16-bit SISO||2 x 1 x 16||32 bits||55 Msps||109 Msps||219 Msps|
|8-bit MIMO||2 x 2 x 8||32 bits||55 Msps||109 Msps||219 Msps|
|12-bit MIMO||2 x 2 x 12||48 bits||36 Msps||73 Msps||146 Msps|
|16-bit MIMO||2 x 2 x 16||64 bits||27 Msps||55 Msps||109 Msps|
We chose the Mini PCIe form factor for XTRX because it’s the best option for a high-speed, low-latency bus that is both physically compact and widely used. In other words, using Mini PCIe results in a device that is both high-performance and easily embeddable.
While it’s true that many laptops are moving away from Mini PCIe slots and toward M.2 slots, Mini PCIe is still the most popular PCIe form factor among standards-based, professional single-board computers (SBCs) and embedded systems. We will likely release an M.2 version of XTRX after the Mini PCIe version has been delivered.
We also considered USB 3 and Thunderbolt 3, but the former is high-latency and the latter is not yet very popular. However, should you want to use USB 3 or Thunderbolt 3, there are adapter boards for both.
This PCIe card securely holds an XTRX board so it can be used in a standard PCIe x4 slot. Unlike standard PCIe adapter that only have one PCIe lane, the PCIe x2 Lite Adapter has two lanes. This adapter achieves the full 10 Gbit/s raw bus bandwidth and can be plugged into x4/x8/x16 PCIe slots, though it won’t fit into an x1 slot unless the slot has an open end. A six-pin JTAG connector on the edge is compatible with a JTAG-HS2 cable, so you can easily program and debug the FPGA.
The XTRX hardware itself is proprietary, though the hardware accessories we designed for it (e.g., the USB 3 and PCIe adapters) are open hardware.
XTRX’s main FPGA code is open source and without a viral license, so not only can you modify the code, but you can also develop your own proprietary FPGA blocks. The FPGA is approximately 30% utilized. We will share a detailed utilization report in a future update. You can upload your own firmware with our USB 3 adapter board or with a JTAG cable and our PCIe adapter board. If you are good at soldering, you can even solder JTAG directly to the XTRX board — that’s how we programmed our first samples.
The host-side software and drivers are open source.
We developed our low-level API to maximize performance (i.e., we’re using a zero-copy interface). We provide a SoapySDR interface to our low-level library, so you can quickly start developing if you’re already familiar with SoapySDR. For example, using SoapySDR plugins, you can easily get UHD support. Of course, there’s always the option to interface directly to the low-level API if you don’t want to use SoapySDR or need to eek out the most bandwidth and lowest latency.
The USB 3 adapter relies on a
libusb wrapper, so it will work on
almost every platform
libusb works on. In contrast, PCIe
communication requires a kernel-level driver for direct memory access
(DMA) and interrupt handling. Our host library talks to a device
provided by the kernel driver. Currently, we have an implementation
for Linux only. A Windows driver is in early stages of development and
will be released later. We don’t plan to develop PCIe drivers for
other platforms right away. Our Linux kernel driver exposes TTY
devices for GPS, UART, and SIM card UART, so you can use existing
xgps. The adapter also provides a
kernel pulse per second (LinuxPPS) interface for handling the lowest
levels of jitter in NTP-like applications.
Developing a cutting-edge product requires more than just snapping together a few ready-to-use pieces. Over the last year and a half, we’ve been through three major revisions and many minor revisions of XTRX to find the optimal ratio of price, performance, and power consumption. In order to deliver the best product possible at an incredible price, we took deep dives into many thorny issues. For example, we wrote our own PCIe DMA implementation so as to maximize bus throughput while staying within the constraints of the smallest Artix 7 FPGA.
We did this work so you wouldn’t have to. With XTRX, you can incorporate an SDR into your own designs without first becoming an expert in the rarefied art of SDR design.
At Fairwaves, we’re familiar with the problem of not being able to buy an off-the-shelf SDR. Way back in 2008, we had an idea to build an SDR-based GSM base station that could be deployed in real networks. We got a USRP1 and tried to run OpenBTS, only to struggle for days before realizing cellular standards require 0.05 to 0.1 ppm clock accuracy but the USRP1 has only 20 ppm clock accuracy. We needed a better clock, so we created ClockTamer, an open source, highly accurate, programmable clock source.
Soon after, we found the USB connection used by USRP1 was neither reliable nor easily embedded in a compact system. So, we created UmTRX, an industrial-grade SDR that became the basis of our UmSITE product, a rugged, network-in-a-box GSM base station that has been deployed around the world and has withstood everything from Saharan summers to Siberian winters.
In 2016, we started looking into 4G (a.k.a. LTE) and 5G wireless systems and realized we needed something better. Today, we’re launching XTRX to eliminate size, performance, and cost barriers to making the next generation of wireless solutions.