European GNU Radio Days/2025
The EU GR days 2025 are taking place in Lyon, July 16–18 (incl.)
Invitation
Dear GNU Radio Community, After the previous years' European GNU Radio Days, and following popular demand, we announce a lighter version for 2025 that will take place July 16-18 in Lyon, France, in Inria/INSA Lyon's CITI laboratory. This time, to reduce the organization load while still providing a venue to meet and chat around GNU Radio in Europe, there won't be dedicated tutorial and presentation talk tracks. The goal is to get together in a room to develop/design, on/with GNU Radio, brainstorming together on possible features and improvements. It is also an opportunity for those interested to visit and start playing with the SLICES/CorteXlab SDR testbed that we have in the lab, for reproducible and remote radio experiments. Beginners are, of course, welcome for those who want to work on their own project, on the wiki's tutorials,... in an stimulating environment with other GNU Radio enthusiasts. As mentioned above, this will take place in France, in the Doua Campus of Lyon's metropolitan area: 6 avenue des Arts, 69100 Villeurbanne, France. It's easily accessible by public transport from the city center (mostly tram T1 and T4) Registration will be free as this is an informal meeting, but please tell us if you plan to come so that we can book the right number of rooms. See you in Lyon, -- Cyrille MORIN Ingénieur SED Équipe MARACAS
Logistics
Location
A mentioned in the invitation email, it will be held in the ground floor of the Hedy Lamarr building, 6 avenue des Arts, 69100 Villeurbanne, France.
Currently, one room is booked, but we will be able to use another one if we want to split subjects without too much interferences.
We will operate from 9h to 17h (or more if we get too invested in discussions)
Planning
The exact planning will be flexible and depend on the inclinations of the attendees, but here is a tentative one. Feel free to criticize it!
| Date | Morning | Afternoon |
|---|---|---|
| Wednesday 16 |
|
|
| Thursday 17 | CorteXlab Visit and Tutorial |
|
| Friday 18 |
|
|
| Date | Morning | Afternoon |
|---|---|---|
| Wednesday 16 |
|
|
| Thursday 17 | CorteXlab Visit and Tutorial |
|
| Friday 18 |
|
|
Discussion
Wednesday Morning
- Re Wednesday "Latency" work: I can sure present a bit on that, but it really only makes sense to assign a whole half-day to it if someone else at the end of talking about it is able to take up the torch and drive the issue afterwards for weeks to months, until we can merge the result into GNU Radio – I'd love to drive it, but I'm already too busy with other things in GNU Radio. So, really, this is a team-finding thing. Whoever drives the issue afterwards need not be super technically involved, but needs to be able to coordinate with me and other stakeholders.
Topics
As announced, the organizers will not try to set up a talk track or something; it's a hackathon thing, and everyone is encouraged to coordinate topics with others. Thus, let's collect topics here:
Topic Template
- Champion
- Sarah D. Topicbringer
- Level
- Intermediate (or entry-level, or expert)
- Scope
- 0.5 days
Description
Let's talk about topic, which happens a lot in turboencabulators.
Desired Outcome
Code to turboencabulate to effectively prevent sinusoidal deplanaration.
Q&A
Will we talk about longitudinal error amplification codes? ~Carl
- not my area of expertise, but if you want to, that'd be cool! ~Sarah
- Sure, I'll bring a 20 min slideset! ~Carl
Managing Latency
- Champion
- Marcus Müller (might try to convince Derek to come)
- Level
- Expert to Intermediate
- Scope
- 1.0 to 1.5 days
Description
There's a transmit-token based approach to managing latency that Derek together with Matt designed a few years back.
It would be nice to integrate it into GNU Radio, such that it becomes universally available.
A first step might be something like a message listener in gr::block on the system port, which can be "programmed" to ensure nitems_written(x) <= last_value_received + max_nr_of_samples_in_flight. This warrants discussion.
Desired outcome
Prototype, and a champion to drive the change.
Q&A
None yet.
The GNU Radio 3 runtime locking clustershamble
- Champion
- Marcus Müller
- Level
- Expert++
- Scope
- 1.5+ days
Description
Changes like adding functionality to get one, and exactly one, tag from this input based on this tag filter function passed in, which would mean a large reduction of memcopy & CPU load in tag handling blocks, are blocked.
This is due to locking of buffers, tag structures, the Python GIL and other parts of GNU Radio not being well-designed.
Especially, everything related to block_detail does one large "mega-lock", regardless of whether it's reading or modifying access.
This needs to be overhauled.
Desired outcome
Plan for granular locking that allows multiple concurrent read accesses to tag structures, doesn't conflate tag structure locking with ring buffer locking
Q&A
None yet.
Improving CI infrastructure brainstorm
- Champion
- Marcus Müller + X
- Level
- Intermediate to Expert
- Scope
- 1h to 0.5 days
Description
Currently, we have pretty slow CI running on github actions on free github runners.
How do we approach getting things faster?
Desired outcome
Direction to go
Q&A
None yet.
The SLICES/CorteXlab radio testbed
- Champion
- Cyrille Morin
- Level
- Entry-level to Intermediate
- Scope
- 2h to 0.5 days
Description
We have in the basement an RF isolated room full of SDRs for radio experiments, the SLICES/Cortexlab testbed. It's freely and remotely accessible. We would be happy to present it to you, go through the tutorials with the attendees, and discuss ideas of uses you might have for it, or changes you might want from it.
Desired Outcome
Have interested people get to know the platform and how to use it. Foster new uses for it.
Q&A
None yet.
Hardware in the loop CI (with CorteXlab or other)
- Champion
- Cyrille Morin
- Level
- Intermediate to Expert
- Scope
- 1h to 0.5 days
Description
The current CI works for stuff that can be tested with just software, but there might be features that can only be tested with hardware in the loop. Turns out we have a publicly available platform with (currently only) USRPs, guaranteed without interference, and remotely accessible with automated deployment.
Would it make sense to setup a semi automated CI pipeline to test some flowgraphs in Cortexlab? What features would we want to test?
Desired Outcome
Answers as to the relevance of this approach. If relevant, some kind of prototype pipeline.
Q&A
None yet.
Next generation remote GUI
- Champion
- Cyrille Morin
- Level
- Intermediate to Expert
- Scope
- 1h to 0.5 days
Description
The current "official" way to get remote display of plots and interaction with GUI elements is through gr-bokehgui. That works but has a number of limitations, including plot quality, ease of use of the underlying bokeh library, and most importantly refresh rate in the browser (with more than a couple of plots)
What would be the future remote GUI library? - Improvements of the existing bokehgui? - Some other remote display lib? Like netImgui ?
We have paradigm issues about gnuradio display plots currently, like the waterfall. What should a display behave like?
Outcome
Quite some discussions about how a future system should handle showing "oscilloscope like" or Fosphor like displays showing stats (not histograms) of signal instead of current state at display time.
For bokehgui, we probably keep it as the RemoteGUI for GR 3. And Imgui is a very good candidate for GR4.
There are still some things that can be tried out in bokehgui, such as improving the waterfall behaviour
Q&A
None yet.
GR 4.0 progress and evolutions
- Champion
- Ralph Steinhagen
- Level
- Intermediate to Expert
- Scope
- 1h to 0.5 days
Description
Exchange ideas on how GNU Radio 4.0 could evolve into a key enabler and as a foundation for use in public critical infrastructure and industrial applications. Funding opportunities, both in Europe and in North America, ties to strengthen.
Desired Outcome
Direction to go If relevant, some kind of prototype
Q&A
None yet.
GR 4.0 SYCL integration
- Champion
- Ralph Steinhagen
- Level
- Intermediate
- Scope
- 1h to 0.5 days
Description
- Surprisingly easy and conceptually easy to integrate into GR4 block structure that intuitively handles the host->device & device->device transfer (via existing 'std::allocator' interface in CircularBuffer)
- Stand-alone FFT seems to be a poor candidate for acceleration on the GPU (at least for N < 1M, O(N logN), -> O(n^2))
- Probably will be tackling SVD or similar -- 💡💡 ideas and suggestions are welcome 💡💡 (MVPs)
Desired Outcome
PoC
Q&A
None yet.
GR 4 FFT-simd clean-up
- Champion
- Ralph Steinhagen
- Level
- Beginner to Intermediate
- Scope
- 1h to 0.5 days
Description
Mostly mechanical
- Matthias gave some helping snippets that should make the pfFFR code even more portable, cleaner/leaner, and that I wanted to integrate
- Extend support for N=prime numbers (via Bluestein's algorithm - from our existing implementation)
- Have a look at the existing FFT performance benchmark and results
Desired Outcome
Work done
Q&A
None yet.
GR 4 ONNX integration
- Champion
- Ralph Steinhagen
- Level
- Beginner to Intermediate
- Scope
- 1h to 0.5 days
Description
Looking for a simple, yet meaningful use-case, e.g.
- multiple peak-detector
- more toy/demos:
- speech-to-text: e.g. via whisper https://github.com/openai/whisper
- text-to-speach: e.g. via https://github.com/coqui-ai/TTS
- DNN, CNN, ... 💡💡 ideas and suggestions are welcome 💡💡 (MVPs)
Desired Outcome
PoC level
Q&A
None yet.