Dynamically streaming any stream in the flowgraph

When working on a flowgraph I've found myself often wanting to add QT sinks of various sorts to almost every step in the process. This makes for a bit of a cluttered UI, and I always have to stop, add, restart. And then I have to go back and disable or delete them, when no longer needed.

If I understand correctly, gr-ctrlport still needs to have configured all the tap locations ahead of time, and it provides just the latest, not a stream as such?

Looks like gnuradio 4 allows[1] it? I've not tried gnuradio 4 yet.

In the meantime, for my Rust framework, I added the remote ability to discover and stream arbitrary streams in a flowgraph. I also vibe coded having gnuradio export the interface. The code is just a throwaway demo, but a demo that does work.

https://blog.habets.se/2026/10/Inspecting-RustRadio-and-GNURadio-streams-dynamically.html

Will this kind of thing be more natively supported in GNU Radio 4? The use cases for me are:

1. Detachable UI, so that the actual flowgraph can run headless.

2. Arbitrary inspection without needing to add taps to everything manually.

3. Though the "live" version holds on to an SDR, it allows teeing off the raw I/Q for development of the next version, without needing a second SDR.

My question, I guess, is if in general yes this is gr4 territory, and no nobody's interested in making it also work with gr3?

[1] " Runtime plugins allow blocks, schedulers, and related extensions to be discovered from the active installation" — https://wiki.gnuradio.org/index.php?title=GNU_Radio_4.0

--

typedef struct me_s {
 char name[]      = { "Thomas Habets" };
 char email[]     = { "thomas@habets.se" };
 char kernel[]    = { "Linux" };
 char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
 char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

Capture the Flag @ Ingeniería deMuestra

Hi everyone,

Just like every year since 2020, we're organizing a little CTF very much like GRCon's during an exposition event at our University (https://idm.uy/). Since it is completely online, we encourage people from all over to join and play. The only caveat is that it is in Spanish, but many English-speaking people have played it in the past. 

If you're interested, you may read all the details at our webpage https://ctf.idm.uy/ (or directly at https://eva.fing.edu.uy/course/view.php?id=1557&section=1#tabs-tree-start). You may register with a group of up to three people by sending us a mail to ctf@fing.edu.uy.

The deadline to register is Friday of next week, the CTF begins that night and runs for a week.

best

Federico

Re: volunteer opportunity -> IAC2026

Hey GNU-R people,

Following up on this, I'm happy to report that we were able to publish our paper, and will have a team of 3 attending IAC26 in Turkey next week! You can view the Interactive Presentation here.

A massive thank you to my coauthors / contributors from this email list who made it happen. While there's plenty more to do, I'm always truly amazed at what is possible when smart people come together in pursuit of a common goal :).

Ralph

On 5/12/2026 9:10 PM, Ralph Ewig wrote:

Hi Everyone,

I'm heading up OUTLYR Space - a non-profit foundation aiming to be a Global Space Agency. We're working on a space network concept (using GNU Radio), and our 2nd paper was accepted at iac2026.org this year. I'm looking for volunteer help (min 4 hr/week) to complete testing by early October; no pay but you'll be a co-author, and free trip/stay/registration at the conference in Turkey for up to three contributors :). Send me a note if you're interested,  thanks for reading!

Ralph

https://outlyr.space

softlora: a pure-Python LoRa PHY decoder + TinyGS SDR ground station

Hi all,

I wanted to share a project I've been working on this summer as part of
Google Summer of Code 2026 with LibreCube: a pure-Python LoRa physical-layer
receiver (softlora) and an SDR-based TinyGS ground station (tinygs).

softlora decodes LoRa packets from IQ recordings or live SDR streams using
only NumPy/SciPy. Synchronization implements the three-stage CFO/STO estimator in [1], and I ported gr-lora_sdr's frame_sync block as an alternative front-end. It's
tested on synthetic AWGN sweeps, over-the-air captures, and real satellite
passes (SF7-12).

Links:

  Project write-up:            https://studhamza.github.io/hamza-folio/projects/LoRa_tinygs/

  softlora (LoRa PHY decoder): https://gitlab.com/librecube/lib/python-softlora
  tinygs (ground station):     https://gitlab.com/librecube/lib/python-tinygs

Happy to answer questions and get feedback. :)

[1] M. Xhonneux, O. Afisiadis, D. Bol, and J. Louveaux, "A Low-Complexity
    LoRa Synchronization Algorithm Robust to Sampling Time Offsets," IEEE
    Internet of Things Journal, 2021. https://arxiv.org/abs/1912.11344

Cheers,
Hamza Sayed

Re: browser use?

Hi Don, sure, since we even embed it on our gnuradio.org website, we're kind of aware :) No, seriously, thanks for bringing it up. Marc, of pysdr.org and iqengine.org fame wrote that *specifically* to make classroom beginner teaching and individual experimentation easier. Best, Marcus On 2026-09-14 6:23 PM, Don Latham wrote: > I assume the group has found https://gnuradioworld.com <https://gnuradioworld.com/> > Any comments? Useful for us beginners?

browser use?

I assume the group has found  https://gnuradioworld.com

Any comments? Useful for us beginners?

Function arg checking

I was checking some code[1], and found some null pointer deref and other precondition issues.

One interesting pattern was when the use happens in a constructor initializer list, but then the actual check is done in the constructor body.

Any opinions on what pattern should be used, here? One way is to simply move the usage below the check. But that prevents the compiler from enforcing e.g. that d_ted is initialized before d_interp, which uses d_ted, is initialized.

Another way is this:

$ git diff
diff --git a/gr-digital/lib/symbol_sync_ff_impl.cc b/gr-digital/lib/symbol_sync_ff_impl.cc
index 82b5a8036..dbc68a4f1 100644
--- a/gr-digital/lib/symbol_sync_ff_impl.cc
+++ b/gr-digital/lib/symbol_sync_ff_impl.cc
@@ -47,6 +47,15 @@ symbol_sync_ff::sptr symbol_sync_ff::make(enum ted_type detector_type,
                                                           taps);
 }
 
+template <typename C, typename F>
+auto check(C c, F f)
+{
+    if (!c()) {
+        throw std::runtime_error("bleh");
+    }
+    return f();
+}
+
 symbol_sync_ff_impl::symbol_sync_ff_impl(enum ted_type detector_type,
                                          const float sps,
                                          const float loop_bw,
@@ -69,7 +78,11 @@ symbol_sync_ff_impl::symbol_sync_ff_impl(enum ted_type detector_type,
               damping_factor,
               ted_gain),
       d_interp(interpolating_resampler_fff::make(
-          interp_type, d_ted->needs_derivative(), n_filters, taps)),
+          interp_type,
+          check([this] { return d_ted != nullptr; },
+                [this] { return d_ted->needs_derivative(); }),
+          n_filters,
+          taps)),
       d_inst_output_period(sps / static_cast<float>(osps)),
       d_inst_clock_period(sps),
       d_avg_clock_period(sps),

But introducing such a pattern is a bigger stylistic change, and seems like it should be "blessed" as a good pattern before spreading.

This also applies to other UB stuff like glfsr_source_b_impl.cc which shift left by a potentially UB-triggering value before it bounds checks it (also it should not allow 64 exactly, and probably instead needs to special case it).

Opinions?

[1] Well, truth be told I'm asking LLM to "find bugs and UB".

--

typedef struct me_s {
 char name[]      = { "Thomas Habets" };
 char email[]     = { "thomas@habets.se" };
 char kernel[]    = { "Linux" };
 char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
 char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;