[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Having problems using forecast method

From: Martin Luelf
Subject: Re: Having problems using forecast method
Date: Tue, 6 Jul 2021 08:03:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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


On 05.07.21 22:51, George Edwards wrote:

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.



On Mon, Jul 5, 2021 at 2:44 PM George Edwards <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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]