Wednesday, July 23, 2025

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
 

Saturday, July 19, 2025

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


Wednesday, July 16, 2025

GRCon25 Schedule is live - Sept. 8-12, Everett, WA

Dear GNU Radio Community,

We're excited to announce that the schedule for GNU Radio Conference 2025 (GRCon25) is now live!

This year's conference is shaping up to be one of the best yet, with an exciting lineup of content and activities for attendees of all backgrounds and experience levels. Here's a preview of what's in store:

  • 10 Hands-On Workshops covering a wide range of SDR and signal processing topics
    Note: These sessions are not livestreamed or recorded - join in person to get the full experience!

  • New User Day on Monday - workshops and hands-on help specifically designed for attendees who are new to GNU Radio or looking for extra guidance

  • An outstanding main track lineup featuring talks from leading experts, students, and community members throughout the week

  • Amateur Radio License Exams on-site on Thursday, September 11

  • Breakout Sessions and Panel Discussions for deeper dives, collaboration, and community-driven conversations

  • Evening Social Activities on Monday and Wednesday to connect and celebrate with fellow attendees

    • Wednesday's event is sponsored by Emerson/NI to celebrate 20 years of the USRP -  it's a USRP birthday party you won't want to miss!

--> gnuradio.org/grcon25 for all information and registration

We also want to mention the Zero Retries Conference that will be taking place the weekend following GRCon at the same venue: https://www.zeroretries.org/p/conference - ZRDC 2025, will be the inaugural digital communications conference hosted by Zero Retries zeroretries.org with a focus on technological innovation in Amateur Radio

We can't wait to see you in Everett, WA this September!
Stay tuned for more updates and as always, thank you for being a part of the GNU Radio community.

Best regards,
The GRCon25 Organizing Team
grcon@gnuradio.org
gnuradio.org/grcon25


Thursday, July 10, 2025

GRCon25 Schedule Overview (8-12 Sept, Everett, WA)

Greetings!

Wanted to give an update on the GRCon25 schedule (8-12 Sept, Everett, WA) - we are still fine-tuning, but the conference will be organized as follows.  Detailed schedule with specific talk timeslots should be available in the next week.  Visit gnuradio.org/grcon25 for the most up to date information - and tickets.gnuradio.org to register

Monday AM

  • Introductory GNURadio Workshop (for beginners)
Monday PM
  • Intermediate GNURadio Workshops

Tuesday

  • Keynote
  • GNU Radio Update
  • Main Talks: Applications of GNURadio track
  • Lightning talks: 5 minutes, no sign-up required
  • Intermediate/Advanced Workshop in the afternoon
  • CTF all day
  • Expo Hall

Wednesday

  • Keynote
  • GNU Radio 4 Roadmap
  • Main Talks:  RADAR and Communications track
  • Lightning talks: 5 minutes, no sign-up required
  • Intermediate/Advanced Workshop in the afternoon
  • CTF all day
  • Expo Hall

Thursday 

  • Keynote
  • Main Talks: Signal Processing track
  • Lightning talks: 5 minutes, no sign-up require
  • Intermediate/Advanced Workshop: late afternoon
  • CTF all day, concludes at 1700
  • Expo Hall

Friday

  • Keynote
  • Concluding talks
  • CTF walkthrough: spoilers!
  • Hands-on project collaboration

The conference should conclude by 1300 (ish) on Friday. As a final note, slides and your final paper should be submitted by Friday, 5 Sept. Feel free to reach out to the technical chair at nrogers@gnuradio.org if you have any questions.

Please reach out to grcon@gnuradio.org for any general questions.  Looking forward to seeing all of you in Everett!


Josh


Monday, July 7, 2025

2026 IEEE Aerospace Conference

 

Hello,

 

I am chairing the Software Defined and Cognitive Radio session at the upcoming IEEE Aerospace Conference (http://www.aeroconf.org).  This large conference will take place March 7-14, 2026 in Big Sky, Montana.  The conference provides a world-class technical program and provides excellent opportunities for both networking and recreation. This is one of the few conferences where SDR can be put in the context of a complete system and can be applied to new missions and concepts of operations.

 

Last year there were a few papers dealing with application of machine/deep learning to radio design.  I hope to see even more next year!

Abstracts are due now, but I can take them a bit later as well, while the full paper is due end of October.  This session will focus on flexible radio architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of existing systems and testbeds are of significant interest.  This year I'd like to introduce work related to machine learning as applied to wireless communications.

 

Please forward this to your friends and colleagues working in the areas of SDR and cognitive radio.


Regards,

Eugene.

 

Re: European GNU Radio days 2025 updates

Dear Community,

This is a last reminder about the upcoming European GNU Radio Days next week in Lyon, France. (16-18 July)

- There are still plenty of spots available so you are welcome to register by sending us an email at european-gr-days@gnuradio.org.
- You can see and contribute to the subjects to discuss during these three days here:
https://wiki.gnuradio.org/index.php?title=European_GNU_Radio_Days/2025
- A Matrix channel has also been setup for more interactive discussions: https://matrix.to/#/#eugrdays25:gnuradio.org

If you are particularly interested in certain topics, please tell us (by email, Matrix chat or on the wiki), especially if you are not present all the time.
This will help us deciding on the exact planning.

See you in Lyon,

Cyrille MORIN
Ingénieur SED
Équipe MARACAS


Centre Inria de Lyon

Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne

Le 02/06/2025 à 14:22, Cyrille Morin a écrit :

Dear Community,

This is a small reminder about the upcoming European GNU Radio Days next month in Lyon, France
Now with additional updates:

- You can contact us at european-gr-days@gnuradio.org to register, ask questions about the event, make suggestions ...

- Murat Sever has kindly stepped up and offers to hold a beginners workshop if there is enough interest. So please tell us if you are interested so we can plan for it.

- Similarly, Ralph Steinhagen offers to hold a GR 4.0 intro or tutorial. So again, please tell us if you are interested.

- You can find a list of proposed topics for the event in the wiki. Feel free to comment on those, and/or add some!
    https://wiki.gnuradio.org/index.php?title=European_GNU_Radio_Days/2025

See you in Lyon,

Cyrille MORIN
Ingénieur SED
Équipe MARACAS


Centre Inria de Lyon

Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne

Le 05/05/2025 à 11:39, Cyrille Morin a écrit :

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


Centre Inria de Lyon

Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne

Monday, June 16, 2025

Re: Inconsistent I/Q Channel Output with single Pluto for BPSK tx and rx

On Sat, Jun 14, 2025 at 3:26 PM Maciej Zemło <mzemlo.pl@gmail.com> wrote:
Hi,

I'm testing a basic BPSK tx-rx chain using GNU Radio v3.10.12.0 with a single Pluto device. The system performs BPSK modulation on a constant bit stream (0x0A) and transmits it via the PlutoSDR's TX (cycle on), while the RX path is connected in a loopback configuration.

Each time I run the script, the received I and Q components appear in a different arrangement. Sometimes the signal appears predominantly on the I channel, other times on Q, or even rotated. The transmitted waveform remains constant and is visualized properly in the TX time sink, while the RX signal varies significantly in phase alignment between subsequent executions. A set of plots showing these differences is available at:

This phase ambiguity is inherent in the system and the modulation. Each local oscillator being used are separately tuned which introduces the phase shift.
 
I'd appreciate even a brief signal on whether this behavior is expected and how it is typically addressed. Would using two separate Pluto units (one for TX and one for RX) eliminate this ambiguity?

If you want to keep regular BPSK, then typically you'll send some synchronization pattern to figure out "which way is up". The undoing of this is a simple phase rotation (complex multiplication) with the complex conjugate of the result of the correlation between what was sent and what was received.

If you want to get rid of all ambiguities in general, and you're willing to take a 3 dB performance hit, switch to differential BPSK. This looks at just the difference between the previous symbol and the current symbol to get the actual message data. Phase ambiguities are eliminated using this method.

Good luck.

Brian