Forum: GNU Radio How many samples per call to work function?

Hello,
I am going to be making a C++ block which will either change the value 
of a
variable (which would be passed to it by a pointer) or call the tune
function of a USRP sink (passed by a pointer) after a certain number of
samples have been passed to the block. This is related to my question 
here.
<http://old.nabble.com/Tunning-USRP-From-Seperate-C...
order to do this, I need to establish how often the work function is
called. From my past experience writing GNURadio signal processing 
blocks,
it looks like around 8190 samples are passed to the blocks work function
each time it is called, but this tends to vary wildly. Also, I haven't
tested whether this is dependent on data format of the input/output. My
current plan to build the block is to increment a (local, not the on 
being
passed) variable by noutput items each time the work function is called.
Once a certain number of samples have been handled by the block, I will
change the frequency. I was wondering if it is even possible to 
construct a
block with no output or input, and if it is possible whether the work
function would ever get called and whether its noutputitems (or
ninputitems) would correspond to the number of samples flowing through 
the
rest of the flowgraph? If it cant be done this way, I suppose it would 
be
no real issue to give the block an input so that it can count 
ninputitems
then just not do anything with the input items. Just trying to get a 
feel
for the best way to do this and to find out, in general, how frequently 
the
work function of the block is called and how many samples are passed 
with
each call? Thanks!

-Dan

You can put a block in sequence with the samples that does two things in 
the work() function:


1)      copy the input buffer to the output buffer using memcpy or 
something similar since it doesn't look like you need to process the 
samples at all

2)      keep track of "number of samples remaining before re-tune" in a 
local variable that you set to NSAMPS_PER_TUNE, and decrement it by 
noutput items as you described. If this variable gets down to 1 (or 0?) 
re-set it to NSAMPS_PER_TUNE and call the set_command_time() function to 
retune. You'll have to follow the lead of the burst tagging example to 
know precisely what absolute time you need to retune, and you also have 
to make sure the re-tune command gets called with some lead-time, so I'm 
not quite sure how to handle this.

This is just a rough guess of how to do it; I'm sure there are other 
nuances. With this approach you shouldn't need to worry about how many 
samples were passed to your work() function since you always decrement 
your count variable by how many you received.

Hope that helps!

Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On 
Behalf Of Daniel Labarowski
Sent: Friday, June 29, 2012 4:21 PM
To: discuss-gnuradio@gnu.org
Subject: [BULK] [Discuss-gnuradio] How many samples per call to work 
function?
Importance: Low

Hello,
I am going to be making a C++ block which will either change the value 
of a variable (which would be passed to it by a pointer) or call the 
tune function of a USRP sink (passed by a pointer) after a certain 
number of samples have been passed to the block. This is related to my 
question here. 
<http://old.nabble.com/Tunning-USRP-From-Seperate-C... 
In order to do this, I need to establish how often the work function is 
called. From my past experience writing GNURadio signal processing 
blocks, it looks like around 8190 samples are passed to the blocks work 
function each time it is called, but this tends to vary wildly. Also, I 
haven't tested whether this is dependent on data format of the 
input/output. My current plan to build the block is to increment a 
(local, not the on being passed) variable by noutput items each time the 
work function is called. Once a certain number of samples have been 
handled by the block, I will change the frequency. I was wondering if it 
is even possible to construct a block with no output or input, and if it 
is possible whether the work function would ever get called and whether 
its noutputitems (or ninputitems) would correspond to the number of 
samples flowing through the rest of the flowgraph? If it cant be done 
this way, I suppose it would be no real issue to give the block an input 
so that it can count ninputitems then just not do anything with the 
input items. Just trying to get a feel for the best way to do this and 
to find out, in general, how frequently the work function of the block 
is called and how many samples are passed with each call? Thanks!

-Dan

Thanks for the thoughts Sean. I hadn't thought of calling early to give
the tuner time to settle. I'll also have a look at the burst tagger
example as you suggested. I think I should be able to make a block with
only an input and put it in parallel with the other blocks in my
circuit. This should save some processing power in not needing to copy
the samples to the output. I guess what I was really asking was whether
it had to accept samples at all? As in, could a block be made with no
input or output and would its work function be called at a set interval
of time (or even at all)? Probably not a request made often and I don't
think it would take much extra processing power to just feed it the
samples. Still, I thought it was worth looking into.

-Dan

I'm not really sure about whether you can get a work function to be 
called at a set interval. One thing comes to mind though. I suppose you 
could make this block into a data sink that's in parallel with your 
actual data flow. Then you can just use the size of each  incoming 
buffer when work() is called to determine when you need to retune. Just 
ignore the actual incoming data itself.

However, this may not work because the USRP sink/source block is the 
actual object that provides access to the set_command and 
set_command_time methods. Now that I think of it, you may have to edit 
the USRP source/sink block to directly schedule retuning in the work() 
function using an algorithm like the one I mentioned earlier, or else 
enhance it to act on incoming "tune" tags in a similar way to how burst 
commands are done, and then tag samples in an upstream block with the 
"tune" tag. Does that make sense?

Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On 
Behalf Of Daniel Labarowski
Sent: Saturday, June 30, 2012 11:21 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How many samples per call to work 
function?

Thanks for the thoughts Sean. I hadn't thought of calling early to give 
the tuner time to settle. I'll also have a look at the burst tagger 
example as you suggested. I think I should be able to make a block with 
only an input and put it in parallel with the other blocks in my 
circuit. This should save some processing power in not needing to copy 
the samples to the output. I guess what I was really asking was whether 
it had to accept samples at all? As in, could a block be made with no 
input or output and would its work function be called at a set interval 
of time (or even at all)? Probably not a request made often and I don't 
think it would take much extra processing power to just feed it the 
samples. Still, I thought it was worth looking into.

-Dan

On 6/29/2012 7:31 PM, Nowlan, Sean wrote:
You can put a block in sequence with the samples that does two things in 
the work() function:


1)      copy the input buffer to the output buffer using memcpy or 
something similar since it doesn't look like you need to process the 
samples at all

2)      keep track of "number of samples remaining before re-tune" in a 
local variable that you set to NSAMPS_PER_TUNE, and decrement it by 
noutput items as you described. If this variable gets down to 1 (or 0?) 
re-set it to NSAMPS_PER_TUNE and call the set_command_time() function to 
retune. You'll have to follow the lead of the burst tagging example to 
know precisely what absolute time you need to retune, and you also have 
to make sure the re-tune command gets called with some lead-time, so I'm 
not quite sure how to handle this.

This is just a rough guess of how to do it; I'm sure there are other 
nuances. With this approach you shouldn't need to worry about how many 
samples were passed to your work() function since you always decrement 
your count variable by how many you received.

Hope that helps!

Sean

From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org<mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org> 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On 
Behalf Of Daniel Labarowski
Sent: Friday, June 29, 2012 4:21 PM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: [BULK] [Discuss-gnuradio] How many samples per call to work 
function?
Importance: Low

Hello,
I am going to be making a C++ block which will either change the value 
of a variable (which would be passed to it by a pointer) or call the 
tune function of a USRP sink (passed by a pointer) after a certain 
number of samples have been passed to the block. This is related to my 
question here. 
<http://old.nabble.com/Tunning-USRP-From-Seperate-C... 
In order to do this, I need to establish how often the work function is 
called. From my past experience writing GNURadio signal processing 
blocks, it looks like around 8190 samples are passed to the blocks work 
function each time it is called, but this tends to vary wildly. Also, I 
haven't tested whether this is dependent on data format of the 
input/output. My current plan to build the block is to increment a 
(local, not the on being passed) variable by noutput items each time the 
work function is called. Once a certain number of samples have been 
handled by the block, I will change the frequency. I was wondering if it 
is even possible to construct a block with no output or input, and if it 
is possible whether the work function would ever get called and whether 
its noutputitems (or ninputitems) would correspond to the number of 
samples flowing through the rest of the flowgraph? If it cant be done 
this way, I suppose it would be no real issue to give the block an input 
so that it can count ninputitems then just not do anything with the 
input items. Just trying to get a feel for the best way to do this and 
to find out, in general, how frequently the work function of the block 
is called and how many samples are passed with each call? Thanks!

-Dan