Notion of buffering up input data in GNURadio

Discuss-gnuradio mailing list
[email protected]

Hi Anil

On 05/25/2015 09:03 AM, [email protected] wrote:

???I have a block that involves collecting samples in a buffer, once
buffer is full, start processing the data (slide a window over it etc

My question is how does this whole concept of buffering work?
So, you’re writing that application and ask us how your buffering works?
that doesn’t sound right, so maybe I’m misunderstanding you?
Can I say I need len(buffer) number of samples (assuming that buffer
is the name of the array over which I slide my window etc) i???n the
forecast function and then just copy input_items[0] into buffer in
every work call? What if in some iterations I don’t need to copy
len(buffer) elements? For example if I only need to copy one or two
window lengths worth data while other windows are still under process.
Can I still do that?
I think you should really read the guided tutorials I’ve linked to in my
last email; you’re trying to replicated functionality that is central to
GNU Radio.
GNU Radio cares for your block’s in- and output buffers. Unless your
work explicitly consumes input items (e.g. by returning a positive
number), GNU Radio accumulates the samples in your input buffer.

My second question is, how do I account for the data that comes in
while I’m still processing data in buffer? Do I need a second buffer
to accumulate subsequent data while processing buffer is full?
Don’t you care, GNU Radio does that for you!
When your work() is called, GNU Radio knows how many items you can
consume (from the input) and how many you can produce (on the output) –
your job as a developer is just writing an algorithm that can work on an
array of samples that lies sequentially in memory.
If you know how much items you need at once (e.g. you always need 127)
you can use set_output_multiple (which will inherently set the input
multiple on a sync block, i.e. any block with a work(), not a
general_work()), and GNU Radio will only call you if there’s at least
127 items of input.

Whilst your block is working on its input, new input might already occur
from the block upstream – that’s no problem at all (in fact, it’s
what’s pretty awesome about the current GNU Radio scheduler). Right
after your current work() call is finished (i.e. has "return"ed), work()
will be called again, with whatever you left untouched of the input from
last time plus the new items.

Best regards,