Re: [Discuss-gnuradio] GrBlock

[Josh Blum]

On 11/04/2011 01:22 PM, spino wrote:
>> It needs a more recent gnuradio (master or latest release) because of
>> the tags requirement. Anyway, the grblock work has been continued on my
>> gnuradio development branch. Its now integrated into gnuradio as well:
>> http://gnuradio.org/cgit/jblum.git/log/?h=next
> 
>> -Josh
> 
> Hi Josh, I installed GNURadio 3.5.0rc0 from the git repository as
> normal (git clone http://gnuradio.org/git/gnuradio.git). Could you
> please help me with these questions: How can I find the examples of
> GrBlock? Where to start? Do I need to compile GrBlock or it suppose to
> be a part of GNURadio?
> http://gnuradio.org/cgit/jblum.git/log/?h=next

Sorry for the confusion, things tend to move fast around here.

Grblock began as a stand-alone project, but my intention was always to
merge it into gnuradio. After all, shouldn't gnuradio, as a de-facto
feature, allow you to write blocks in python?

So, all work on grblock is now on my next branch in gnuradio:
http://gnuradio.org/cgit/jblum.git/log/?h=next
If you checkout and build this branch, you can write blocks in python.

All of the examples have been turned into qa code:
http://gnuradio.org/cgit/jblum.git/tree/gnuradio-core/src/python/gnuradio/gr/qa_block_gateway.py?h=next

> I want to write some blocks in GNURadio that perform the algorithms
> that I had implemented in Matlab for joint source-channel coding, also
> I'm using some basic algorithms for frequency synchronization in
> matlab that I'll implement in GNURadio. Could you please advice me, I
> need some sort of performance, but also I need to implement them asap.
> Which option do you prefer, GrBlock approach or normal GNURadio block
> implementation?
> 

I suppose the intention was to allow the user to make this choice, since
they did not have an option before. :-)

I personally have wanted this feature years ago because I was
comfortable and efficient in python. Now, I suppose, I would prototype a
new block in python because it saves developer time.

0) If I find that the python is too slow for my purposes:
1) I will try first to speed it up with numpy,
2) and if that is too slow, to write the block in c++,
3) and if that is too slow, to make vector optimized blocks in libvolk
4) and if that is too slow, maybe I use the FPGA or just go home.

-Josh

> 
> Thank you for your time, Sergio Pino
> University of Delaware
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio