Hi Anil, On 05/29/2015 09:07 PM, Anil Kumar Yerrapragada wrote: > Hi Marcus, > > Thanks for the explanation, it is very clear. > > But is there a way to keep track of time elapsed across *consecutive* > work calls? well, you have the nitems_read() method, which, assuming you have a constant sampling rate coming from some ADC hardware is directly proportional to time. > > Like I said in the first post in this thread, if I have a sliding > window based energy detect. Samples keep coming in, but at some point > I will have to say, right I have enough samples, let me start sliding > my window now. > Then you should make it clear that you need that many samples. Override the forecast() method to give GNU Radio a hint of how many samples you need. Don't consume items until you processed them. > My algorithm is, as long signal energy (or power) in each window is > less than a threshold, do nothing and keep sliding. The moment power > exceeds threshold for the first time, I want to start measuring > time. I need to see how many windows I'm able to slide in the next > let's say, 10 milliseconds (because I expect that the actual signal > transmission( by which i mean not incoming samples, but *useful* > samples) is to last for that long). As a hypothetical example, let's > say by 7 milliseconds I've reached the end of the buffer. You've said that -- still, wall time has no meaning in GNU Radio, and you should just go by the number of samples. > > My understanding is that by calling forecast, you don't call forecast, you implement it. > I am effectively creating an an imaginary (?) array of that many > samples to process. No. GNU Radio calls your block's forecast to ask your block how much input it needs to produce a given amount of output. There's no data involved at this point. > I may be getting many 100s of samples, but if my forecast says only 50 > should dealt with in each work call, then that's how many will be > available. not exactly. Forecast gets called as a question. Your block is asked "I'd like to ask you to produce 512 items. How much input do you need?". If your block then says "I need 400 items", no matter for how many items GNU Radio asks, GNU Radio will first try to reduce the number of items it asks for, and then just stop asking until it has more input items. > > If my understanding is correct, once I reach the end of this imaginary > array, the next set of samples come in (as per forecast) and work is > called again. My question is how do I make this next work call aware > of this concept of time and that 3 milliseconds were unaccounted for > in the last call? > There's no imaginary array. Never wait anywhere in GNU Radio, especially not by 3ms "wall clock time". Let the scheduler decide when and whether to call your work function.
> Is the solution simply to not limit the number of samples in each work > call i.e., not mess around with the forecast function at all? You don't limit the number, you tell GNU Radio to supply at least a specific amount of input items for a specific amount of output items. Again, there's a guided tutorial chapter on this topic [1]. Best regards, Marcus [1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#431-Specific-functions-related-to-block
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
