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