# Re: Integration of python's time.time() and work() calls **URL:** \ **Category:** GNU Radio\ **Created:** [May 29, 2015, 9:08pm UTC](https://www.ruby-forum.com/t/re-integration-of-pythons-time-time-and-work-calls/242134 "2015-05-29T21:08:02Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [May 29, 2015, 9:08pm UTC](https://www.ruby-forum.com/t/re-integration-of-pythons-time-time-and-work-calls/242134/1 "2015-05-29T21:08:02Z")
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? 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. 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. My understanding is that by calling forecast, I am effectively creating an an imaginary (?) array of that many samples to process. 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. 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? 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? Thanks Anil ---
**Author:** ![anil\_y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/22d042/32.png) [@anil\_y](https://www.ruby-forum.com/u/anil_y)\ **Post date:** [May 29, 2015, 9:39pm UTC](https://www.ruby-forum.com/t/re-integration-of-pythons-time-time-and-work-calls/242134/2 "2015-05-29T21:39:34Z")
Hi Anil, On 05/29/2015 09:07 PM, Anil K. 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](https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#431-Specific-functions-related-to-block)