[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
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