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++.
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++.
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.
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?
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.
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 B. [email protected] 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?
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
