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