discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Problem with the OOT forecast() method in Python


From: Johannes Demel
Subject: Re: Problem with the OOT forecast() method in Python
Date: Thu, 13 Oct 2022 14:51:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

Hi George,

first a few words of caution. Python blocks are intended for quick tests and incur a serious performance penalty. Thus, they are actually not that well documented in terms of more advanced functionality. Given that `forecast` is generally more of a performance optimization function, this is not surprising. It might be interesting to describe your issue in more detail. What are you actually trying to do? Maybe the `forecast` method is not the thing you actually need to implement.

Please refer to a default implementation for the Python `forecast` method:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L153

Also:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L336
This is another example how to implement the forecast method.

The implementations for sync, decimation, and interpolation blocks are available and do not need to be implemented separately. This would only be necessary for general blocks.

Cheers
Johannes

On 13.10.22 01:00, George Edwards wrote:
Hi Jeff, thanks for bearing with me.

When I retested the last approach just now upon receiving your email it works. Earlier, l forgot to take out some extraneous stuff in my code, which broke it. The code snippet I sent implies a one to one relationship between input and output. The forecaster does its job to ensure the number of input samples is at least the same size as the output, but in many instances the input is larger. This, however, will present a problem to the signal processing algorithm I have in mind which requires the post-pending samples (the size of my filter) to the end to the incoming data before upsampling. It seems the forecaster may be too loose in its input/output sample relationship and will mess up my algorithm.

Anyway, if you have any thought on this and do not mind sharing I would appreciate it.

Thank again for your assistance.

George

On Wed, Oct 12, 2022, 2:58 PM Jeff Long <willcode4@gmail.com <mailto:willcode4@gmail.com>> wrote:

    The last one looks correct, and would not have given the error you
    mention above. What happened?

    On Wed, Oct 12, 2022 at 4:49 PM George Edwards
    <gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>> wrote:

        Hi Jeff, thank you very much for the response.
        I tries:
        ninput_items_required[0]=[noutput_items]
        ninput_items_required=[noutput_items]
        and
        return [noutput_items]
        None of these worked for me.

        Regards
        George

        On Wed, Oct 12, 2022, 8:07 AM Jeff Long <willcode4@gmail.com
        <mailto:willcode4@gmail.com>> wrote:

            For Python, the forecast() function should return a list,
            containing the number of items required for each input.

            On Wed, Oct 12, 2022 at 8:08 AM George Edwards
            <gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>> wrote:

                Hello GNURadio Community,

                I am getting a TypeError when I fill in the code in the
                forecast() method in my Gnuradio OOT block design. I
                know, if I want to interpolate or decimate, I can simply
                pick the block type in the gr_modtool design menu,
                however, I would like to develop the capability to
                design my own. Here is how I fill in the forecast()
                method in Python to do either decimation or interpolation:

                ninput_items_required[0] = noutput_items*self.sps  # for
                decimation
                OR
                ninput_items_required[0] = noutput_items/self.sps  # for
                interpolation

                On running the flowgraph in GRC Console I see TypeError:
                'int' object does not support item assignment.

                Will appreciate any suggestion to fix this problem.

                George

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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