Questions to set up Gnuradio for windows WSL

Dear GNURadio Community,

In the past I had a GNURadio binary running on Windows and was able to access the HackRF hardware via the USB port to Tx/Rx signals. The problem is I could not build OOT modules. I bought a new Windows PC recently and wish to build OOT modules for GNURadio on it and I read that Windows WSL will do the trick, here are my questions:

Q1. Which is best: WSL1 or WSL2 (I read this is like a Virtual Machine)? 

Q2. Running inside WSL1 or WSL2, will I be able to access the USB port directly as before (to Rx/Tx signals via HackRF)?

Thank you!

George

Re: GNU Radio with UHD 4.8

Hi Steve,

the UHD version that your hardware (N320) is on and the library version you're using on
your PC must be the same.
And: the version of UHD that your GNU Radio was built against must be the same that you're
currently using.

So, solution here is:
1. Uninstall UHD 4.6 from your PC. This will hopefully uninstall GNU Radio linked against
that version (depends on how you installed both!).
1.1 if the above did not uninstall GNU Radio, uninstall GNU Radio
2. Install UHD 4.8
3. Build GNU Radio against that version of UHD.

If you tell us what operating system you're on and how you installed UHD and GNU Radio on
it, we might be able to help you with these steps :)

Best regards,
Marcus

On 4/1/25 11:59 PM, Steve Hamn wrote:
> Hi,
>
> I just upgraded my Ettus N320 from UHD 4.6 to UHD 4.8 and am getting the MPM Mismatch
> error now with GNU Radio. What do I need to do to get GNU radio working again with UHD 4.8
>
> Thanks
>
> Steve

GNU Radio with UHD 4.8

Hi, 

I just upgraded my Ettus N320 from UHD 4.6 to UHD 4.8 and am getting the MPM Mismatch error now with GNU Radio. What do I need to do to get GNU radio working again with UHD 4.8

Thanks

Steve

Re: GNU Radio Companion Video Creation Toolkit (GSoC proposal)

Hi Andrej,

Thank you for getting back to me. I see what you mean, yeah the content creation community is rather small at the moment. I do have one other idea that I've been thinking about, it'd be an OOT module but it's something that a few communities I'm part of have mentioned interest in and I think might be worthwhile: ft8/WSPR implementations. 

Corey had made this a few years ago: https://github.com/ckoval7/automate_ft8

and my idea is in a similar vein. Whereas he is focused on automating QSOs this would be more creating a modular/reusable FT8 OOT module for GNU Radio. Basically let people incorporate FT8 functionalities into their custom GNU Radio applications. There would have to be two main parts: encoding and modulating FT8 messages then demodulating and decoding, an integrated FT8 modem would be the end goal essentially. I'd expect gr-digital and gr-fec to be basically the main parts of GNU radio I'd use right now. But yeah this is the general skeleton of what I'm thinking, I can write up a super detailed proposal like last time if you'd like, let me know.

I will need to do some homework if you think this is a good idea though, April 8th is the deadline so hope to talk soon!

Daniel 

P.S. If you think this is too large a project/not the greatest idea, I'm open to the "Revitalize in-tree and out-of-tree (OOT) modules" project idea as well. Not having support for some of these is probably annoying for a lot of people so I see the value of the idea. I'd just appreciate more details when the time comes around. 

On Tue, Apr 1, 2025 at 4:55 AM Andrej Rode <arode@gnuradio.org> wrote:

Hi Daniel,

Sorry for the late response, we have looked at your proposal and discussed about the idea and implementation.
Generally your idea seems worthwhile, for the GNU Radio project we are mostly lacking content regardless of the form.

So if we have a great tool to create videos with GNU Radio we would still need someone to do that. And generally we are lacking the "someone".
Another point is that this proposal is quite large and complex in nature and needs a lot of integration with existing parts of the project. I think many of those features
are already sufficiently captured with screen recording.  Coming back to the point that we are still lacking content production and not the means of it.

Thanks for creating such a detailed idea proposal, maybe there  is some other topic that interests you and you want to implement within GNU Radio?

Cheers,
Andrej

> On 13. Mar 2025, at 02:04, Daniel Paul <danielpaul1221@gmail.com> wrote:
>
> Personal Information
> Name: Daniel Paul
> Location: Winnipeg, Manitoba, Canada
> Email: danielpaul1221@gmail.com
> University: University of Manitoba
> Degree Program: B.Sc. in Data Science (minor: Chemistry), expected April 2025
> GSoC Project Duration: Full-time, 350 hours over 12 weeks
>  GNU Radio Companion Video Creation Toolkit (GSoC idea)
> So the idea I have is to develop a GNU Radio Video Creation Toolkit that streamlines the process of creating high-quality YouTube videos and tutorials demonstrating GNU Radio flowgraphs, SDR experiments, and signal processing concepts. This toolkit will integrate flowgraph exporting components, visualization, screen recording, dynamic annotations, and video post-processing to provide a more seamless content creation experience.
> So quick about me: I'm a data science student and I have my HAM advanced and basic radio licenses. I also have a RTL-SDR and a HackRF One dongle. Finally, I also have created videos for my youtube channel related to SDR stuff that you can see below. https://www.youtube.com/@agarauproductions
> Also, one point I'll make, this isn't an SRS so if you're going to ask about specific implementation details, while I might have ideas, I haven't fleshed them out just yet -- but I've given general directions I hope to go in.
> Now back to the idea.
> Deliverables (to be discussed with mentor on how many to focus – all would be amazing though):
> 1.       High-Quality Flowgraph Exporting
> ·       Generate formatted screenshots and animated sequences of GNU Radio flowgraphs.
> ·       So, imagine if you can extract high quality images of each component you're building out, ie. extract each block and arrow. Each part without the background associated with it, so you can just pick out the parts you want to export, and you can keep those in the highest quality so no more of those pesky screenshots if you don't want them. And give an option to be more colourful than just white/back when you export.
> 2.       Screen Recording with Interactive Overlays
> ·       Capture screen activity with real-time annotations (e.g., highlighting, text pop-ups, guided steps). Of course, existing tech allows you to draw on top of anything on your screen, but if this was embedded in GNU that would be super useful for tutorials.
> 3.       Signal Visualization Recording
> ·       Capture real-time spectrograms, FFTs, and time-domain plots directly from GNU Radio. Again just export them directly, in fact I saw the CyberEther project, maybe they could embed some of those useful features here too, overall just making the lives of tutorial makers easier.
> 4.       Automated Narration & Voice-over Syncing
> ·       Enable voice recording and auto-align narration with flowgraph execution steps. Again, this is possible but if you treat this as step 2a then you don't have to worry about manual synchronization anymore.
> 5.       *Template-Based Scripted Video Creation
> ·       Offer reusable templates for common tutorial structures, including recorded steps and visual aids. *I haven't really worked this one out yet, but sort of implementation of this would be useful though. I hope I can talk more about this with someone.
> 6.        Export Features
> ·       A way to export the things I previously mentioned with Youtube and existing major products that are free to use. The idea being support the open source community while also making these steps easier overall for everyone.
> Benefits to the Community
> Creating tutorials and educational content for GNU Radio currently requires so much manual effort, including taking screenshots, editing videos, and syncing voiceovers. This toolkit will significantly reduce the time and complexity here. If we make video creation more accessible, it will encourage more people to share their expertise and increase the adoption of GNU Radio and just support the community in general.
> 
> Tech stack (most likely): Python, OpenCV, FFmpeg, PyQt.
> What the ideal schedule looks like:
> Phase 1 (Week 3-6)
> Implement flowgraph exporting features and initial screen recording capabilities.
> Phase 2 (Week 7-10)
> Develop automated narration, voice-over syncing, and visualization recording.
> Final Phase (Week 11-12)
> Complete template-based video creation, finalize documentation, and test stability.
> 
> 
> Background & Coding Experience
> I am a Data Science student at the University of Manitoba with a strong background in machine learning, software development, and signal processing. I hold an Advanced Amateur Radio Certification and have hands-on experience with RTL-SDR and HackRF One. Additionally, I create SDR-related educational content on my YouTube channel: Agarau Productions.
> Relevant Projects
>     • Machine Learning for MRI Classification: Developed a CNN-based model for early-onset Alzheimer's detection.
>     • Biometric AI (Displaid): Applied signal processing techniques to analyze raw voltage signals.
>     • SSIS Data Pipeline Development: Built an automated data migration and processing pipeline in SQL and Python.
> I have read and understood the three strikes rule and GNU Radio's guidelines
> Secret Code Word: Cyberspectrum is the best spectrum.
>
> Hope to talk with someone about this!
> Thank you,
> Daniel

Re: GNU Radio Companion Video Creation Toolkit (GSoC proposal)

Hi Daniel,

Sorry for the late response, we have looked at your proposal and discussed about the idea and implementation.
Generally your idea seems worthwhile, for the GNU Radio project we are mostly lacking content regardless of the form.

So if we have a great tool to create videos with GNU Radio we would still need someone to do that. And generally we are lacking the "someone".
Another point is that this proposal is quite large and complex in nature and needs a lot of integration with existing parts of the project. I think many of those features
are already sufficiently captured with screen recording. Coming back to the point that we are still lacking content production and not the means of it.

Thanks for creating such a detailed idea proposal, maybe there is some other topic that interests you and you want to implement within GNU Radio?

Cheers,
Andrej

> On 13. Mar 2025, at 02:04, Daniel Paul <danielpaul1221@gmail.com> wrote:
>
> Personal Information
> Name: Daniel Paul
> Location: Winnipeg, Manitoba, Canada
> Email: danielpaul1221@gmail.com
> University: University of Manitoba
> Degree Program: B.Sc. in Data Science (minor: Chemistry), expected April 2025
> GSoC Project Duration: Full-time, 350 hours over 12 weeks
> GNU Radio Companion Video Creation Toolkit (GSoC idea)
> So the idea I have is to develop a GNU Radio Video Creation Toolkit that streamlines the process of creating high-quality YouTube videos and tutorials demonstrating GNU Radio flowgraphs, SDR experiments, and signal processing concepts. This toolkit will integrate flowgraph exporting components, visualization, screen recording, dynamic annotations, and video post-processing to provide a more seamless content creation experience.
> So quick about me: I'm a data science student and I have my HAM advanced and basic radio licenses. I also have a RTL-SDR and a HackRF One dongle. Finally, I also have created videos for my youtube channel related to SDR stuff that you can see below. https://www.youtube.com/@agarauproductions
> Also, one point I'll make, this isn't an SRS so if you're going to ask about specific implementation details, while I might have ideas, I haven't fleshed them out just yet -- but I've given general directions I hope to go in.
> Now back to the idea.
> Deliverables (to be discussed with mentor on how many to focus – all would be amazing though):
> 1. High-Quality Flowgraph Exporting
> · Generate formatted screenshots and animated sequences of GNU Radio flowgraphs.
> · So, imagine if you can extract high quality images of each component you're building out, ie. extract each block and arrow. Each part without the background associated with it, so you can just pick out the parts you want to export, and you can keep those in the highest quality so no more of those pesky screenshots if you don't want them. And give an option to be more colourful than just white/back when you export.
> 2. Screen Recording with Interactive Overlays
> · Capture screen activity with real-time annotations (e.g., highlighting, text pop-ups, guided steps). Of course, existing tech allows you to draw on top of anything on your screen, but if this was embedded in GNU that would be super useful for tutorials.
> 3. Signal Visualization Recording
> · Capture real-time spectrograms, FFTs, and time-domain plots directly from GNU Radio. Again just export them directly, in fact I saw the CyberEther project, maybe they could embed some of those useful features here too, overall just making the lives of tutorial makers easier.
> 4. Automated Narration & Voice-over Syncing
> · Enable voice recording and auto-align narration with flowgraph execution steps. Again, this is possible but if you treat this as step 2a then you don't have to worry about manual synchronization anymore.
> 5. *Template-Based Scripted Video Creation
> · Offer reusable templates for common tutorial structures, including recorded steps and visual aids. *I haven't really worked this one out yet, but sort of implementation of this would be useful though. I hope I can talk more about this with someone.
> 6. Export Features
> · A way to export the things I previously mentioned with Youtube and existing major products that are free to use. The idea being support the open source community while also making these steps easier overall for everyone.
> Benefits to the Community
> Creating tutorials and educational content for GNU Radio currently requires so much manual effort, including taking screenshots, editing videos, and syncing voiceovers. This toolkit will significantly reduce the time and complexity here. If we make video creation more accessible, it will encourage more people to share their expertise and increase the adoption of GNU Radio and just support the community in general.
>
> Tech stack (most likely): Python, OpenCV, FFmpeg, PyQt.
> What the ideal schedule looks like:
> Phase 1 (Week 3-6)
> Implement flowgraph exporting features and initial screen recording capabilities.
> Phase 2 (Week 7-10)
> Develop automated narration, voice-over syncing, and visualization recording.
> Final Phase (Week 11-12)
> Complete template-based video creation, finalize documentation, and test stability.
>
>
> Background & Coding Experience
> I am a Data Science student at the University of Manitoba with a strong background in machine learning, software development, and signal processing. I hold an Advanced Amateur Radio Certification and have hands-on experience with RTL-SDR and HackRF One. Additionally, I create SDR-related educational content on my YouTube channel: Agarau Productions.
> Relevant Projects
> • Machine Learning for MRI Classification: Developed a CNN-based model for early-onset Alzheimer's detection.
> • Biometric AI (Displaid): Applied signal processing techniques to analyze raw voltage signals.
> • SSIS Data Pipeline Development: Built an automated data migration and processing pipeline in SQL and Python.
> I have read and understood the three strikes rule and GNU Radio's guidelines
> Secret Code Word: Cyberspectrum is the best spectrum.
>
> Hope to talk with someone about this!
> Thank you,
> Daniel

Re: Potential GSoC 2025 Contributor: FM Broadcast Radio application

Hi Hamza,

I've had a look initially but forgot to get back to you - basically your proposal looks pretty solid.
For some of the things (in particular) SCA it would be good to check where in the world this kind of signal is still added
to FM (I mostly found references to the U.S. and Canada) and if it is easy to get some recordings from there to
replay into your implementation of the decoder.

Initially I haven't considered implementation of SCA decoding and this slightly increases the scope of the project (I haven't found out if gr-rds already supports this). There seems a mention in a Doxygen file, but there is no reference in code or the git history. I suppose the original author planned to add this, but never actually implemented SCA.
With this I think it fits well to the medium size (175 hours) project.

As for the questions I thinks you described the features well and also length & timeline work out well.
Some of the technical (implementation) details we can discuss after the ideas have been accepted, I think for the proposal it's good enough right now.
Overall I was proposing this project to also show some example of how to implement an application using GNU Radio, e.g. also interacting with flowgraphs & doing flowgraph "management" programatically. So, not just creating and using flowgraphs in a GUI, but possibly creating & changing flowgraphs in Python code, since this gives you a lot of flexibility for your applicatiion. But as said, this is more of a technical implementation detail :)

Cheers,
Andrej


> On 27. Mar 2025, at 11:57, Hamza Mohammed <hamza.mohammed.hasan@gmail.com> wrote:
>
> Hello Andrej,
>
> Looks like you forgot about my email :(. That's fine, I have been chatting with the community on the Matrix Channel about my proposal, they suggested some features and improvements. Anyway I would really appreciate it if anyone on the mailing list would give me some insight on my proposal. It's a 5 min read :(, I think it's long, what do you all think?
>
> I would appreciate feedback on,
> • Features section: Are the features described clear enough ?
> • Length of the proposal. I think I have over explained things, while listing others. What do you all think?
> • Schedule timeline: is it detailed enough? Did I distribute the workload correctly?
> • Any other insight regarding the technical aspects of the project.
> Note: I have been working on the proposal for a long continuous time, so my brain might have messed it up. Like writing the same feature twice, but I can't catch these errors right now. So please don't be harsh; it's still not my final proposal.
>
> Thank you all for your time, looking forward to hearing from you. Here is the link https://drive.google.com/file/d/1xfNUaqoVEJZsA6IwxyMyXo3EezP3P3zy/view?usp=drive_link
> Sincerely,
> Hamza
>
> On Mon, 17 Mar 2025 at 00:23, Andrej Rode <arode@gnuradio.org> wrote:
> Hi Hamza,
>
> thanks for your interest in participating in the GNU Radio GSoC. Welcome to the mailinglist :)
> I'll give your proposal a read in the coming days and hopefully I can provide some feedback & points of improvement to you.
>
> In the meantime have a look at our GSoC Participants Guide [0].
> Let me know if you have any questions or concerns.
>
>
> [0] https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo
>
> Cheers,
> Andrej
>
> > On 12. Mar 2025, at 05:58, Hamza Mohammed <hamza.mohammed.hasan@gmail.com> wrote:
> >
> > Hello everyone,
> > Hamza here. I hope you are doing well. I am currently working on my draft proposal for Google Summer of Code (GSoC) for the FM application project, and I would greatly appreciate your feedback on it.
> > I have outlined my project goals, deliverables, and timeline based on the GSoC schedule. I have also planned a features table. However, I would love to hear suggestions on areas for improvement, whether it's refining the features, structuring the timeline better, or improving clarity in my explanations.
> > Please find my draft proposal here [https://drive.google.com/file/d/1MfWWRX6FDMxjSAZDFxQMvN9eGc65-FP5/view?usp=drive_link]. If you have any specific points that I should address or modify, I would be happy to incorporate them.
> > Looking forward to your valuable insights! But note, this is my very initial version, so it might be bothersome to go through :).
> > Best regards,
> > Hamza
> > https://github.com/StudHamza
>

GSoc'25 proposal feedback request

Hello!

I'm Daksha, a sophomore majoring in Computer Science at California State University Long Beach, and I'm really excited about the opportunity to contribute to GNU Radio through Google Summer of Code!

I've always been fascinated by media technology and its ability to connect people on a large scale, and GNU Radio's open-source approach makes advanced signal processing more accessible than ever. The idea of using it for things like FM RDS reception is exciting to me, and I'd love to help make these tools even more approachable for newcomers while expanding their impact.

I've put together an initial draft of my proposal and would  appreciate any feedback to refine my ideas. Looking forward to your thoughts—thanks so much for your time!

Best,
Daksha