[Top][All Lists]

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

Re: Problems when passing messages to a source block

From: Marcin Puchlik
Subject: Re: Problems when passing messages to a source block
Date: Tue, 30 Nov 2021 08:13:31 +0100

Are you mailing with yourself?

wt., 30 lis 2021 o 00:46 Jeff Long <willcode4@gmail.com> napisał(a):
Sounds good. Only look at the C++ to figure out the general idea. I'd learn Python threading first in a standalone program so you're not learning (debugging) GR and python threading at the same time. Good luck - let us know how it goes.

Also, please respond to the mailing list so everyone can benefit from the conversation.

On Mon, Nov 29, 2021 at 5:11 PM Michelle <mkprojects731@gmail.com> wrote:

Hi Jeff,

thank you for your help and sorry for the delay, I was in class.

it is now that I start to work on it. My first step is to master how the c++ code of the strobe message block work, specially the functions:

-bool message_strobe_impl::start()

-bool message_strobe_impl::stop()

-void message_strobe_impl::run()

Then I will implement the python version following your advice. I will write to you to show you the result.

Once again thank you, I was really lost.

Have a good afternoon.

OK, it does work, as long as there is a message port defined and connected in a flowgraph. I was trying too simple an example. You would do your thread management in the start() and stop() functions.

Embedded Python Blocks:

Each time this file is saved, GRC will instantiate the first class it finds
to get ports and parameters of your block. The arguments to __init__  will
be the parameters. All of them are required to have default values!

import numpy as np
from gnuradio import gr
import pmt

class blk(gr.sync_block):  # other base classes are basic_block, decim_block, interp_block
    """Embedded Python Block example - a simple multiply const"""

    def __init__(self):  # only default arguments here
        """arguments to this function show up as parameters in GRC"""
            name='Embedded Python Block',   # will show up in GRC

    def start(self):
        return True

    def stop(self):
        return True

On Mon, Nov 29, 2021 at 2:13 PM Jeff Long <willcode4@gmail.com> wrote:

On Mon, Nov 29, 2021 at 1:58 PM Jeff Long <willcode4@gmail.com> wrote:
It does not seem that python blocks can override start() and stop(), which they should be able to do. So, don't go too far down that path. I do not see anywhere in the code where this is used or would have been caught.

The embedded blocks are easier, be beware that GRC calls the init function to learn about the block. Therefore, you don't want any action taken as a result of a call to init, for instance spawning a thread and starting to send messages. Embedded python block are sort of a toy that turned out to be useful. In general, an OOT is a better idea, but an embedded block can work if it's simple enough.

Maybe someone else has figured this out. With just a quick look, I don't see how a Message Strobe kind of block can be implemented in python without start() and stop().

Here's kind of a hack: make a python block with a message handler that gets a periodic strobe from the existing Message Strobe block. In the handler, send out the message that you would have sent in the thread.

reply via email to

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