Re: [Discuss-gnuradio] Python function processing block

[Murray Lang]

Thanks Eric.

sox will get me started but I would eventually like my application to be able to open wav files. Unfortunately the Python wave library limits the sample size to 16 bits - OK for USRP but not for HPSDR. I have a feature request in at python.org to expand it. 

I'm still struggling to get my head around GNU Radio but I see a network source as having a single output and a sink as having a single input. If you want to split or combine then subclass hier_block to do the job. Also, I see the network blocks operating at a higher level than raw sockets. As for the data types, it should deal with a range of them appropriately and transparently. The source output type should be whatever was pumped into the sink at the other end. If the flow graph mechanism is too rigid for that then have different classes for different data types.

In terms of performance, I would have thought that if you can play wave files in Python (you can) then it's probably fast
 enough as a wave source. Network I/O should be more of a bottleneck than Python. (I must research on-the-fly compression.)

I have skimmed through howto-write-a-block.html but need to understand the relationship between Python and C++ better to make use of it (I have a rudimentary understanding of SWIG). The occasional evening time-slice that I get to devote to this stuff just doesn't make for rapid progress. 

Cheers,
Murray
VK6HL

Eric Blossom <address@hidden> wrote:

On Tue, Oct 17, 2006 at 02:31:28PM +1000, Murray Lang wrote:
> How did you go Marcus?
>
> I hunted high and low for a class that I could subclass to implement
> a gr.block in Python. My initial reason is that I want to implement
> a source that reads I/Q data from WAV files so that I can compare my
> GNU Radio results with PowerSDR using exactly the same data. Wav
> files are much easier to work with in Python than C++.

The easiest thing may be to convert the WAV files with sox.

I think something like this will work:

$ sox -V foo.wav -f foo.raw

and foo.raw will end up with floating point values.
If the input has two channels, then I think you'll get interleaved
floats as output, which is equivalant to gr_complex (== std::complex)

> I would also like to implement network data sources and sinks for
> remote SDR operation. Network programming is much easier in Python
> than in C++.

Agreed. Just open the sockets in python then pass the corresponding
file descriptors (s.fileno()) to gr.file_descriptor_{sink,source}.

> In short it seems to me perfectly natural to have a gr.block class
> implemented in Python, particularly (but not only) sources and
> sinks. It would be really nice if there was a Python class that we
> could simply subclass to achieve that.

It's natural, but will be dog slow ;)

If that doesn't scare you off, then the next question is
what i/o signature do you want to use? Will the block
accept a single input and produce a single output, or will it accept a
varying number of inputs and produce a varying number of outputs?

I can imagine several common cases:

float -> float
complex -> complex
float -> complex
complex -> float

Would you expect your python code to accept input and produce
output a single sample at a time, or to deal with arrays of input and
output samples?

If you haven't already, please take a look at
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html
Though it's C++ centric, the same issues will exist in a python
implementation. After reading that, please ask the question again,
and I can provide further assistance.

> Murray
> VK6HL

Eric

Send instant messages to your online friends http://au.messenger.yahoo.com