discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD de


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)
Date: Fri, 30 Dec 2011 15:02:35 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On Thu, Dec 29, 2011 at 07:01:19PM -0500, Marcus D. Leech wrote:
On 29/12/11 06:48 PM, Tom Rondeau wrote:

I absolutely agree on this. We should definitely have a standard uhd
options parser that we can pull in to any program using a uhd device.
Excellent suggestion.

If we have/had one for GNU Radio before, I never used it or knew about
it. Having recently just fixed most of the examples, I never ran
across it, either. We do have a preferred style and suggested options
in our style guide on the Wiki, though.

For this, we probably don't have enough general use options to have a
default GR options parser module, though. We should definitely make a
UHD one though.
That was my suspicion--that there just aren't really any "general" Gnu
Radio options, except perhaps for scheduler
   tweaks (TPB vs not-TPB is the only one I can think of).
I keep thinking this may be a reason for the lower interest in GnuRadio.
If someone writes a program to run on a USRP2 and daughterboard and I want
to run it on my USRP1, the UHD part should take care of the differences
if the frequencies and such are compatible. The computer should be able
to tell what hardware is connected and use the appropriate parts or
default to the most likely.
The problem is that it's very often the case that the "computer" can't really intuit what your *intent* was when you're dealing with new hardware. Sample rates, for example, aren't always compatible between different USRP families (oh, sure,
  there are spot places where there are overlaps, but not in general).

So, you have a flow-graph that "knows" that the sample rate is 3.2Msps--what should UHD *do* when you plug it into a USRP2-family device that doesn't support that
  sample rate?

For the most part, I find that UHD flow-graphs (and I've written a *lot* of them)
  *are* compatible between hardware families, provided I pay attention to
those cases where there are irreconcilable differences betweeen hardware families.

And your comment about "low interest in Gnu Radio" is quite perpendicular to most peoples experience here. Look at CGRAN--there's a lot of applications that have been written with Gnu Radio, and that's the tip of the iceberg. There are a *lot* of private
  projects out there using Gnu Radio and UHD.

I finally got programs to work with UHD and my USRP1 but only after much
searching and adding command-line info. I know I'm old school, but the
computer is supposed to work for the user as best it can rather than the
user having to work for the computer. This, of course, is about the
programming but I spend far too much time trying to get older programs
to work because of some update that breaks everything.
The key message here is "as best it can". In fact, UHD *does* pick reasonable defaults wherever it can. For example if you don't specify a device string with UHD, it'll look around trying to find something it can attach to. But if there are multiple devices, which one should it pick? I'm also old-school, having been a software developer and system architect for over thirty years. But I've never bought into the poorly-though-out notion that "the computer should just know". Because in many (but, admittedly, not all) cases, it can't pick a reasonable default.
  It's neither psychic, nor artificially intelligent.


If I find some neat new block in GRC I spend way too much time trying to
figure out what parameters to enter rather than tweaking default params.
Of course the error messages are seldom useful either. The uhd_fft.py
finally worked on my 3 GHz 4-core machine after I figured out the options
but just hung when I clicked on anything. Seem to be the frame rate problem
which should have been fixed long ago.
It's really hard for the software to know and predict how crappy the frame-by-frame performance will be *on your particular platform*, so again, how should it pick
  a default frame rate?  Should the strategy be:

o pick one that will please whoever is sitting in front of the screen. Not too slow, because that will just piss them off. Not too fast, because that will swamp the OpenGL rendering engine (maybe, depending on exact graphics hardware being used, OpenGL version, memory bandwidth
        CPU speed and type, etc, etc).

o Pick one that is based on some hard-to-define heuristic based on hardware configuration and
       flow-graph parameters

o Pick some reasonable middle-ground, like the current (AFAIR) 15 FPS, and let the user cope with
       whatever computational consequences there are

The error messages from GRC come from within Python, for the most part. So it is true that you need to understand Python error messages in order to fix problems that arise when you make mistakes in setting parameters. It is also true that GRC isn't that well documented, and very little tutorial material exists for it. The community is always invited to fix that class of problem, and contribute the results. Gnu Radio isn't a commercial development. It's a small handful of core people who do this part-time.


You see, in modern software systems, the software sits on the shoulders of dozens and dozens of somtimes-flawed giants. It's not really possible to control the flaws in any of those giants. One might decide not to pick those giants in the first place, but then the development slows way down while you try to replicate the functionality provided by those giants, instead of focussing on the core features of your actual "product". So when you say "the frame rate problem should have been fixed a long time ago", you are either being deliberately inflammatory, or you don't understand how modern software gets put together, and where the boundaries of responsibility lie, for a project driven by volunteers.


It is hardly worth updating the hardware if the same problems will be
encountered. I'm afraid to update Ubuntu or GnuRadio at the moment since
my experiments will likely be stopped again. I have some programs I run
under FreeBSD, since that is my preferred OS, but I can't update any of
them because GnuRadio won't compile there at all since 3.2.2. Most of the
problems are probably like the header files in the TCP sink code when
something was probably "updated" from an old version.
Have you thought (FSM forbid!) of figuring out *why* newer versions of Gnu Radio won't build under FreeBsd, and then *contributing* those fixes back to the project? Most of the Gnu Radio developers are Linux people, and while we strive for portability, the fact is that most of the testing and development happens on Linux. If this were a commercial project, rather than one that was community driven, there'd be resources allocated to deal with portability issues. We rely
  on the interested community to provide those resources.  If the community
  doesn't step up, then nothing happens.


I use GnuRadio a lot to just get bits to feed to C programs where they
get processed because doing that in GnuRadio is much harder. Good thing
I'm not doing this for a living.

I do this as well. I'm under no delusion that Gnu Radio can solve *all* randomly-selected computational problems that have to do, tangentially or otherwise, with radio. It's primarily a (still-emerging) DSP framework, with a little bit of packetizing and relating "goo" thrown in. There are certainly many classes of problems for which the DSP-based focus isn't a particularly good fit. But, well, so what? The Unix "Shell" isn't a particularly good fit for doing real-time high-speed data processing, but within its problem domain, it's
  pretty darned good.

Gnu Radio is a flow-based DSP framework. So it isn't very good at *algorithmic* work, at least not at the top-level--"algorithmic work" tends to get done inside the context of blocks, so if you have to execute an "algorithm" on data, it may require a new block to be constructed. Adding new blocks isn't, perhaps, as easy as it could be, but it's easier than it used to be. Again, see some of the work on CGRAN. Also, for non-performance-critical stuff, Josh Blum's Python-blocks work is about to get folded into the main codebase, and this allows much easier construction of new blocks, complete with reasonably-seamless
  integration into GRC.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org





reply via email to

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