# Nature of gr\_vector data **URL:** \ **Category:** GNU Radio\ **Created:** [March 2, 2011, 2:13pm UTC](https://www.ruby-forum.com/t/nature-of-gr-vector-data/203961 "2011-03-02T14:13:07Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [March 2, 2011, 2:13pm UTC](https://www.ruby-forum.com/t/nature-of-gr-vector-data/203961/1 "2011-03-02T14:13:07Z")
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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [March 2, 2011, 2:18pm UTC](https://www.ruby-forum.com/t/nature-of-gr-vector-data/203961/2 "2011-03-02T14:18:09Z")
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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [March 2, 2011, 3:15pm UTC](https://www.ruby-forum.com/t/nature-of-gr-vector-data/203961/3 "2011-03-02T15:15:53Z")
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 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