GRCon25 - Less Than One Week to Register at Regular Prices

Join Us at GRCon25 - 8-12 September, Everett WA!

The 15th annual GNU Radio Conference (GRCon25) will take place 8-12 September 2025 at the Edward Hansen Conference Center in Everett, Washington, in the greater Seattle area. GRCon is the premier event for the Free and Open Source Software Radio community, bringing together developers, researchers, industry leaders, and hobbyists from around the world.

Full conference details are available at gnuradio.org/grcon25.

---

Registration Deadline Approaching

Regular-price registration ends Friday, August 15. After that date, prices increase.

All attendees registered by August 15 will be entered into a drawing to win a HydraSDR RFOne - delivering laboratory-grade performance with 24 MHz to 1.8 GHz coverage, 12-bit ADC resolution, and GNU Radio integration.

Thanks to HydraSDR for sponsoring this giveaway - even more will be given away throughout the week.

Register now at tickets.gnuradio.org.

---

Main Track Sessions

Our main track sessions will include presentations from both new and returning contributors, offering insights into the latest developments in wireless communications, signal processing, and SDR hardware and applications.

We are also pleased to announce our keynote speakers:

• Prof. Joshua R. Smith - Milton and Delia Zeutschel Professor at the University of Washington (Allen School of Computer Science & ECE), Director of the UW+Amazon Science Hub, and global leader in sensor systems, wireless power, and ubiquitous computing. IEEE and National Academy of Inventors Fellow.
  

• Dr. Tom Rondeau - Principal Director for the FutureG Office, U.S. Department of Defense, and former DARPA Program Manager. Former lead of the GNU Radio project, with a career spanning open source SDR, national security, and advanced wireless research.
  

• Bradley M. Kuhn - Policy Fellow and Hacker-in-Residence at Software Freedom Conservancy. Former FSF Executive Director, creator of the Affero GPL, and lifelong advocate for software freedom, GPL enforcement, and FOSS community infrastructure.
  

• Jesse Alexander (WB2IFS) - Senior member of IEEE, Radio Club of America, and ARRL, with over 40 years of experience in STEM education, knowledge management, wireless systems, and amateur radio leadership.
  
  

---

Workshops - In Person Only

GRCon25 features a wide range of workshops available exclusively to in-person attendees.

Monday kicks off with New User-focused content and a special invited workshop:

Paul Clark - Tutorials from his new No Starch Press book Practical SDR, introducing hobbyists, students, and engineers to practical SDR concepts.

We also have Dan Boschen returning to present a new invited workshop: Quantifying Signal Quality: Practical Tools for High-Fidelity Waveform Analysis.

Additional workshops throughout the week include:

• Communications Basics - Wylie Standage-Beier
  

• Reverse Engineering a Simple Remote - Dr. Neil Rogers
  

• GNU Radio on Embedded SDRs - Philip Balister, Toby Flynn
  

• Simple Replay Attack Demo with GNU Radio - Murat Sever
  

• GR4 Block Design Tutorial - Josh Morman
  

• You Can Do Everything with MultiUSRP, and for Everything Else There is RFNoC - Marian Koop (NI)
  

• GPU Accelerated Block Development - John Sallay
  

• USRP FPGA Processing Using RFNoC - Neel Pandeya
  
  

---

Amateur Radio Exams

Amateur Radio license exams will be offered on Thursday, September 11. Please indicate during registration if you plan to take the exam. The exam itself is free, but a nominal FCC fee must be paid prior to taking it. See larc-vec.org/licensing.php for details.

---

Capture the Flag

GRCon25 will host its popular Capture the Flag competition, with prizes and bragging rights for the winners. A dedicated conference room will be available for participants to collaborate and work on the challenges throughout the event.

---

Evening Events

• Monday Evening - Meet and Greet Reception for all attendees following the first day's workshops.
  

• Wednesday Evening - Social Event sponsored by NI/Emerson, celebrating 20 years of the USRP!
  
  

---

Sponsors and Expo Hall

Our generous sponsors make GRCon25 possible. Most will be showcasing their products and demos in the expo hall throughout the week. See the full list at Our Sponsors.

---

Related Event - ZRDC 2025

The weekend following GRCon25, the Zero Retries Digital Conference (ZRDC) will be held at the same venue. This independently organized event focuses on technological innovation in amateur radio, featuring presentations and demonstrations on topics such as:

• The IP400 Networking Project
  

• M17 Digital Voice/Data System (with repeater demonstrations)
  

• MMDVM-TNC data system (with repeater demonstrations)
  

• AREDN, HamWAN, and other microwave networking
  

Details at zeroretries.org/p/conference.

---

Register today to secure your spot at GRCon25 and join the world's leading open source SDR community in Everett this September.

Register Now

Box 'o radios

I have qty 110 of the older RTL-SDR radios that I want to liquidate. 
These are from before Nooelec and RTL-SDR.com really got into this game,
but all should work.

Various types and RF connectors.

I'm asking U$800.00 for the lot, not including shipping.

Im I making a fundamental mistake?

Dear GNURADIO friends,

I'm wondering if I am making a fundamental mistake or an implementation mistake.

You don't have to debug; thanks for sharing your thoughts! 

Summarized: The RTL-SDR has an 28.8MHz oscillator and I'm feeding this clock-signal into a fractional divider which brings it to a 500Hz audio tone. Please notice this process is carried out with hardware components and is not affected by computer interrupts etc.

The 500Hz audio signal is fed into a regular HAM FM 145MHz transmitter.

The signal is received by an RTL-SDR USB and goes in a SOAPY GNURADIO source block and is decimated to 256000 sampless and demodulated resulting into 500Hz audio tone.
I assume(!) that the IQ sample rate is defined by the SDR receiver and deducted from its 28.8Mhz clock.  
I calculated that with an sample rate of 256K it takes 512 samples =(1500)(1256000)  to cover the cycle time of a 500Hz sine wave.
In a GNURADIO C++ OOT block (based on the very useful GR OOT Cpp tutorial) I re-create (based on the incoming a IQ-stream) with a  sample counter in combination with a look-up table a synthetic sine wave of 500Hz.
I expect that the demodulated 500Hz FM signal  and created synthetic 500Hz signal have exactly the same frequency but I am facing a phase drift between them…
Both 500Hz signals though origin from the same source (the 28.8MHz) SDR clock which defines the audio tone and the sample rate.
I'm wondering if I (still a beginner) am making a fundamental digital signal processing mistake or simply making an implementation mistake which I have to deep dive further into.
After several months I am still learning but got stuck and highly appreciate if you share your thoughts.
My question: Is this approach theoretically possilbe?
Thanks,
Robert PA0BRT

files fyi: Recorded IQ, 2Ch_audio, GRC, Video, OOT_Cpp, lookup_table_synthetic_sine
https://tinyurl.com/3pryf9kb

Re: Adding a Clock IP to RFNoC Block

Hey Jons,

I responded on the usrp-users list (didn't see that you had cross-posted).

--M

On Sat, Jul 26, 2025 at 10:18 AM Jons <jonsdeburn@gmail.com> wrote:

Hi all,

I am trying to add a custom RFNoC block and my block runs on different clocks(not the default ones). So I followed the instructions from the FAQ page in RFNoC wiki of deriving clocks from the available clocks - https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_a_clock_with_a_different_frequency.3F But when I add the parameters in block YAML, it added new ports to my rfnoc_block_myblock module, which is not what I expected. My intention was to derive 2 clocks from the rfnoc_chdr_clk  and use it inside my block. For this I added the clock IP module (instantiated) in the noc_shell_myblock, because this is where the CDC FIFOs are there. So, with this method the generated clock just stays inside my block and won't be available outside to it. Maybe the steps described in the FAQ might not be the right way to go about with my requirement? I am not sure.

Also, I tried not adding the YAML parameters of the clocks for my block. This worked to the point where the implementation of the entire design failed with WNS of -0.8ns on the new derived clock I added. I also got a few Critical warnings for the clocks I added, not sure if it is related somehow or if I can ignore it -

TIMING-4#1 Critical Warning
Invalid primary clock redefinition on a clock tree  
Invalid clock redefinition on a clock tree. The primary clock x4xx_core_i/rfnoc_image_core_i/b_myblock_3/noc_shell_myblock_i/clk_wiz_chdr_200_125_inst/inst/clk_in_chdr is defined downstream of clock clk200 and overrides its insertion delay and/or waveform definition.

I followed this thread (https://www.mail-archive.com/usrp-users%40lists.ettus.com/msg14663.html) to add IPs of my clock module that I generated with with Vivado IP catalog and copied the .xci, .v and other generated files into the path/to/module/rfnoc/fpga/myblock/ip/ and changed the Makefile and block YAML definitions like the example given in the example Gain block.

Any tips or leads in adding custom derived clocks to the design would be super helpful and thank you all for maintaining such a nice community!!

-J

Adding a Clock IP to RFNoC Block

Hi all,

I am trying to add a custom RFNoC block and my block runs on different clocks(not the default ones). So I followed the instructions from the FAQ page in RFNoC wiki of deriving clocks from the available clocks - https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_a_clock_with_a_different_frequency.3F But when I add the parameters in block YAML, it added new ports to my rfnoc_block_myblock module, which is not what I expected. My intention was to derive 2 clocks from the rfnoc_chdr_clk  and use it inside my block. For this I added the clock IP module (instantiated) in the noc_shell_myblock, because this is where the CDC FIFOs are there. So, with this method the generated clock just stays inside my block and won't be available outside to it. Maybe the steps described in the FAQ might not be the right way to go about with my requirement? I am not sure.

Also, I tried not adding the YAML parameters of the clocks for my block. This worked to the point where the implementation of the entire design failed with WNS of -0.8ns on the new derived clock I added. I also got a few Critical warnings for the clocks I added, not sure if it is related somehow or if I can ignore it -

TIMING-4#1 Critical Warning
Invalid primary clock redefinition on a clock tree  
Invalid clock redefinition on a clock tree. The primary clock x4xx_core_i/rfnoc_image_core_i/b_myblock_3/noc_shell_myblock_i/clk_wiz_chdr_200_125_inst/inst/clk_in_chdr is defined downstream of clock clk200 and overrides its insertion delay and/or waveform definition.

I followed this thread (https://www.mail-archive.com/usrp-users%40lists.ettus.com/msg14663.html) to add IPs of my clock module that I generated with with Vivado IP catalog and copied the .xci, .v and other generated files into the path/to/module/rfnoc/fpga/myblock/ip/ and changed the Makefile and block YAML definitions like the example given in the example Gain block.

Any tips or leads in adding custom derived clocks to the design would be super helpful and thank you all for maintaining such a nice community!!

-J

A problem in increasing the BladeRF instantaneous bandwidth

Dear GNU Radio,

I am working on radar system development using BladeRF micro 2.0 and GNU Radio. Currently, my system performance is limited by the default sampling rate of the BladeRF which is ~80MSps. According to this page, there is a possibility to increase BladeRF bandwidth/sampling rate and I want to do it to enhance my radar performance. I was following this instruction by updating the firmware, then adding this argument into gr-osmocom sink and source block. 

"bladerf=0,sample_format=8,feature=oversample" 

However, I didn't see that it worked because when I increased my radar sampling rate, I got a warning that told me that the maximum accumulated sampling rate was still ~80MSps. 

Is there anyone know what did I miss? Thank you.

Best regards,

Edwar

 

Re: Writing Drivers for Custom Hardware

Hi all,

Following up on a thread from last year. After trying multiple approaches, I finally spent some time figuring out how to write a GnuRadio OOT module. My code is here.

In the OOT, I took the approach of having a separate thread using PCAP to listen to the hardware and populate a circular buffer. Then, the work() method of the OOT populates the output buffer using the circular buffer. While the code compiles, and the buffer doesn't seem to get "lapped", this approach is still yielding bad data. Using a separate program that just involves calling essentially the same PCAP routines and dumping the values straight to a file works yielding good data. The printing to STDERR may be slowing things down, but that was just a poor-mans debug; commenting those lines out doesn't change the resulting bad data. I've also tried various sizes for the circular buffer from 2^20 to 2^31, but larger sizes don't seem to fix the issue either.

I understand that most folks don't have the firehose hardware, but I was wondering if someone would skim my code and see if I was missing something obvious. I'm currently stuck with GnuRadio 3.8.5 because I'm using MacPorts. The biggest obstacle here is that 3.8.5 still uses SWIG rather than PyBind. That means I have hard-coded my device path (en5) rather than having it passed in through the block interface because I wasn't in the mood to mess with SWIG any more than I had to.

Ultimately my plan is to use a ZMQ PUB Sink block, but for now, I'm testing using a File Sink block and then using a vendor-provided python script to plot the spectrum of the values in the file. Also, are my definitions of "good" and "bad" data: When I say that an approach yields "good data", what I mean is that the spectrum of the data dumped to a file looks as it should. When I say that an approach yields "bad data", the spectrum does not look as it should. To further confirm that the good spectrum actually has good data and the bad spectrum has bad data, there are a few other python scripts that I've run using the data that show high SNR for GPS/Galileo/GLONASS satellites that are actually visible when I capture good data but not when I capture bad data.

Does anything come to mind?

Thanks,

Walter

On Jul 13, 2024, at 7:32 AM, Marcus Müller <mmueller@gnuradio.org> wrote:

Hi Walter,

interesting project!

The libpcap approach seems to be reasonable; backintheday, I used to capture at Ethernet frame level using socket(PF_PACKET,…), but that's pretty non-portable and comes with its own can of worms. pcap's the way to go there, I'd say, unless you want add a protocol family to your operating system (don't know whether that is Linux or Mac OS), which I kind of doubt.

However:
The PUB/SUB scheme is almost certainly not what you want here – that is for broadcasting data to multiple subscribers (or dropping them, when the subscriber(s) aren't ready) from potentially multiple transmitters. You might spot the problem here! If you attach a waterhose on one end, and the other end doesn't fetch packets in intervals short enough for the receive buffer to not overflow, these packets will just silently be dropped - business as usual for a PUBlisher! Try the PUSH/PULL pattern: GNU Radio by principle will need a block like the SUB block to fetch data as available, and call it back later at some point. That will not work well in this use case.

So, to your core question, writing a GNU Radio block for your device is relatively easy, probably; data rates aren't *that* high, so an extra memory copy here and there is something I'd live with for a prototype.
Methodology would be this, roughly:
1. make an out-of-tree module. We cover this on https://tutorials.gnuradio.org , specifically in [1]. In short, `gr_modtool newmod yourmodname`.
2. Make a source block (`gr_modtool add -t source -l c++ hose_source`)
3. in the generated lib/something_impl.cc, add a `bool hose_source::start() {}`, and also add tht `bool start() override;` method prototype to the _impl.h
4. in the _impl.h add private fields: a set of buffers, one for each channel, where you'll put the data "deinterleavedly" from the NIC. Make each buffer some (say, 2²⁰) GNSS samples long. Also add two unsigned integer counters: one read and one write index. And because we're lazy and don't care *that* much about performance yet, two mutexes (one for securing access to the read index, and one for the write index).
5. in the constructor, you allocate these buffers, set the read index to the length of the buffers (-1) and the write index to 0
6. in the start() method, you spawn a thread that, in a loop
 1. checks how much space there is between read and write index (get read mutex, fetch read index value, release mutex, calculate difference)
 2. uses pcap to fetch packets, (but only as much as the space calculated above allows for!), deinterleaves data onto the buffers, finally
 4. updates write index (get write mutex, update write index, release write mutex)
7. the block's work() method is called by GNU Radio regularly and
 1. checks how much data is between write and read indices (get write mutex, read write index, release mutex, calculate difference)
 2. checks whether that's more or less than the space for output items available in this current call to work(), takes the minimum of both
 3. gets that amount of items from each buffer and writes them to the output buffer, as passed as argument to the work() method (you could do type conversions here!)
 4. updates the read index accordingly (get read mutex, update index, release mutex)
 5. returns the number of written items

note that the index updating and distance calculation need to take the "wraparound" at the end of the buffer into account.

Also note: very similarly, you could write a **SoapySDR** driver instead of a GNU Radio block. You could then use the Generic SoapySDR Source block to get data from that driver, and other, non-GNU Radio programs, could be using the driver just as well, without knowing about the hardware. I don't think the basic principle would be much different: you need an IO thread that keeps the NIC busy, and because readers might be slow, an internal buffer, which you ideally use constructively (instead of just incurring a memory bandwidth overhead), to deinterleave channels on ingress, and to convert data types on egress, if you will.

Note that one *could* potentially, as mentioned above write a zero-copy-ish driver for GNU Radio 3.10+ using our custom buffer framework and something like AF_XDP, dpdk, or io_uring, but I think that would very much a) leave the scope of what anyone be able to assist you with – to the best of my knowledge, you'd be the first to do that with a network device – and b) we're "only" talking gigabit ethernet here, and you got a fast machine. As you said in your email, in principle, things are plenty fast enough, so let's not overcomplicate.

[1] https://wiki.gnuradio.org/index.php?title=Creating_C%2B%2B_OOT_with_gr-modtool

On 12.07.24 22:42, Walter Szeliga wrote:

Hi all,
    I have a GNSS Firehose (https://transitiva.com/product/gnss-firehose-receiver-tri-band-quad-constellation/ <https://transitiva.com/product/gnss-firehose-receiver-tri-band-quad-constellation/>) and have been trying to get it working, in a streaming capacity, with Gnuradio. The Firehose sends packets over ethernet using the experimental ethertype 0x88b5. I've tried a few things to get data from the Firehose into Gnuradio, some have worked, others have not. Things that work:
* Use tcpdump and filter on 0x88b5 and save to a file. Open and repackage each packet in the pcap dump as interleaved bytes of I&Q and save to a file. Read into Gnuradio.
* Write a custom program using libpcap to filter on 0x88b5 on a selected interface, repackage the packets and write directly to a file. Read into Gnuradio.
* Write a custom program using libpcap to filter on 0x88b5 on a selected interface, repackage the packets and PUB them using ZMQ. SUB to this PUB using a simple Python script and dump the message contents to a file. Read into Gnuradio. Both tcp and ipc PUB/SUB work equally well.
Some things that do not work:
* SUB to the ZMQ PUB/SUB using the Gnuradio ZMQ SUB Source block.
* Write a custom program using libpcap to filter on 0x88b5 on a selected interface, repackage the packets and send them using UDP.
The UDP approach doesn't work because too many packets get dropped and I have been unable to set sysctl values appropriately (on an M1 Mac) to avoid dropping too many packets.
I'm not sure why the ZMQ approach does not work with Gnuradio. I've tried many simple flowgraphs to convert from vector to stream, ibyte to complex, you name it, and then dumping the data back out to a file using a File Sink (just to use existing software to check for data sanity). Data gets into Gnuradio, but it clearly loses something because constellation diagrams of the output data become blobs centered on the origin rather than pairs of point clouds offset from the origin as one would expect from the BPSK nature of the GNSS signals captured by the Firehose.
I've come to the realization that it's probably best to write some sort of driver to get data straight from the Firehose into Gnuradio, but I have no idea where to start with this. Any ideas about how to fix my ZMQ approach or start writing a custom driver would be appreciated. There's a lot in here, so let me know if you would like code or flowgraph examples.
Cheers,
Walter