On Thu, Apr 26, 2012 at 08:31, Getz, Robin <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
