Re: [Discuss-gnuradio] nature of gr_vector data

[Martin Braun]

Hi Marius,

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 long
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<float> 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
640 bytes.

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, and
you want to run them through an FIR filter, which operates on individual
samples.
This is your flow graph:

SRC ----> Vec2Stream -----> Filter.

Now let's pretend this is the scheduler order:

1) SRC produces 1 item (vector). It is copied to the first buffer.
2) Vec2Stream copies the vector to its output buffer.
   The SRC output buffer is now empty (because 1 item was copied into it,
   then was consumed by Vec2Stream). The Vec2Stream output buffer
   contains 10 items.
3) Filter is called and because it's a weird filter, uses 7 input items.
   The Vec2Stream output buffer thus now has 3 items left.
4) 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.

Cheers,
MB



On Wed, Mar 02, 2011 at 02:11:38PM +0100, Marius wrote:
> Hi!
> 
> I have a general question related to the data-type model.
> 
> I looked through much of the API documentation but it doesn't seem to
> glue together to something what I would describe as a complete
> picture. I want to know how the GNUradio framework actually converts
> the signal into a digital data-type like a vector.
> I'd be satisfied to get a very broad description because I can
> research details on my own. What I'm interested is the way how the
> 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
> results.

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

pgpjKNgigJufF.pgp
Description: PGP signature