[Discuss-gnuradio] Re: GRC: introspection for block data

[Josh Blum]

Patrick,

I like the idea of having dynamic/automatic block importing. It was a 
consideration from the beginning. However, I realized that there was no 
way to "not" have to write some kind of definition for every block. 
After my 0.5 version of GRC, I switched to this current "signal blocks 
defs" format. It has been very versatile and manageable.

I would like to make some blocks automatic, but I do not see a way to 
escape programming in many of the blocks manually. In fact, there are 
many block definitions that are creative and not just a mechanized copy 
of a gnu radio block.

   First, there is the notion of a super block. GRC combines blocks of 
similar functionality but different data types into a "super block". 
Some super blocks represent up to 16 different GNU Radio blocks (just 
based on different data type combos).

Obviously, the add_xx's should all belong to the same super block. 
Because they have infinite inputs, I had to add an Integer parameter to 
the block that controls the number of inputs dynamically. How else can 
GRC know how many inputs to draw?

Even less obvious are the filters. A filter's functionality is actually 
defined by the taps. In GRC, filters of all types are grouped together. 
The actual block represents a particular taps generating method from 
gr.firdes. Therefore, the filters appear as lowpass, highpass, band... 
and each filter can be FIR decimation, xlating fft... A mechanized 
filter implementation would have a separate block for each type (FIR, 
interp, decim, xlating...) and ask the user for a taps array. Assuming 
that the user should not have to enter taps, GRC has a limitation: It is 
not a python script, and you cannot create a taps variable from a 
gr.firdes method.

There is a similar issue with the trellis blocks: GRC does not know 
about fsm data types. It only knows primitive types and arrays of 
primitive types. The trellis blocks work around this by asking the user 
for a file the represents a fsm data type. Then in the signalblockdef, 
this file is converted to a fsm and the actual gnu radio block is 
created using this data type.

   Second, the way to implement callbacks is not 100% mechanized. A 
callback allows you to change a block's parameter during runtime via a 
slider. Some callbacks are obvious: set_samp_rate, set_decim, 
set_ampl.... Some are unnecessary:  changing the noise type from 
Gaussian to Laplace cannot be done because they were chosen from an Enum 
type (a minor detail).

But once again, our friends the filters are unique: Each filter has a 
set_taps method, but you cannot change the taps with a slider. A sider 
can change the cutoff freq, then the gr.firdes taps generator has to be 
called, and then the set_taps method can be called.

   And of course, the graphical blocks are special cases. The 
enumerated choices for audio source/sink rates are special cases. 
Sometimes you may wish to give blocks parameters they do not really have 
(for ease of use) and then do some kind of translation when making the 
gnu radio block.

   Some issues are limitations of GRC, others are done out of 
atheistics and ease of use. We cannot escape manually programming in 
certain blocks. Fortunately, the number of blocks in GNU radio is 
finite, and the time taken to manually add any block to GRC is trivial 
compared to the effort put into the actual block.  

But what about those blocks that are mechanical? They have a 
simple/strait forward correlation between grc implementation and gnu 
radio implementation. Well, the simplest idea that I can think of is 
recording the important information into parse-able doc strings.

@name <canonical name>
@category <category id>
@superblock/family <block family id (optional)>
@inputs <datatype> <num inputs>
@outputs <datatype> <num output>
@param <datatype> <canonical name> <default value (optional)> 
<description (optional)>
@param .........
@param ......
@grc (tells grc that it is good to import)
<description of block>

Of course, the @param's would have to be in the same order as the blocks 
constructor. If a block has inputs of different data types, one could 
have @input  <data type> for each input (same idea for outputs). 
Ignoring GRC, if all blocks had doc strings as above, the quality of the 
documentation of gnu radio blocks would be drastically improved. A 
formal definition for a gnu radio doc string would be good to have (and 
use).

So, either way (manually/automatically), somebody has to write something.

-Josh

I am cc'ing this to the list. Maybe somebody wants to talk docstrings.


Patrick Strasser wrote:
> Hello Josh!
>
> As you may have read on the gnuradio list I'd like to extend grc for
> some introspection capabilities to let find itself out about available
> blocks and it's characteristics. I've already some working code. My idea
> is, not to write all the explicit code in src/SignalBlockDefs but to
> create block descriptions in the fly. For example I've added phase to
> the gr.sig_source blocks, and adding support for phase in grc was quite
> mechanical. Default values are hard coded, too, although blocks expose
> interfaces for reading default values. Finally some blocks, like
> gr.add_xx have unlimited input ports, which has no correspondence in grc.
>
> What do you think about dynamic block exploring (don't know a better
> name for now)?
>
> Patrick