Gnuradio under Ubuntu under Parallels on MacPro dual Quad core

GNU Radio
1

Hello all,

I have gnuradio running per se.

I have seen an error “USRP2 failed to enable real-time scheduling”. Does
that mean that I have a configuration issue with Ubuntu and the ethernet
system?

The MacPro has two ethernet ports, one is connected to the Internet
(eth0) and the other to the USRP2 (eth1).

I tell each routine to use eth1 (with the -e option) and that seems to
work.

I believe at this juncture that the computer is talking to the USRP2 and
that the WBX is correctly configured. I received the following output
from USRP2 Probe:

USRP2 Probe

MAC Addr:
00:50:c2:85:36:cc

Name (ID):
83

Converter Rate:
100000000 Hz

Gain Range (min, max, step size):
0.0
31.5
0.5

Freq Range (min, max):
68750000.0 Hz
220000000.0 Hz

=========================

The program usrp2_fft.py shows no spectrum.

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

2

I believe that the usrp2 gnuradio driver has a linux specific packet
ring, and therefore wont work on a bsd environment.

you may want to try the uhd, its using userspace sockets so it should
function cross-platform:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

-josh

3

(eth0) and the other to the USRP2 (eth1).

I tell each routine to use eth1 (with the -e option) and that seems
to work.

I believe at this juncture that the computer is talking to the
USRP2 and that the WBX is correctly configured. I received the
following output from USRP2 Probe:

After seeing a post by Josh B. stating that I should run HUD because
he thought that since “the usrp2 gnuradio driver has a linux specific
packet ring, and therefore wont work on a bsd environment.” I was
momentarily outraged. Does it not often seem that if you are not
running what (the ubiquitous) “they” are running the answer is always
the same? Go get on a different system is just the easy way out.

Then I thought to myself, “he said that because the underlayment of
OSX is indeed BSD.” Of course, I was running BSD when Josh was in
diapers, but that is beside the point. It is also of no consequence
that I exclaimed out loud “THERE IS A GOD!” when Apple announced that
it was moving it’s platforms to Unix. I digress…

It was clear I was on my own, so I started searching. I then
discovered “ethtool” and found that it did not want to tell me what
the so-called pause parameters were for eth1. Then I remembered what
Josh had said and thought again to myself, “maybe the problem
is on the Mac side”. This was heresy, but what the hey it’s
only bits and my time, and good grief I have spent enough of the
latter on this game.

Lo and behold, the Mac Network control panel for Ethernet 2 was set to
full-duplex, flow control! Ahhh-Hah! So, switching that allowed the
data to flow, literally. Now I have a USRP2 that is doing as it’s
told, life is good. Who said you can’t run gnuradio on a VM?

Summary:

• Apple Mac Pro 2 x 3.2 GHz Quad-Core Intel Xeon w/4 GB 800 MHz DDR2
FB-DIMM RAM

• Mac OS X 10.5.8 (Leopard)

• Parallels Desktop 5 for Mac build 5.0.9344/Rev 558741 2/5/2010

• Ubuntu Linux 10.04 LTS (What have you kids done to Unix?!)

• gnuradio whatever…

• USRP2 w/WBX daughterboard

Now the fun can begin. Thanks for all the tips!

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

4

On 05/17/2010 04:45 PM, HR Myler wrote:

After seeing a post by Josh B. stating that I should run HUD because
he thought that since “the usrp2 gnuradio driver has a linux specific
packet ring, and therefore wont work on a bsd environment.” I was
momentarily outraged. Does it not often seem that if you are not
running what (the ubiquitous) “they” are running the answer is always
the same? Go get on a different system is just the easy way out.

When developing software these days, it’s important to start out life by
picking the environment
most likely to be broadly useful first. Eliminating windows for a
second, that leaves Linux.
While it’s true that it’s possible to build many classes of
applications in such a way that they’re
utterly-portable from OS-to-OS, it’s hard, and it’s harder when the
application has to touch
anything other than a highly-abstracted interface to the filesystem,
and few rigidly-standardized
applications APIs.

It’s not a big surprise to me that some of the bits 'n pieces of the Gnu
Radio network interface
code use some Linux-specific networking “stuff”.

You are using a VM that may, or may not, faithfully mimic the behaviour
of real hardware. That’s
not the environment that Gnu Radio was developed on, so it should
hardly be surprising that
the kinds of “weird cases” produced by a VM environment haven’t been
tested-for, or accounted for.

The kinds of combinatorial explosions that happen in code when the code
does try to account for
“all possible barriers to correct functionality” are truly hideous,
and lead to code that is
profoundly hard to maintain–speaking from agonizing experience. Over
and over again.
For the past 31 years.

Consider a reductio ad absurdium argument. What if there was hardware
out there that couldn’t
add certain numbers properly, and occasionally didn’t do multiplies
correctly? Software generally
assumes that when you add 2+2, you get four. It generally doesn’t
need to verify that the
underlying CPU is actually sane. But one could argue that software
should perhaps be robust in
the face of impossible odds, and do such checks, perhaps only when it
detects “weirdo environment
number 57”. But it’s easy to see how quickly such a piece of
software becomes elephantine and
unmanageable.

Probably the right thing for MacOS, is to have native ports of the Gnu
Radio code, and UHD,
and so on. I think basic Gnu Radio functionality is already available
on MacOS, so some keener
with BSD experience could perhaps lend a hand and get UHD running
natively on MacOS/*BSD.

–

Principal Investigator
Shirleys Bay Radio Astronomy Consortium