UHD Announcement - July 19th 2011

GNU Radio
#1

Hello list,

I have pulled work from the next branch into the master. If you are
working from the code in the master branch, you will need to update your
FPGA images. In the case of E100 users, this will also require a kernel
uImage and kernel modules update.

FPGA and firmware images for the master branch can be found here.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads

Some changes are summarized below, for a detailed list see:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/ChangeLog

– USRP2 / N-series changes

The mimo_mode device address argument was removed. It was redundant, and
there is now one proper way to set the clock and time source, which is
to set the clock configuration:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#using-the-mimo-cable

The gr-uhd blocks in gnuradio now provide per motherboard reference
source configurations, and the MIMO cable has been added as a possible
reference source option. If you have a source and sink block referring
to the same device, it is only necessary to set the reference source in
one of the blocks. See the docs in the block properties windows.

We have made significant gains in windows transmit performance. 1) The
UDP transport now uses the async (aka overlapped) IO to submit UDP
packets. And 2) It is imperative that a magical registry value be set
allow MTU sized datagrams to pass efficiently through the kernel. Docs
here:
http://www.ettus.com/uhd_docs/manual/html/transport.html#windows-specific-notes

– USRP E100 changes

There is no longer any need for clock recovery and the pass-through
image after programming in bad clock rates. The UHD can bring up the
clock at every run regardless of the previous settings.

Async messages are no longer muxed into the receive path. This frees up
some overhead and thread context switching in UHD’s receive fast-path.

E100 now has dual RX DSP support just like USRP2 and N-Series.

For those of you compiling UHD native on the embedded processor, you
will be pleased to find out that UHD links much-much faster.

We have changed the name of the fpga image file that the E100 code
searches for. This is to prevent the older images from being
automatically loaded. Please do not rename an older image to force it
to load. Instead, please get new images from the downloads page.

For now, please find compatible kernel images for the master branch
here:
http://www.ettus.com/downloads/uhd_releases/master_images/e100_kernel_images/

See updating kernel modules:
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/BootFiles#Updating-kernel-modules
And updating the uImage:
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/BootFiles#Updating-Boot-Files

– Overall changes

For USRP2, N2XX, and E100, the receive and transmit DSPs have been
reworked to include clipping and rounding, IQ imbalance compensation,
and DC offset compensation. While the fpga work is implemented, the
hooks for compensation are not yet in the host code. Expect this soon.

The “glue” code for the various USRP motherboards has been re-worked and
simplified. Duplicated code has been abstracted out. All of the various
things on a motherboard are registered into a property tree, where each
element in the tree has registered callbacks for set and get. The
multi-usrp implementation sits on top of this properties layer.
For the curious, run uhd_usrp_probe --tree

The common packet handler code has been improved. For receive, users can
expect, timestamps on packet fragments, and inline overflow messages for
USRP2/N-Series. And for transmit, timestamps on individual packets when
UHD fragments a buffer that was decorated with a timestamp.

#2

Hi Josh,

Please could you add TVRX rev1 support to your UHD things to do list.

I’d like to update my scanner apps to be universal before I release
them.

Thanks,

Mike
M0MIK

#3

Hi Josh,

I am a newbie and have some questions regarding the UHD announcement.

uImage and kernel modules update.

FPGA and firmware images for the master branch can be found here.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads

Some changes are summarized below, for a detailed list see:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/ChangeLog

I understand that the FPGA and firmware images have to be updated, i.e.
the newest images downloaded and “flashed” on the SD card in case of
USRP2.
However, since the source code is new too, should I rebuild and
reinstall the UHD from the new source?

Thanks in advance.

Nemanja Trecakov

#4

I understand that the FPGA and firmware images have to be updated, i.e. the
newest images downloaded and “flashed” on the SD card in case of USRP2.
However, since the source code is new too, should I rebuild and reinstall the
UHD from the new source?

The host code and images must match. If you want to use the latest
images, you have to download and install the latest UHD host code as
well. http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Source-code

Or you can wait for binary installer packages (for the host code).

Or, if you are happy with everything as it is. Dont update at all :slight_smile:

-josh

#5

On Sat, 2011-07-23 at 18:55 +0100, Nemanja Trecakov wrote:

The host code and images must match. If you want to use the latest
images, you have to download and install the latest UHD host code as
well.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Source-code

  1. Why must code and images match? If FPGA image is newer than the UHD
    code one have installed, according to my logic only things that are
    different would not work.

Because we tend to change all sorts of stuff under the hood between
releases. We try to keep things sane by using a FPGA “compatibility
number”, and use that compatibility number to ensure you’re using
compatible host code and FPGA images.

  1. I want to adjust the FPGA image slightly. I want to write some
    extra Verilog code and build it myself with Xilinx. However, since I
    change the image on the FPGA, and the installed UHD code has to match
    to the image, how can this work?

You can do whatever you want to the FPGA image, we’re just saying you
should start with corresponding FPGA and UHD host code versions.

–n

#6

There are two more things I am not clear with.

I understand that the FPGA and firmware images have to be updated, i.e. the
newest images downloaded and “flashed” on the SD card in case of USRP2.

However, since the source code is new too, should I rebuild and reinstall the
UHD from the new source?

The host code and images must match. If you want to use the latest
images, you have to download and install the latest UHD host code as
well. http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Source-code

  1. Why must code and images match? If FPGA image is newer than the UHD
    code one have installed, according to my logic only things that are
    different would not work.

  2. I want to adjust the FPGA image slightly. I want to write some extra
    Verilog code and build it myself with Xilinx. However, since I change
    the image on the FPGA, and the installed UHD code has to match to the
    image, how can this work?

Thank you in advance.

Nemanja