[Top][All Lists]

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

Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pur

From: Martin Luelf
Subject: Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks
Date: Mon, 7 Mar 2016 15:40:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 07.03.2016 14:23, Tom Rondeau wrote:
On Sun, Mar 6, 2016 at 6:08 AM, Martin Lülf <address@hidden <mailto:address@hidden>> wrote:

    Dear Tom,

    thanks for your reply.

    I created an account on the gnuradio.org <http://gnuradio.org>
    platform. A day later the account is still disabled, so I assume
    there is a manual confirmation required.

    So I kindly ask somebody on the list with the right permissions to
    activate my account "MartinLuelf" with the same Email address as I
    use for this mailing list.

    Thank you and have a nice weekend eveybody.

I have activated your account.

Hi Tom,

thanks for the activation, I can now log in. However I can't find a button or link to create a new bug/issue. According to the wiki there should be an entry "New Issue" appearing in the navigation, but I can't find it anywhere. Do I need to have additional rights to open tickets?


Now, if someone can get rid of spammers, we wouldn't need to do this...


    On 03/04/16 18:05, Tom Rondeau wrote:

        On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <address@hidden
        <mailto:address@hidden <mailto:address@hidden>>> wrote:

            Dear mailing list,

            we are trying to create a status overview of our receiver
        by using
            the control ports feature. For most of our custom made
        blocks this
            works very well and we can see the exported variables.

            But for a few blocks the exported variables do not show up
        in the
            control port monitor. After putting tracing lines in these
        blocks we
            found out that the setup_rpc function is not called. The only
            difference we could see between the blocks were the setup_rpc
            function is called and the ones where it is not is that
        the latter
            have no stream in- or output. Instead they only use the
            passing API to process data, like the mesage debug block
        from GNURadio.

            A minimal working example of a block whichs setup_rpc()
        method is
            not called can be found at http://pastebin.com/cBFJCnW7
        with private
            and public header files at http://pastebin.com/35WhFqQ0 and

            If we run this block and feed messages to it, we get the
            ControlPort Monitor running.
            INFO: Apache Thrift: -h localhost -p 40444
            monitor::endpoints() = -h localhost -p 40444
            process frame()
            process frame()
            process frame()
            process frame()
            running: ['gr-ctrlport-monitor', 'localhost', '40444']
            process frame()
            process frame()
            process frame()
            process frame()

            We would expect to see an additional line at the beginning
            "setup_rpc()" (see line 71 of the c++ code) and
        consequently see the
            variable "testval" in the control port monitor, like it
        does for our
            working blocks.

            The above output is generated with GNURadio version
   manually compiled from source on an
            trusty system (64 bit).

            The only difference we could find between the blocks
        working as
            expected and the ones that do not, is that they use
        streaming for
            data transport, i.e. that their work or general_work
        function has
            some actual data processing and their gr::io_signature is
        not set to

            I kindly ask for your help to find out why the setup_rpc
        function is
            not called for our example block posted above and what we
        can do to
            change this.

            Yours sincerely
            Martin Luelf


        This definitely sounds like a bug for a case that wasn't
        planned for
        initially. Can you open up a bug report with this information
        on our
        Issue tracker on gnuradio.org <http://gnuradio.org>


reply via email to

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