All,
we've just tagged and bagged our 3.10.0.0 release (tag:
https://github.com/EttusResearch/uhd/tree/release_003_010_000_000). As mentioned, this release comes with a lot of changes to our X-series devices, as we are pulling in the RFNoC infrastructure into the regular release of UHD. (Side note: We will release a 3.9.5 version of UHD very soon).
This release also contains the drivers for the TwinRX daughterboard.
Going forward, this new architecture will be used for the X300/X310, the E310 (and any variant thereof) and any other future product. This does mean that there will be some changes in behaviour, and there may be some adaptation required for your software to work. All in all, we tried hard to keep behaviour and APIs backward compatible. In particular, all multi_usrp calls are designed to behave as before.
The biggest architectural changes in a nutshell:
== Block separation of components ==
The Tx path uses the following blocks:
DRAM => DUC => Radio
The Rx path uses these blocks:
Radio => DDC
Any of these blocks can be skipped by using the 'skip_ddc', 'skip_duc',
or 'skip_dram' device args.
One big difference is the timing of timed receives and transmits. Prior
to this merge, a timed receive or send was when samples were read from
or written to the DSP chain. Now, the time is when the samples are read
to or read from the ADC/DAC.
Also, the DRAM FIFO adds latency to the Tx path, on the order of tens of microseconds.
== Raw uhd::device API changes ==
Some of the properties have different paths now. uhd_usrp_probe --tree
will print a property tree.
In general, multi_usrp based APIs will work as before, but software
working directly with uhd::device() may not.
In particular, uhd::device::get_rx_stream() and
uhd::device::get_tx_stream() may not do what you're expecting it to do.
However, the same calls on multi_usrp are unchanged!
== usrp3_rfnoc directory ==
We currently have some minor conflicts between usrp3 devices that use
RFNoC, and those devices that don't (i.e., B2xx, N230). To eliminate
those conflicts, we have temporarily split up those devices into usrp3
and usrp3_rfnoc (in the FPGA repository). We'll be resolving those
conflicts in the near future and re-consolidate those directories.
== Known issues ==
There are a couple of known issues with this release:
- On Tx, there will be a couple of underruns (their number depends on
the rate) until the DRAM FIFO stabilizes. This won't happen when the tx
stream is timed a little bit into the future.
- Rate changes during streaming are currently unsupported. This goes for
both DDC and DUC.
We will provide a migration guide from 3.9 to 3.10 very soon, and there will be a separate announcement for that. Binary installers are currently building and uploading and should be available before next week.
Cheers,
Martin
PS: Changelog:
## 003.010.000.000
- Changed version string to quadruplets (Major.API.ABI.Patch)
- Minimum dependencies bumped for gcc, Boost, CMake, clang and Python.
- TwinRX: Added support. Includes LO API for multi_usrp.
- N230: Added support
- Added expert framework
- X300: Completely restructured to use RFNoC
- X300: FPGA builds include git hash, dual 10GigE receive is now supported
(allows 2x200 Msps receive over 2x10GigE connections), DMA FIFO (over DRAM)
now part of builds, added Aurora support
- WBX: Fixed bug that prevented LO locking with 50 MHz ref clock
- pkg-config: Added boost_system
- Utils: uhd_usrp_probe can query sensors, query_gpsdo_sensors: minor fixes,
and cleanup
- Examples: Bugfixes in tx_waveforms, benchmark_rate measures timeouts,
- USB subsystem: Cleanups and minor bugfixes
- Added devtest infrastructure
- Converters: Added s8 and s16 data types
- Added more aggressive optimization strategies for FPGA builds
- Xilinx IP tool upgrade scripts cleaned up