> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
