Re: [Discuss-gnuradio] Porting new hardware to GNURadio

[Johnathan Corgan]

On Thu, Apr 26, 2012 at 08:31, Getz, Robin <address@hidden> wrote:
> On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered:

>> This will give you the "canonical" format for writing your own
>> out-of-tree installable GNU Radio blocks.
>
> And what is preferred? I always think in-tree is better - but that's just me.

If you are not planning to contribute your code to the GNU Radio
project, the out-of-tree build system allows you to maintain your
source code independently of GNU Radio, in its own version control
system, and allows you to distribute said code in an optimal fashion.
In addition, the build process is much faster.  You can even use OS
supplied binary development packages in lieu of compiling GNU Radio.

If you are planning to offer your code for inclusion into GNU Radio
proper, it's still much easier to get it written and debugged on its
own, then convert it to the in-tree, top-level component form.

One thing to consider, though is that in order for the code
maintainers (Tom and I) to be able to manage inclusion of new hardware
support into the project, we need to be able to test locally in our
labs.  This involves providing the hardware either on a long-term loan
or donating it to the project.

>> A hardware source block would have no input ports, one or more output
>> ports for whatever streams your device generates, and a work function
>> that wraps calls to your existing sample-based I/O library for your
>> device.  The main purpose of the work function would be to retrieve
>> samples from the device and put them into the block output buffer, and
>> some housekeeping to tell the GNU Radio runtime what you've done.
>
> What is the widest band device (MSPS) that GNURadio can keep up with in real
> time? With this card - we are limited in memory bandwidth (vs a desktop), and
> Cortex A9 isn't bad - but it's no Intel CPU in terms of floating point
> performance...

There are way too many variables here to answer your question
accurately.  GNU Radio routinely handles 25 Msps I/Q plus DSP with
mid-range desktop x86 systems.  The greatest variable is not so much
the sample rate but what you're doing with it.  Others on the list may
chime in with their own unique applications and the performance they
are achieving.

> Who actually manages the location of the buffer? If GNURadio mmaps the
> location (rather than malloc), it will save a memcpy in the work function.

Yes, the work function is provided a mmaped buffer which you can
directly DMA into if your hardware supports that.

> What's the format that GNURadio wants (16-bit fixed? float? other?) We can
> make the format converter in the HDL, to decrease the load on the processor.

Inside GNU Radio, the majority of the blocks are designed to operate
on single-precision, floating-point samples.  Usually, the
over-the-wire format is optimized the bandwidth of the transport in
use, which means fixed-point samples and conversion on the host.  You
can instead transport floats to gain CPU performance at the expense of
transport bandwidth/sample rate.

> There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC
> sample rates, sync, MIMO config, etc) - I'm assuming some of those
> configuration knobs are exposed to the python interface in a standard manner
> across hardware?

No, we don't have a device abstraction layer at this level.  It's a
nice idea and many have suggested it, but it's been an open issue for
SDR in general for a long time.  So you are free to implement whatever
function calls are needed to twiddle the hardware the right way, and
there is a standard way (via SWIG) that these functions get exported
to the Python API.

>> This isn't needed to develop your own distributed GNU Radio blocks;
>> you only need comply with the GPLv3 license terms of GNU Radio.
>
> Right - but I would think that it would be better to have things in tree?

For the reasons above, we have to think about how generally available
the hardware is, whether we ourselves can test with that hardware,
etc.  But in-tree is definitely better for your users, as they get the
drivers "for free" when they install GNU Radio.

Johnathan