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<float>)
> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
