I’m co-writing a paper on the use of GNU Radio. Because I’m inclined to
use ‘Open Source’ solutions,
GNU Radio and the attendant DSP library, was for me about the only
choice I would have made…
However, in the paper I’d like to at least make some attempt at
indicating any ‘alternatives’, if there
are any in the Open Source arena, or parish the thought, cost-money type
packages.
If anyone has done a more detailed evaluation and perhaps has a chart
depicting features, that would be
good.
Also, a while ago, I saw someone who had put together a ‘graphical’
interface, where one could construct
a DSP processor using graphical means, and setting various parameters
using a GUI. I have not had the
time to really keep up on that sort of thing, but if there is someone
who has something that works, I’d also
like to know about that.
For those who have information, and send me a release, credit will be
made in the paper for their contribution.
WARP is a very expensive platform IMO, and they are not as modular as
GNU Radio. I would say GNU Radio has far more in the PHY layer, and
WARP has 1 PHY (OFDM) + a bunch of MAC implementations.
The KU Agile radio is still pretty new, Prof. Minden gave a talk here
about it last semester and it seemed the hardware was pretty concrete
but the software was still in progress… which is what truly separates
SDR platforms
CalRadio v1 is strict 802.11 based, and the PHY is not flexible. I
think their goal was to keep the PHY in hardware and swap out
daughterboards with different PHYs that you could re-program the MAC on.
There are a couple other SDR-type platforms in the academic world…
but none really come close to the code base of GR IMO.
Some of these seemed pretty ‘expensive’ to get into… the use of ASICs,
and the like, also, they seem to be directed to pretty
specific implementations of transmissions, even though one could
conceivably load in a new chunk of firmware ‘on the fly’ perhaps…
WARP is a very expensive platform IMO, and they are not as modular as
GNU Radio. I would say GNU Radio has far more in the PHY layer, and
WARP has 1 PHY (OFDM) + a bunch of MAC implementations.
Looked interesting, but did have this overhead of ASIC, and buying the
attendant boards.
The KU Agile radio is still pretty new, Prof. Minden gave a talk here
about it last semester and it seemed the hardware was pretty concrete
but the software was still in progress… which is what truly
separates SDR platforms
Looks closest to what I’m doing… albeit not with a PPC core…
CalRadio v1 is strict 802.11 based, and the PHY is not flexible. I
think their goal was to keep the PHY in hardware and swap out
daughterboards with different PHYs that you could re-program the MAC on.
Almost instant negative… I have my Master from UCSD, the consolation
prize for those who didn’t get a PhD… and further… have not
forgotten the nonsense with UCSD Pascal and the Regents… but I
digress…
I’m co-writing a paper on the use of GNU Radio. Because I’m inclined to
use ‘Open Source’ solutions,
GNU Radio and the attendant DSP library, was for me about the only
choice I would have made…
However, in the paper I’d like to at least make some attempt at
indicating any ‘alternatives’, if there
are any in the Open Source arena, or parish the thought, cost-money type
packages.
High Performance Software Defined Radio (opensource)
An Open Source Design
The HPSDR is an open source (GNU type) hardware and software project
intended as a “next generation” Software Defined Radio (SDR) for use by
Radio Amateurs (“hams”) and Short Wave Listeners (SWLs).
There are GnuRadio developers which are in contact with or collaborate
with people of HPSDR.
They use some of the verilog sourcecode of the USRP for their FPGA in
their boards.
libDSP (opensource)
libDSP is a C/C++ library of digital signal processing routines,
including standard vector operations, digital filtering, and transforms.
flex-radio (commercial)
Company building software defined radio frontends (SDR-1000) for use
through the soundcard of a PC for the IF.
Aimed at Radio-amateurs
Comblock (commercial)
Hardware oriented commercial company delivering blocks to build SDR
systems
ComBlock modules are small commercial off-the-shelf modules which are
pre-programmed with essential communication processing functions,
including modulation, demodulation, error correction encoding and
decoding, digital to analog/RF, RF/analog to digital, formatting, data
storage
and baseband interfaces. http://www.comblock.com
For those who have information, and send me a release, credit will be
made in the paper for their contribution.
If you need any other kind of info, please let me know.
I have done some presentations on GnuRadio and Software Defined Radio
and I am preparing for some GnuRadio courses that I will be giving.
It would be appreciated if you made the paper public and available
somewhere on the web.
If you need any other kind of info, please let me know.
I have done some presentations on GnuRadio and Software Defined
Radio and I am preparing for some GnuRadio courses that I will be
giving.
It would be appreciated if you made the paper public and available
somewhere on the web.
Martin - Are your presentations linked into the Wiki, or available
elsewhere for general viewing? I, for one, would love to see them.
I, too, am writing a paper that will (among other things) discuss GNU
Radio and USRP and alternatives to them. I’m happy to provide a
summery, on or off-list, of what I’ve learned / written. Assuming the
paper gets published, then we’ll make sure to link it in the GR wiki.
There are a couple other SDR-type platforms in the academic world…
but none really come close to the code base of GR IMO.
Some of these seemed pretty ‘expensive’ to get into… the use of
ASICs, and the like, also, they seem to be directed to pretty
specific implementations of transmissions, even though one could
conceivably load in a new chunk of firmware ‘on the fly’ perhaps…
Along those lines are Lyrtech’s boards (the Small Form Factor (SFF) SDR)
and TI has something similar. These are almost all FPGA-based SDR
devices, and I’m not sure what kind of software you get with them to do
any communications. And they are very expensive.
Looks closest to what I’m doing… albeit not with a PPC core…
Gary’s new design uses an Intel chip, though I’m not sure where they are
on production. I’ve seen them work, though, and they provided a nice
demonstration of the KUAR at the IEEE DySPAN conference in Dublin last
year. I hope to get them back for this year’s, too.
I have two of the Lyrtech boards and with the develpment tools for DSP
chip and FPGA. Using Matlab simulink, and code generation, etc. for
rapid prototyping this is just about ohh, one hundred grand…
The Matlab is shared license at work as is the DSP and FPGA development
tools but this is well out of reach of most.
Bob
Tom R. wrote:
conceivably load in a new chunk of firmware ‘on the fly’ perhaps…
Along those lines are Lyrtech’s boards (the Small Form Factor (SFF)
SDR) and TI has something similar. These are almost all FPGA-based SDR
devices, and I’m not sure what kind of software you get with them to
do any communications. And they are very expensive.
I’m trying to build the latest in SVN under ubuntu (6.06 lts). Compiled
fine about 6 months ago but this time it fails on missing header files.
Tracked it down to abs_top_srcdir is not getting defined.
I manually defined it in the shell and the compile seems to be going
now.
I assume automake should have generated this? Is anyone else having this
problem?
I’m trying to build the latest in SVN under ubuntu (6.06 lts). Compiled fine
about 6 months ago but this time it fails on missing header files. Tracked
it down to abs_top_srcdir is not getting defined.
I manually defined it in the shell and the compile seems to be going now.
I assume automake should have generated this? Is anyone else having this
problem?
We (well, I) recently checked in a fairly significant update to our
build system, which should have had no impact on existing
functionality. Testing was done with Ubuntu 7.10 but not 6.06.
Could you please try compiling using the stable 3.1.1 release branch?
I have two of the Lyrtech boards and with the develpment tools for DSP
chip and FPGA. Using Matlab simulink, and code generation, etc. for
rapid prototyping this is just about ohh, one hundred grand…
In my spare time I am working on getting Linux running on the ARM on
the Lyrtech board.
Since I don’t have enough spare time, I only have Linux running on the
ARM via root over NFS, but it is a start. I have a web page where I
keep track off my efforts:
This is only for people experienced with embedded Linux at the moment.
If you are interested in trying this out, ping Lyrtech Tech support
and ask for a utility to restore the flash to the factory settings.
The board should run GNU radio once Linux is running OK.
We (well, I) recently checked in a fairly significant update to our
build system, which should have had no impact on existing
functionality.
Yup. That’s what it was. autotools in 6.06 does not define
“abs_top_YYY”, as does autotools for 7.10. Go figure. I’ll find
another way to do this, robustly. - MLD
I just checked in a fix for this issue, so please try updating to the
latest SVN trunk.
“abs_top_YYY” -is- used internally in older autoconf such as found in
Ubuntu 6.06 or 6.10, but it isn’t placed in the list of substitution
variables (i.e. for external use). Adding these variables to the list
of substitutions is simple, and “just doing it” (even twice) is OK
because autoconf checks for duplicates. “make” and “make check” work
(for me) on Ubuntu 6.10, 7.10, and OSX 10.5. - MLD
CC: [email protected]; [email protected]> From: [email protected]> To: [email protected]> Subject: Re: [Discuss-gnuradio] abs_top_srcdir?> Date: Sun, 10 Feb 2008 21:38:43 -0500> > On Feb 10, 2008, at 6:46 PM, Johnathan C. wrote:> > We (well, I) recently checked in a fairly significant update to our> > build system, which should have had no impact on existing> > functionality.> > Yup. That’s what it was. autotools in 6.06 does not define > “abs_top_YYY”, as does autotools for 7.10. Go figure. I’ll find > another way to do this, robustly. - MLD
Thanks, I’ve worked around for now by manually defining these.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
