[Top][All Lists]

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

Re: [Discuss-gnuradio] Acoustics instead of radio & what's possible in r

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Acoustics instead of radio & what's possible in real-time?
Date: Mon, 10 Dec 2007 09:32:31 -0800
User-agent: Mutt/1.5.17 (2007-11-01)

On Sun, Dec 09, 2007 at 07:16:45PM -0500, Jim Morash wrote:
> 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.
> http://www.engadget.com/2007/06/03/via-epia-px10000-pico-itx-motherboard-gets-reviewed/
> I am fairly new to software-defined radio in general. Thanks in advance for 
> any suggestions.
> --Jim Morash
> address@hidden


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.


reply via email to

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