a lot of the confusion understanding GR stuff (in particular, data
types) comes from using Simulink, where vector- or samplebased
processing actually is different. There’s a lot of Simulinkers around
here, so I’ve explained this a couple of times
In GNU Radio, the scheduler simply moves binary data from one block to
another. It doesn’t matter whether it’s samples, vectors of samples or
even pink fluffy teddybears (rather, binary representations thereof) as
as they have a fixed size. One binary object of this fixed size is
called an ‘item’. What an item is is up to you to define.
The most common item in GNU Radio is the complex value. Every
item usually has 64 bits (depends on the architecture, but that’s the
most common value) and stores one complex value. All the scheduler cares
about here is the item size. It will reserve a buffer for each edge in
the flow graph to store ‘enough’ items. How much ‘enough’ is depends on
a couple of things, e.g. how many items does my block need to produce
one output item.
So say you have fixed vector length of 10 complex samples. The scheduler
couldn’t care less. All it knows is that you now have an item size of
One important slicer is the vector_to_stream block. This block is much
simpler than you might imagine (judging from what you asked). It takes
two parameters: The vector length (N), and the size (in bytes) of every
item (M). All it pretty much does is copy the input buffer to the output
buffer, but redefines the item size on the output buffer to M, whereas
it was M*N on the input buffer.
The scheduler, which handles the inter-block-buffers, thus know how many
items are stored in the buffer (it’s a ring buffer, to be precise) and
how large they are.
Now say you have a signal source which outputs vectors of 10 samples,
you want to run them through an FIR filter, which operates on individual
This is your flow graph:
SRC ----> Vec2Stream -----> Filter.
Now let’s pretend this is the scheduler order:
- SRC produces 1 item (vector). It is copied to the first buffer.
- Vec2Stream copies the vector to its output buffer.
The SRC output buffer is now empty (because 1 item was copied into
then was consumed by Vec2Stream). The Vec2Stream output buffer
contains 10 items.
- Filter is called and because it’s a weird filter, uses 7 input items.
The Vec2Stream output buffer thus now has 3 items left.
- SRC and Vec2Stream are called with one item each. This produces 10
more items in the Vec2Stream output buffer, which now has 13 items.
And so on.
I’ve been deliberately inaccurate in two respects:
- The GR scheduler does a lot more stuff, and
- there’s another way to pass data (messages).
I hope this was helpful.
On Wed, Mar 02, 2011 at 02:11:38PM +0100, Marius wrote:
gr_vector stuff interacts with the various streams and what “Slicing
and Dicing Streams” (group__slicedice__blk) means. This is important
for me in order to know the data representation and to interpret the
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Phone: +49 721 608-43790
Fax: +49 721 608-46071
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association