in our style guide on the Wiki, though.
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 B.'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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
