discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Notion of buffering up input data in GNURadio


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Notion of buffering up input data in GNURadio
Date: Mon, 25 May 2015 20:48:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Hi Anil

On 05/25/2015 09:03 AM, address@hidden 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 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,
Marcus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]