Hi Martin,
Thank you very much for the detailed response. Like I indicated, I
experimented and found a work around by leaving out the forecast method
and in the general_work method, I simply get the value of the number of
input samples and scale it to get the precise number of outputs and
reset Gnuradio noutput_items[0] to match and it works. But I would love
to learn how to also use the forecast method and have the same OOT work.
Here is a simplified version of my OOT code using the forecast method
and it works sometimes in the QA test which is not good. In this OOT I
am feeding in a stream of data and output a stream. In this exampleI I
choose M=4 and N=2 to be small numbers and M/N =2 was an integer (my
true algorithm has M and N in the hundreds and M/N is not an
integer, but would be a decimal value). This simple algorithm, reads the
input in group of 4 values and output the first two values in the group.
I will list my results when I run the QA test! Here is the Python code:
In the general_work method I have:
in = input_items[0]
out = output_items[0]
jj =0
for n in range(0, len(in)-4, 4): # read in 4 samples at a time so M=4
input = in[n:n+4]
for k in range(0,2)
out[jj] = reg[k] # write to output to the
first 2 input samples, N=2
jj = jj+1
self.consume(0, len(input_items[0]))
return len(output_items[0]) ,
In the forecast method for loop, I set input_items_required[i] =
noutput_items*M/N where M=4 and N =2
I ran the QA test with input vectors [0,1,2,3], then [0,1,2,3,4,5,6,7]
and the outputs were [0,1] and [0,1,4,5], respectively which are correct.
When I changed the QA input vector to [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11] (so now the output should be [0,1,4,5,8,9]). The QA test bombs and
stated: handler caught exception: index 4 is out of bounds for axis 0
which is size 4. I inserted some print statements inside
the general_work method to see the values for ninput_items and
noutput_items and the ninput_items was 12 (the size of the input vector
in the QA test) and noutput_items was 4. noutput_items was
4 explains why the program bombs because out[jj] with jj = 4 means I am
attempting to place a value in out[4] which does not exist because
noutput_items is 4. Based on the settings in the forecast method, I was
expecting that if the scheduler set noutput_items to 4, then it would
set ninput_items to 4*M/N = 8 and the program would not bomb, it would
work perfectly. Then in the next scheduler round, the last 4 samples
would be brought in for processing.
Any ideas on how I can fix the simple program above so I can use the
forecast method and get it to work?
Thanks again for your help.
George
On Tue, Jul 6, 2021 at 1:04 AM Martin Luelf <mail@mluelf.de
<mailto:mail@mluelf.de>> wrote:
Dear George,
what specifically does not work with your test? Any error messages, or
is it not producing the result you are expecting. And if so, what is
your block input, what is the output and what output are you expecting?
Keep in mind that the forecast method tells the scheduler how much
input
you *likely* need. This is not binding, meaning the general_work method
does not have to produce this number of outputs, nor does GNURadio have
to give you that exact amount of input data. In the general_work method
you need to tell the scheduler how many samples you used (using the
consume method) and how many samples you created (by returning that
number).
Also be aware of the data types in C++. noutput_items is an int. If M
and N are integer types as well, C++ will round M/N to the nearest
integer before multiplying it to noutput_items and you have effectively
created an integer decimating block. To avoid that you want to cast
M, N
and noutput_items to a floating point number type (if you know the C++
specifics you can probably get away with just casting one type and have
the compiler cast the others, but just to be sure I would cast them all
to float). With that you will get a floating point number of samples
that your block needs. Since GNURadio can only deal with an integer
number of samples, it is up to you and your algorithm to bring that
to a
sensible integer number. Most likely you will want to round that number
up or down and feed this integer number of samples back into
ninput_items_required[0].
Yours
Martin
On 05.07.21 22:51, George Edwards wrote:
> Hello,
>
> I played with it and got it to work. I left out the forecast
method and
> forced my will on the scheduler in terms of the input to output
> sample relationship.
>
> However, I am still open to hearing from anyone who has used the
general
> block with the forecast method to solve this problem, so as to
have the
> perspective on how to use the forecast method.
>
> Thanks!
>
> George
>
> On Mon, Jul 5, 2021 at 2:44 PM George Edwards
<gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>
> <mailto:gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>>>
wrote:
>
> Good afternoon GNURadio community!
>
> I am having a problem using the forecast method in my OOT model.
>
> In my model, I have one input port and one output port with
> streaming data. My signal processing algorithm converts every M
> input samples into N output samples where the ratio of M to N
is a
> floating point number, soI cannot use the sync block (if
M=N) nor
> the interpolator or decimator OOT blocks.
>
> I am forced to use the general or basic block which has
theforecast
> method where one has to inform the Scheduler of the relationship
> between the input and output samples.
>
> In the forecast method, I set up the relationship as:
> ninput_items_required[i] = noutput_items*M/N
> which is the precise relationship. However, on running the QA
test I
> cannot get the OOT module to work properly.
>
> Will appreciate any suggestions!
>
> Regards,
> George
>