Re: [Discuss-gnuradio] Multiple applications using same A/D converter?

[Eric Blossom]

On Sat, Mar 22, 2003 at 02:40:50PM -0600, David Nesting wrote:
> I'm a long-time lurker here and one of the things I'm interested in is
> the ability for more than one application to access (and demodulate,
> independently) from the same A/D converter.

Me too.

> >From all of the code I've studied, each application seems like it takes
> exclusive control of the ADC for its specific task (even the sample that
> demodulates two FM broadcasts at once).  Is it likely that a current or
> future GNUradio implementation might allow some additional flexibility
> here?

Yes.

> If I use an expensive ADC, I'd like to only have to buy one of
> them and start up a separate process for each type of demodulation I wish
> to perform (perhaps piping the results to speakers/video terminals in
> other locations at the request of users, or delivered on-demand through
> a SIP-negotiated network session).  This way I don't have to devote the
> ADC to one task.  I can be decoding an ATSC broadcast in one process
> and decide I want to decode the closed-caption messages from another.
> And maybe 24x7, I'm listening on WWV and providing time synchronization
> to the network, independent of other "real" tasks that are working with
> other areas of the spectrum.

The thing to note in all of these scenarios, is that if there's
sharing of the A/D and the attached RF front end, there does need to
be some way to figure out where to tune the front end, and what sample
rate to run the A/D.  After all, at any given instant the RF front end is
tuned to a single center frequency.  If the signals of interest are
within the pass band of the front end, and if you're sampling rate is
sufficient to capture them all, and if the A/D converter's got enough
usable dynamic range to handle the span between the weakest and
strongest signals of interest, this will work.

> This would more or less require a "master" process doing the tuning
> and ADC work and managing the flow of data to each slave performing
> the demodulation.  These slaves could attach or detach in any number or
> fashion to the master, subject to available CPU horsepower.

We'll be adding support for a scripting language soon.  I spent a
bunch of time considering Python, but after comparing it to PLT Scheme
(http://www.plt-scheme.org, http://download.plt-scheme.org/doc), I'm
leaning towards scheme.  It's between 10 and 100 times faster than
Python, has both a byte code compiler and native code compiler, and
has considerably more expressiveness than Python (e.g., macros, higher
order functions, mutable strings).  Both solutions have lots of
documentation, big user base, active development, good bindings for
GUI functions, networking, classes, and all the rest.  I believe the
scheme solution will actually allow the implementation of some low
bandwidth signal processing functions directly in scheme.  In python
that's unlikely to work.  [This will allow experimentation without
having to code up new C++ primitives.]

Anyhow, the idea is that you build a data flow graph that describes
your application using the scripting language.  The nodes in the graph
are the signal processing primitives.  These includes things like A/D
converters, FIR filters, file sources, file sinks, TCP sources, TCP
sinks, FPLL's, equalizers, viterbi decoders, etc.  The edges are the
interconnections between the outputs and inputs of modules.  Some
modules are hierarchical, built out of primitives, and present a
single interface to the rest of the code.  One of the first modules of
this type that I expect to see encapsulates the A/D and N channel
selection filters.  A channel selection filter performs the digital
down conversion of the signal, filtering and decimation.

One way to implement your idea is to just connect the other
demodulation paths to the output of one of the channel selection
filters.  The demodulation could be run in the same address space, or
for that matter, you could run the sample stream into a TCP sink,
where it would available to other processes.

> (And actually, taking this a step further, maybe this "master" could
> conceivably juggle between multiple A/D converters (maybe on different
> systems?), letting people take advantage of a large number of spare
> sound cards and aggregate the sampling power of each.  But I might be
> diving a little too far into fantasy here.)

One thing to keep an eye on is the aggregate i/o bandwidth.  If you're
talking about sound cards, it's really not going to matter.  On the
other hand, if you're pushing 80 MB/sec, a little more thought is
required.

Returning to the combined A/D, N channel selection filters module, I
expect we'll have at least a couple of implementations.  One will be
similar to our current setup.  A dumb A/D streaming data into the
system, and then all the channel selection filters implemented in
software.  The other solution maps onto hardware like the USB board
with FPGA we've been talking about.  In that case, the channel
selection filters are implemented in the FPGA, reducing the
computational load on the PC tremendously.  I'd expect similar
implementation for ASIC DDC's (e.g., Analog Devices "Receive Signal
Processors") or some other kind of reconfigurable hardware.

In all of these, the user codes his graph using the high level module,
and then the appropriate implementation is selected based on the
available hardware.  This makes it easy for folks to build high
performance radios without having to sweat the low level details.

Eric