Most of the updates so far were related to hardware design progress, but hardware is nothing without software, so it’s time for a software update. Sergey has been putting massive amount of work into making sure XTRX software is high performance, flexible and stable. And making sure all most popular applications are supported.

General architecture notes

• XTRX software is implemented in a modular way to support a variety of interfaces between an XTRX and a PC. Primary interface we’re focusing on right now is PCIe.
• All RF parameters tuning and calibration is done on a host. Thanks to PCIe bus low latency this doesn’t affect performance while making it much easier/faster to develop.

Max/min transfer speed

Numbers bellow are not theoretical and are based on real tests. A test is assumed correct if it sustains the speed for at least 5 min without any underruns/overruns. Tests are run under RT priority.

Current streaming limitations

• RX: Minimal samplerate is ~400 kSps, but we can reduce it to ~100 kSps using 4x decimation on the host.
• TX: Minimal samplerate is 2.5 MSps by the FPGA MMCM spec, but for some chips we can get it down to 2.0-2.1 MSps. With the host interpolation we can get it further down to ~500-625 kSps.
• Both RX and TX single DMA buffer is limited to 32768 bytes. This requires strict timing and sample rates more 25 MSPS have bad performance when an application is not run under the realtime priority (a lot of underruns / overruns).

Platform support

C/NT – Compiles, but hasn’t been tested
WIP – Work in progress, no actual test are done

Applications support

Native XTRX API support

Other applications which have been tested with non-native API

• GnuRadio (SoapySDR) — Ok
• gqrx (gr-osmosdr) — Ok
• LTE_fdd_dl_scan from OpenLTE (gr-osmosdr) — not working! (std::bad_alloc)

Applications which haven’t been tested yet (wait list)

• OpenBTS-UMTS (needs adoption)
• LTE_fdd_enb from OpenLTE (needs adoption)

Wire streaming types

• Primary/default streaming type is 16-bit MIMO/SISO to accommodate for 12-bit ADC/DAC resolution, possible decimation gain and fit into an integer number of bytes.
• We expect that some application won’t need full 12 bits of the dynamic range and can use 8-bit streaming mode to save on processing power and bus bandwidth. This mode is supported for both SISO and MIMO modes, but is currently implemented only in the receive direction.
• For receive applications which care about achieving maximum bandwidth without loosing dynamic range we’re working on 12-bit transfer mode for MIMO. Non-integer number of bytes per sample makes it significantly harder and more CPU intensive, so we plan to support it only for the MIMO receive mode where we hit bus bandwidth limits with 16-bit samples.