UHD Announcement - April 23rd 2010

XCVR2450 and RFX series boards are now supported in the UHD.

Here is the link to the wiki and manual that I have been working on:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

The microblaze firmware has changed since the previous announcement.
Download the most recent builds here:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/files

Feedback and testing is appreciated!

Thank you,
-Josh

On Fri, Apr 23, 2010 at 7:31 PM, Josh B. [email protected] wrote:

Thank you,
-Josh

Josh,
Trying it out on one of my USRP2’s here, with an RFX2400. The build
went well: libuhd, firmware and fpga images all built fine. And
building the gr-uhd branch of gnuradio had no problems either,
although I haven’t gotten to the point of being able to use it yet: I
seem to be having trouble with the USRP2 registering as being found.
For example, if I run uhd_find_devices, I get:

$ uhd_find_devices
No UHD Devices Found

Opening up wireshark, I can see that the host and USRP2 are
communicating over UDP (with the correct IP addresses, it seems to me
at least):

43 14:56:36.672264 192.168.10.1 192.168.10.255 UDP Source port: 40243 Destination port: 49152
44 14:56:36.672336 192.168.10.2 192.168.10.1 UDP Source port: 49152 Destination port: 40243

Host has the IP address 192.168.10.1 on the interface connected to the
USRP2, and the USRP2 appears to have the default 192.168.10.2. I can
send the contents of the UDP packets if you’d like to see them.
Taking a quick look at the usrp2::find function, it looks like it’s
supposed to be waiting in a while loop until a timeout occurs, is it
possible the timeout is happening before the response came from the
USRP2? Or have I perhaps made some simple mistake?
Thanks,
Doug


Doug G.
[email protected]

On Mon, Apr 26, 2010 at 3:13 PM, Douglas G.
[email protected] wrote:

Taking a quick look at the usrp2::find function, it looks like it’s
supposed to be waiting in a while loop until a timeout occurs, is it
possible the timeout is happening before the response came from the
USRP2? Or have I perhaps made some simple mistake?
Thanks,
Doug

To follow up: it appears that it does work, at least libuhd + gr-uhd +
grc works. For example, if I open up GRC, throw in a UHD simple
source, and graphical FFT block and set appropriate parameters, I do
see what I expect: a nice FFT plot of whatever bit of spectrum I’ve
specified. So I suspect that I am running into some bug in
uhd_find_device.
Doug


Doug G.
[email protected]

That seems odd, it shouldnt be able to make a device without finding it
first. That is if nothing comes up for ::find, then the ::make will yell
at you.

Is this problem repeatable, if you repeatedly call uhd_find_devices,
will it continue to come up blank?

-Josh

That does look a bit suspicious. I have two suggestions:

  1. if its a firewall issue, make sure that the linux firewall is off
  2. if its a timeout issue edit the udp_simple.cpp and change
    milliseconds(100) to something larger, say 1000

-Josh

On Mon, Apr 26, 2010 at 3:57 PM, Josh B. [email protected] wrote:

That seems odd, it shouldnt be able to make a device without finding it
first. That is if nothing comes up for ::find, then the ::make will yell at
you.

Is this problem repeatable, if you repeatedly call uhd_find_devices, will it
continue to come up blank?

-Josh

That’s what I thought. To answer the question: repeatedly calling
uhd_find_devices gives the same result. Even calling it after
successfully running my GRC test script doesn’t change anything. For
the record, all I’m setting in the GRC test script is the IP address
to talk to (addr=192.168.10.2), the center frequency, and changing the
sample rate to something more appropriate for the USRP2 (2Msps right
now), and gain is left at 0 dB.

Hmmm - to try something else: if I call uhd_find_devices with the IP
address, it works

$ uhd_find_devices --args addr=192.168.10.2

– UHD Device 0

name: USRP2
addr: 192.168.10.2

Current rx socket buffer size: 131071
Using: Flex 2400 Rx MIMO B (0x0027)
Using: Flex 2400 Tx MIMO B (0x002b)

Not sure why it’s behaving differently though. Calling just plain
uhd_find_devices again afterwards still gives ‘No UHD Devices Found’.
Doug


Doug G.
[email protected]

I can confirm that after a couple of bits of finger-trouble on my part,
I built both UHD, and GR-UHD, and
was able to install 'em both. I don’t have a USRP2 to do tests, but at
least the build went well.

If there’s a succinct protocol description out there for UHD-over-UDP
I’d start work on a Wireshark/PCAP
protocol parser, and perhaps even submit an Internet-Draft describing
the protocol, if there’s interest.

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

When no address is specified, the find devices will send a broadcast udp
packet to each interface. I experienced identical behavior on a fedora
11 box because the firewall was interfering with broadcast packets.
After turning off the firewall with system-config-firewall, the find
devices worked as it was supposed to. Do you have the firewall enabled
on your machine?

my best guess…
-Josh

On Mon, Apr 26, 2010 at 4:44 PM, Josh B. [email protected] wrote:

When no address is specified, the find devices will send a broadcast udp
packet to each interface. I experienced identical behavior on a fedora 11
box because the firewall was interfering with broadcast packets. After
turning off the firewall with system-config-firewall, the find devices
worked as it was supposed to. Do you have the firewall enabled on your
machine?

my best guess…
-Josh

Right - ufw is indeed enabled on my machine - so that’s the most
likely candidate then.
Thanks,
Doug


Doug G.
[email protected]

On Mon, Apr 26, 2010 at 4:47 PM, Marcus D. Leech [email protected]
wrote:

I can confirm that after a couple of bits of finger-trouble on my part,
I built both UHD, and GR-UHD, and
was able to install 'em both. I don’t have a USRP2 to do tests, but at
least the build went well.

If there’s a succinct protocol description out there for UHD-over-UDP
I’d start work on a Wireshark/PCAP
protocol parser, and perhaps even submit an Internet-Draft describing
the protocol, if there’s interest.

I would be very interested in such a parser, and would be willing to
help with testing/debugging of said parser at the very least.
Doug


Doug G.
[email protected]

The rx and tx data packets are samples encapsulated in vrt headers for
IF data: http://www.digitalif.org/

The control protocol is just a bunch of enums and structs in a header
shared by firmware and host:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/usrp2/fw_common.h

These kind of contributions would be highly appreciated.

Thanks,
-Josh

Marcus D. Leech wrote:

On 04/26/2010 05:16 PM, Josh B. wrote:

The rx and tx data packets are samples encapsulated in vrt headers for
IF data: http://www.digitalif.org/
Gosh. Too bad they want $$$$ for a copy of the standard. Bleerg.

As long as you don’t mind using a draft version of the document, try:
http://www.digitalif.org/images/VRT_49.0_draft_0.21_approved.pdf

On 04/26/2010 05:16 PM, Josh B. wrote:

The rx and tx data packets are samples encapsulated in vrt headers for
IF data: http://www.digitalif.org/
Gosh. Too bad they want $$$$ for a copy of the standard. Bleerg.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

Hi,

I have finally compiled the uhd library. When I do “sudo
./uhd_find_devices” I get “No UHD Devices Found”. I have turned off the
firewall. I have loaded the firmware unto the SD card. When I turn on
the power of the USRP2 first all leds on the front are lit and then
only “D” is on.

I have no idea what to do.

BR/
Per

On Tue, Apr 27, 2010 at 01:55:55PM -0700, Sam Bretheim wrote:

Marcus D. Leech wrote:

On 04/26/2010 05:16 PM, Josh B. wrote:

The rx and tx data packets are samples encapsulated in vrt headers for
IF data: http://www.digitalif.org/
Gosh. Too bad they want $$$$ for a copy of the standard. Bleerg.

As long as you don’t mind using a draft version of the document,
try:
http://www.digitalif.org/images/VRT_49.0_draft_0.21_approved.pdf

Thanks for the link, Sam.

The draft appears to be functionally identical to the final spec.
Same table of contents, section numbering, etc…

Eric

On 04/30/2010 06:53 AM, Per Z. wrote:

Hi,

I have finally compiled the uhd library. When I do “sudo
./uhd_find_devices” I get “No UHD Devices Found”. I have turned off the
firewall. I have loaded the firmware unto the SD card. When I turn on
the power of the USRP2 first all leds on the front are lit and then only
“D” is on.

I know you got me off-list, but I would like to share the answer because
people tend to google these things and get list postings:

The solution was to set a static IP address on the network interface.
Its not like the raw ethernet communication where sometimes you needed a
static ip to make a particular interface work. You always need the
static IP address to send and receive the UDP packets.

Also, you should not need the sudo. uhd_find_devices works fine as
normal user.

And a little trivia for today: The “F” LED on the USRP2 is actually
light (faintly).

-Josh

Thanks for bringing that up, i should have sent the link as well:

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking

-Josh

On 04/30/2010 11:07 AM, Josh B. wrote:

Also, you should not need the sudo. uhd_find_devices works fine as
normal user.

And a little trivia for today: The “F” LED on the USRP2 is actually
light (faintly).

-Josh

How does the USRP2 get its IP address, how do you deal with multiple
USRP2 on the same
host? With IP routing, you’ll generally need to have each USRP2/Host
combination have its
own (probably very small) subnet, but you do have to get the routing
correct!

When you throw an IP packet “into the stack”, the IP routing machinery
in the stack figures out
which interface to send the packet on, based on the subnet mask
assigned to an interface.
So you need to make sure that your USRP2 has a distinct subnet
assigned, so that it
can be routed to appropriately.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium