I've implemented a power spectrum display to demonstrate a way to postprocess the data gathered from GNU Radio in python.
Update (2014-04-03): An updated version of the software (now compatible with GNU Radio 3.7) is available from GitHub.
The software can use an RTL-SDR compatible DVB-T tuner as a signal source.
The signal is processed by GNU Radio, which performs FFT.
The FFT output is then sent to my python code using a Message Sink block.
The python program then plots the data using the python-matplotlib module.
The above plot shows the output when I transmit with my handheld radio on 2 meters band. Center is set to 145.000 MHz by default, but you can change it in the fft_test.grc file.
When I started out with Message Sink and Source blocks, this tutorial was quite useful. These blocks help you to communicate between your python code and GNU Radio block diagram. Basically, you can get the processed data from GNU Radio and use it in python, or do it in the other direction: you can generate some kind of data in python and send it to GNU Radio for processing.
I wouldn't suggest anyone to implement advanced DSP functionality in python, but it might be reasonable to:
To run my example you would need:
You can edit the flowchart in GNU Radio Companion to suit your needs. Then you have to hit Generate (F5) in GRC, but note that when running my program, it will first change some lines in the the top_level.py before importing it (this is what grcconvert.py does). There are two problems with the code generated by GRC:
The first is, gr_message_sink_0_msgq_out is not a public member of the top_block class, nor it is initialized as it should be, so we have to add a line:
self.msgq_out = gr_message_sink_0_msgq_out = gr.msg_queue(2)
...to create a message queue that we can access from outside.
The second problem is the confusing grayed output of Message Sink. You have to connect it somewhere to have your top_block.py generated, but you don't need to use it for anything at all. You can't connect it to a Null Sink, as IO size does not match. At the end, I've connected it to a Pad block, but then I had to comment out the line corresponding to the Pad block in the top_block.
When executing fft_test.py, the grcconvert module solves both problems automatically by changing the corresponding lines, so you don't have to do it manually every time you generate a new flowgraph.
You can start it by typing: