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?
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].