Hi,
I’m working on a software-defined acoustic communications transceiver,
currently based on DSP-targeted code generated by MATLAB and Simulink.
I’m looking into options for converting the project to free software and
so far I have been reading about Scicos and GNURadio. As part of moving
to a free software platform, I would also transition the system from a
DSP target to a general purpose (PC) processor.
I’d like to make the whole system real time capable (rather than
data-acq followed by post-processing) and I hope to get an idea from the
gnuradio list membership of what is possible on a general purpose
processor, and whether GNURadio is a good platform choice for my
application. For example, one difference from more typical SDR projects
is that we are doing direct quadrature sampling without a HW basebanding
front end. In the current design, the receiver does:
- sampling at 4x the carrier (Fc @ 12kHz now, may go up → 48ksps min,
maybe 96ksps in the future?)
- digital I-Q demodulation, decimation
- correlation to detect start-of-packet
- demodulate & decode packet of QPSK symbols (training & data bits)
using a digital PLL, decision feedback equalizer and viterbi decoder,
currently 200 training symbols & 600 data symbols
- a bit of MAC and application layer stuff (but this is lower processor
demand)
Is this possible? Or perhaps trivial, compared to RF data rates? Does it
look like I’d need to write a bunch of new blocks if I moved to GNU
Radio? 
For comparison, the existing (floating-point) DSP implementation runs a
bit behind real time. It takes about 3 seconds to process a packet of
length ~0.7 second. I would like to do better. The PC-compatible
hardware platform I had in mind is the Via PX10000 (for size/power
reasons); it seems fairly fast and has a nice built in audio codec with
a high sampling rate.
I am fairly new to software-defined radio in general. Thanks in advance
for any suggestions.
–Jim Morash
[email protected]
Jim-
processor, and whether GNURadio is a good platform choice for my
currently 200 training symbols & 600 data symbols
- a bit of MAC and application layer stuff (but this is lower processor
demand)
Is this possible? Or perhaps trivial, compared to RF data rates? Does it
look like I’d need to write a bunch of new blocks if I moved to GNU
Radio? 
For comparison, the existing (floating-point) DSP implementation runs a
bit behind real time. It takes about 3 seconds to process a packet of
length ~0.7 second.
How many MFLOPS does your DSP solution currently require? You mention a
floating-point DSP; is it the Texas Inst
C6713? If so is it running 300 MHz / 1200 MFLOPS?
-Jeff
I would like to do better. The PC-compatible
How many MFLOPS does your DSP solution currently require? You mention a floating-point DSP; is it the Texas Inst
C6713? If so is it running 300 MHz / 1200 MFLOPS?
Yes, that’s right. I do fear we are using it rather inefficiently,
though.
On Sun, Dec 09, 2007 at 07:16:45PM -0500, Jim Morash wrote:
followed by post-processing) and I hope to get an idea from the gnuradio
- demodulate & decode packet of QPSK symbols (training & data bits) using a
behind real time. It takes about 3 seconds to process a packet of length
[email protected]
Jim,
GNU Radio should be a good fit for your problem.
Most PC’s have got plenty of FLOPS to run your problem in real time.
We routinely deal with signals up to 8MS/s complex, though of course
it depends on what you’re trying to do.
You may need to write a few blocks, but I think you’ll find that most
of them already exist.
If you build the documentation (./configure --enable-doxygen)
and point your browser at gnuradio-core/doc/html/index.html you’ll
find a list of blocks under “Classes” / “Class Hierarchy”. This
doesn’t include the hierarchical blocks implemented in python. You’ll
find those by looking in gnuradio-core/src/python/gnuradio/blks2impl
If you need more pointers, just ask.
Eric
Jim-
mysteriously appear when optimization is turned on. As I’m a
microcontroller programmer with little DSP experience I haven’t solved
this problem yet.
To make a valid 6713 vs. PC comparison at some point, on the DSP side
you’d want to
resolve the optimization issues and make sure you’ve got L2 cache being
used
efficiently. There is a current thread on the C6x Yahoo Group about
this (look for
‘dorian’).
-Jeff
Jim Morash wrote:
How many MFLOPS does your DSP solution currently require? You mention
a floating-point DSP; is it the Texas Inst
C6713? If so is it running 300 MHz / 1200 MFLOPS?
Yes, that’s right. I do fear we are using it rather inefficiently, though.
To clarify: we are running non-optimized code on the 6713, due to a
combination of version incompatibilities between various pieces of
software (some MathWorks, some TI, some “4th party”) and bugs that
mysteriously appear when optimization is turned on. As I’m a
microcontroller programmer with little DSP experience I haven’t solved
this problem yet.