Nature of gr_vector data

GNU Radio
1

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.

Best,
Marius

2

On 02-03-11 14:11, Marius wrote:

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.

It all depends on what you want to do i guess. I’ve learned a lot about
gnuradio by playing with the gnuradio-companion ‘grc’. It makes it
really easy to drag and drop a SDR solution together. And if things are
not clear, i grep the sources for the specific method name.

Gr. Sim

3

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 :slight_smile:

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 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:

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 B.
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