discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] [UHD] Major update to UHD master branch


From: Martin Braun
Subject: [Discuss-gnuradio] [UHD] Major update to UHD master branch
Date: Tue, 9 Aug 2016 18:02:28 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Dear UHD users,

master branch on UHD repositories just received a major update, in
anticipation of the 3.10.0.0 release. This affects X300 and X310 users.

In a nutshell, we are starting to merge back RFNoC components into the
master branch and use them for mainline UHD. You will notice that the
RFNoC APIs are not exposed when using the master branch, but under the
hood, we will be using RFNoC and make no distinction between RFNoC and
vanilla UHD.

This comes with some major changes in device behaviour. Most
importantly, Radios, DDCs, DUCs, and DRAM are split up into separate
blocks of their own. We statically connect them up to form an RFNoC
graph internally, but when using multi_usrp, it doesn't make much of a
difference API-wise (so your software will continue to function, with
some minor exceptions).

We are working on a migration guide for going from 3.9.* to 3.10.*.
Until then, here's the biggest changes:

== 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.


== 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 on this branch:

- 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.
- The DRAM FIFO adds a lot of latency to the Tx path, on the order of
tens of microseconds.
- Rate changes during streaming are currently unsupported. This goes for
both DDC and DUC.
- On the X300, we are experiencing trouble making timing on the FPGA
build (this is not the case for the X310). We're working on fixing that.




In the long run, this is how UHD will look like. However, in the short
term, I would recommend users not to upgrade to current master (or even
3.10) if you're currently running important applications, and do not
wish to risk any issues.

Please let us know if you have any problems!

Cheers,
Martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]