Friday, July 24, 2026

Re: function probes don't work in hierarchical blocks

Hi Eugene, > How would you display the current state (e.g. mean > power from a probe mag^2) your use case sounds very straightforward: use the QT GUI Number Sink. But as explained in my previous email: just write the logic you need. (we might want to wrap this in an off-the-shelf block). I'm attaching a flow graph with three options to solve your problem, on the right half of the flowgraph, top to bottom: 1. straightforward number sink 2. a minimal python block that counts to N items, then emits a message containing the value at that position, repeats 3. a minimal python block that, triggered on an external message, emits the last value as message. To display a message's content, you can use the QT GUI Message Edit Box in "static" mode. Note that you can generate the triggers for the third option inside your hier block (as I'm doing here with the Message Strobe), or use a "Pad Source" to allow the user of your block to trigger externally (for example, manually with a Qt GUI Msg Push Button). Added a disabled Pad Source to clarify that concept. > or probe_rate Probe Rate produces messages. I personally mostly connect that to a Message Debug's Log port and read the console. But I can see where you're coming from! You can write a python block with a input message port with a handler. (see the message-triggered from above for an example). The block would furhtermore have an output message port, and no stream in- our outputs. The handler would do something like def msg_handler(self, msg): self.message_port_pub(self._msport_out, pmt.dict_ref(msg, pmt.mp("rate_now"), pmt.from_float(0.0))) to convert from the dictionary that Probe Rate emits to the rate now message. We might also want a ready-made block that does that for you in general. Best, Marcus

Uploaded Image

Thursday, July 23, 2026

Re: function probes don't work in hierarchical blocks

Maybe I am missing something basic.  How would you display the current state (e.g. mean power from a probe mag^2) or probe_rate in the GUI w/out a function probe?  I create a probe to call level() and then display it as a label.  

Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274

Re: GRC file sink/source name does not honor variables

Oops, that was my mistake!  I left off the quotation marks.

Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274

Wednesday, July 22, 2026

Re: function probes don't work in hierarchical blocks

Hi Eugene, agreed, that's a bit ugly. Unless someone comes up with a very non-intrusive and prettier solution, I'll propose we'll leave it as is: Function Probes are an ugly hack, that has, over the course of time, caused more harm than good. If you need to probe a signal at regular intervals from a sample stream¹, you should probably properly decimate (i.e., low-pass filter with decimation >> 1) or just keep 1-in-N instead. If you really need "random times relative to sample processing, but time controlled by the asynchronous reality of the computer around it", then sending messages into a python block's "trigger" input message port, and that block then sending a (sample index, value) tuple out a "value" message port would solve the same issue, but in a way that's compatible with hier blocks. (subliminal message here: don't rely on function probes. I have not *once* found a good use case for them.) Best regards, Marcus ¹ don't forget that GNU Radio blocks always process samples in larger chunks, so "wall-clock time" has, at best, usually not at all, a very loose relation to signal being probed On 2026-07-21 6:40 PM, Eugene Grayver wrote: > Functions probes don't work in hierarchical blocks. > A function probe generates a thread body such as: > > ------- >         def _cross_freq_estimate_probe(): >           self.flowgraph_started.wait() >           while True: > >             val = self.cross_freq_probe.level() > ------- > > However, hierarchical blocks don't have a member flowgraph_started.  I don't have a simple > suggestion, but perhaps we can pass this member from the parent?  A bit ugly!  Makes the > hier blocks dependent on the rest of the GRC framework — i.e. can't easily reuse in > python-only design flow. > > > Eugene Grayver, Ph.D. > Principal Engineer > 310-336-1274

Tuesday, July 21, 2026

Re: GRC file sink/source name does not honor variables

Re: GRC file sink/source name does not honor variables

On 2026-07-21 12:58, Eugene Grayver wrote:
The GRC file sink/source filename does not support variable expansion.  Is this an intentional decision or a bug?

Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274
I've used full-on python expressions in there in the past, so, if that's no longer working, it's a bug.


GRC file sink/source name does not honor variables

The GRC file sink/source filename does not support variable expansion.  Is this an intentional decision or a bug?

Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274