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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
