Hi Marcus,
Thanks for your reply.
> So, you're writing that application and ask us how your buffering works?
> that doesn't sound right, so maybe I'm misunderstanding you?
My bad. What I meant to say was the block that I NEED to implement
involves a fixed number of samples that I need to collect (as long as they are
available) and then start processing those (in my case it is a sliding window).
> 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.
I have been through most of the tutorials. I merely want to make sure I understand
them right. I do understand you may have answered the same questions
lots of times before. Apologies for that :-)
> 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) --
It knows because that is what I specify in the forecast function (for a general block)
am I correct?
> your job as a developer is just writing an algorithm that can work on an
> array of samples that lies sequentially in memory.
So in my case, if I have a sliding window based avg power calculation where
I first buffer up some samples, then calculate power in each window and compare
it to threshold. If in a particular window power < threshold, is there a way to get
GNURadio to immediately replace that window with new data while I slide through
the rest of the input items?
> 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.
I understand what you're saying here.
> 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.
I also understand this. Only question is like I asked above, is there a way to update
new samples in a dynamic way instead of waiting for work to return something?
A case where this might be needed is, if my power never exceeds the threshold,
then nothing will (should) be returned at all.
I am happy to explain further, what i'm trying to implement if necessary.
Thanks for your time
Anil