UHD Announcement - July 6th 2010

GNU Radio
1

Hello all,

MIMO capabilities have just been added to the UHD. With N gigE ports and
N USRP2s, one can perform synchronous aligned receives.

A usrp_mimo class has been added to the UHD for construction of a mimo
enabled device configuration. And I have added the corresponding
gnuradio blocks: uhd_mimo_source and uhd_mimo_sink that call into this
interface.
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1mimo__usrp.html

See the usrp2 application notes on device parameters for the
configuration:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#addressing-the-device

I should note that the aligned send for the mimo sink gnuradio block is
not yet fully working, but may be used to test out the interface.

To use the new blocks you will need the most recent UHD master,
gnuradio/jblum.git uhd branch, and SD card images. See links below:

I have just pushed new host code to the uhd repo, posted new images, and
pushed new uhd gnuradio blocks. The gnuradio blocks will be hosted on my
jblum.git uhd branch until they are merged into the gnuradio.git next
branch.

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#UHD-Firmware-and-FPGA-Images

http://gnuradio.org/cgit/jblum.git/log/?h=uhd

For those of you calling directly into the UHD c++ API and not through
gnuradio. I have changed the send and recv calls to reflect the mimo
work. The asio buffer was replaced with two parameters: a vector of
void-star pointers and a length in number of samples per buffer, for
both send and recv. A convenience wrapper was added to pass in a single
pointer and number of samples for the non-mimo case. The original
interface with asio buffers is still there, just deprecated.

Feedback is always welcome!

Thank you,
-Josh

2

Excellent - I look forward to trying this out. In particular I’m very
happy to see the get_time_now() functionality, which it looks like
made it into the simple_usrp class as well. That is a very nice
addition since it enables exactly the sort of thing you’ve already
done with set_time_unknown_pps: namely dealing with the possibility
the host PC doesn’t have direct access to the PPS signal. So - thank
you, that can be very useful.

On Tue, Jul 6, 2010 at 9:45 PM, Josh B. [email protected] wrote:

See the usrp2 application notes on device parameters for the configuration:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#addressing-the-device

I should note that the aligned send for the mimo sink gnuradio block is not
yet fully working, but may be used to test out the interface.

To use the new blocks you will need the most recent UHD master,
gnuradio/jblum.git uhd branch, and SD card images. See links below:

Feedback is always welcome!

Thank you,
-Josh

–
Doug G.
[email protected]

3

Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and
have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:

1- I am using a PC with four Ethernet ports. I burned the firmware and
the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses
from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also
from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the
USRP2’s,
and all them can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)

3- I used a MIMO source with 4 outputs and the following settings:
freq: 2414000000, 2414000000, 2414000000, 2414000000
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was
prompted
to use this value)
Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the
flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::bad_lexical_cast

’
what(): bad lexical cast: source type value could not be interpreted
as
target.

I have Boost 1.38.0 installed and I did use this command for
configuration:
./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair

View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29105404.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

If I use the UHD driver directly (i.e. not using gnuradio framework)
should I call “mimo_usrp::make” with argument “addr=192.168.10.11
192.168.20.11 192.168.30.11 192.168.40.11, addr=192.168.10.11
192.168.20.11 192.168.30.11 192.168.40.11” to achieve the same or how
should the string be formatted ?

BR/
Per

From: discuss-gnuradio-bounces+perz=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+perz=removed_email_address@domain.invalid] on behalf of Zohair
[[email protected]]
Sent: Thursday, July 08, 2010 12:16 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and
have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:

1- I am using a PC with four Ethernet ports. I burned the firmware and
the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses
from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also
from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the
USRP2’s,
and all them can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)

3- I used a MIMO source with 4 outputs and the following settings:
freq: 2414000000, 2414000000, 2414000000, 2414000000
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was
prompted
to use this value)
Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the
flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::bad_lexical_cast

’
what(): bad lexical cast: source type value could not be interpreted
as
target.

I have Boost 1.38.0 installed and I did use this command for
configuration:
./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair

View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29105404.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

Regarding my post below, I have traced back the error and came to a
result
that the error is occurring in device.cpp file. This line in the catch
block
throws an error:
device::sptr dev = maker(dev_addr);
I beleive there is something wrong in : Arg: addr=192.168.10.11
192.168.20.11 192.168.30.11 192.168.40.11, recv_buff_size=50e6 50e6 50e6
50e6

Does the block support multiple buffer resizing? or maybe I’m not
addressing the devices properly.

Looking foward to your reply.

Zohair

Zohair wrote:

from the same subnetwork above)
to use this value)
target.

I have Boost 1.38.0 installed and I did use this command for
configuration: ./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair

–
View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29106668.html
Sent from the GnuRadio mailing list archive at Nabble.com.

6

Zohair,

The goal is to setup your networking on your such that all devices are
accessible (ie your computer knows how to route udp/ip packets to the
correct device based on ip address). The easiest way to use use a
different subnet per ethernet card. 192.168.X.Y and burn each usrp with
the corresponding address 192.168.X.Z. If you play around with subnet
masks you can get other configurations.

3- I used a MIMO source with 4 outputs and the following settings:
freq: 2414000000, 2414000000, 2414000000, 2414000000
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted
to use this value)

What you probably saw was a warning that the system could not
automatically request a large enough buffer.

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#os-specific-notes

Also, you can only specify one buffer size across all boards. If you
think about it the setup should be uniform per board.

target.

it cant cast a “50e6 50e6 50e6 50e6” to a double. I need to catch these
error and throw meaning full exceptions. :slight_smile:

Thanks for asking, it seems that I need to add more to the docs and
polish. -Josh

7

The make takes a device_addr_t which means you may pass in the formatted
string or a device_addr_t dictionary object:

mimo_usrp::make(“addr=192.168.10.11 192.168.20.11”)

or

device_addr_t dev_addr;
dev_addr[“addr”] = “192.168.10.11 192.168.20.11”
mimo_usrp::make(dev_addr);

-Josh