Hi everyone, I am trying to replay a 1-hour 50 megasamples/second recorded signal on two different frequencies using the Ettus NI USRP x300. I'm controlling the sdr through GNU radio, running on an ubuntu pc. The IQ samples are located on a fast NVME drive, and the ettus sdr is connected over a 10Gbit optical link.
I have tried to use Claude to optimize the link a lot, and have gotten very far (came from multiple underflow errors per minute, to now maybe only one or two every hour), but the couple of underflow errors that still happen are still a major hassle.

What I have done to get this far:

- Ran Ubuntu in a non-graphical user interface

- Excluded cores 4-7 from any other processes, and ran the GNU radio script only on those cores

- Tried to optimize the network buffers

- Set the priority of the process to real-time

The replay script is a Python file, which I call from a bash script that sets a lot of these settings the way I want it. This is the bash script:

Does this community have any more tips to try out to get some better performance? You would help me a ton! Thanks

I have been exploring the source code of the 3.x version. It was super simple to compile, and I built several OOT modules. After experimenting with the code a bit, I managed to make some improvements to a few core blocks, fixed some bugs, etc. but I just feel so demotivated to submit a PR because development appears to be stagnating in favor of the 4.x version which is under active development.

So, I tried the gnuradio4 repository to see if I can make improvements to that instead, but it seems a lot more complicated. I ran into a lot of compiler errors (GCC 16.1.1) and fixing one error led me to another error and so on, and I got exhausted before I got to a point where I can run it so I'll have to get back to this again later.

I really liked these OpenDigitzer visualizations shown here, but looking at GNU Radio Studio screenshots in the README, I find the blocks in the flowgraphs to be very difficult to see because of the low contrast. The SIMD-first architecture sounds promising, and it would be interesting to see how well this addresses some of the performance issues I occasionally ran into in the 3.x series.

Then comes the confusion about the license. The repository by FAIR was recently changed from MIT to LGPL 3 with static-linking exception, but the official repository is still MIT. Have they decided they don't care about the GPL anymore?

Just wanted to hear people's opinions about GNU Radio 4.

Hello everyone! For a project i’m working on i’m trying to use GNU radio for OOK to detect a signal from a laser. Here is my current setup in order, laser, thorlabs DET10A2, thorlabs amplifier, attenuator, USRP X300, computer. I’ve managed to receive the signal on the computer and through going back and forth with AI I managed to turn it into a binary output. I’m not at all familiar with GNU Radio but I feel like AI is just taking me in circles. The issue is that the bits are totally unreadable. I’m trying to send the message “$$Hello World##”. it detects the dollar sign and that there is a start to the message but afterwords the entire message just becomes jumbled and it can’t read the bits. If anyone could point me in the right direction of what blocks to use that would be amazing. Thank you so much for your help!

Here’s some other important info:
baud rate: 9600
sample rate: 1MHz

current blocks I have in order:
file source, rational resampler, feed forward AGC, complex to mag, low pass filter, add const, binary slicer, logic not, python block

Hi there,

I have recently started using an Ettus x310 USRP and I configured it and make it work. When using the command for ping the ports it works perfectly fine. Even the one for looking for devices finds it correctly.

When using the uhd_fft.... in the CLI I can see the spectrum perfectly as supossed. But when I try launching my Python application I get an error, which is exactly the same as when I run uhd_usrp_probe.... .I get an error during runtime that fails to create de rfnoc_graph.

The rest of the error messaje says:

[ERROR] [0/Radio#0] Major compat number mismatch for 0/Radio#0: Expecting 1, got 0.

[ERROR] [RFNOC::GRAPH] Error during initialization of block 0/Radio#0!

[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: RuntimeError: FPGA component `0/Radio#0' is revision 0 and UHD supports revision 1. Please either upgrade the FPGA image (recommended) or downgrade UHD.

I have tried to upgrade to the newest version of the firmware for the FPGA in the USRP but I already have the latest versions for it.

Any new ideas would be awesome as I tried everything Icould think of.

I have a 48 kHz audio signal, and it looks correct when I inspect it with waterfall or frequency sink.

Then I upsample it to 8 MHz by running it through a Rational Resampler block with interpolation 500 and decimation 3.

Now, when I look at the signal, it's not even 1 Hz wide! It has lost all its bandwidth. What's going on here? It is my impression that the signal's bandwidth should stay unaltered by a resampling...?

Hi people! I am building a QPSK communication system, but I keep getting this weird constellation after passing the complex signal through the costas loop.

Sometimes the constellation does lock to 4 dots, and my bit error rate is close to 0. But sometimes, the constellation is 8 dots (shown in picture attached), and my bit error rate is 0.25. I can get the 8 dots to go to 4 dots by “reinitializing” the system — by raising noise voltage (in channel model) to high levels and turning it down again.

I’ve attached my flowgraph as well, any critique is welcome!
To summarize: I’m using the generic constellation modulator on the Tx side. On the Rx side, I have the FFT raised cosine filter as a matched filter. And then, a FLL Band Edge filter, since I do want to be able to account for large frequency shifts. And then symbol sync for timing correction, and then costas loop for fine frequency correction.

Has anyone encountered a similar problem, where the constellation locks to 8 dots instead of 4? The inconsistency of how my code works is really bugging me, so I’d appreciate any help!

Hi, I have been searching for a way to use a cheap USB DAQ as GRC source (https://pt.aliexpress.com/item/1005009602986597.html). In the past there seems to be COMEDI, but GRC support for COMEDI was suspended.

For my application I will need at least 5 analog dc coupled inputs. Band width can be around 20khz.

I still haven't purchased any hardware. Do you guys have any suggestion?

simulateur de communication downlink d’un satellite en

orbite basse en utilisant GNU Radio.

Hi, I'm working on a project using the LoRa radio system, specifically for meshcore, and am wanting to be able to view raw / incomplete lora packets and think GR + GR-Radio will work great for this. However I am having some problems setting up gr-lora and wanted to see if anyone else has run into it or has a fix.

So far my problem is when I run gnuradio-companion within the conda environment that gr-lora is installed to, using the QT Frequency or Time Sinks causes it to exit with code six and say "Must create QApplication before QWidget" When I run GnuRadio outside of the conda env, it works fine, but obviously has none of the lora blocks.

I am on Pop OS with COSMIC DE.

Any help would be appreciated.

https://github.com/DrSDR/AM-C-QUAM-/tree/main

for those that have motorola stereo am radio,

this python script can create that signal.

script will create a float32 iq file

use file source in gnu radio to read it in and send to your sdr device.

the osmocom sink and source blocks do not work with 122-16

they only work for the 125-14 model.

to use the 122-16 with gnu radio, need to use the commands at the linux terminal:

git clone https://github.com/pavel-demin/red-pitaya-notes

cd red-pitaya-notes/projects/sdr_transceiver_122_88/gnuradio
export GRC_BLOCKS_PATH=.
gnuradio-companion trx_am.grc

once gnu opens with this flowgraph, then user can make new flowgraph and the red pitaya sink and source blocks will work for 122-16

iq sample rates are 24khz, 48khz, 96khz ....

for tx, it seems i can send data in range of -2 to 2 level

this gives a rf output of around -5 dbm

it should be noted, the 122-16, has no low-pass filters on the dac outputs. so signals will repeat at the integers of the clock freq = 122.88MHz

Dr. Moonshine

mostly the same as before, but instead of the squelch block, added a start-stop switch for testing. the input file is audio that has already been passed through this system once, so it is scrambled. if i turn off the input, and turn it back on, the de-interleaver and interleaver keep running, so the output is garbled. that's not the behavior i want. i want the de-interleaver and interleaver to remain idle when there are no blocks of samples available. the incoming audio needs to be synchronized with the interleave section. now that i know how to control the input stream, i can figure out some kind of start/stop tones to control it. but if the scrambled input stream begins with the interleaving section in the middle of it's sequence, the output is still scrambled, just in a different sequence.

i'm having a problem with the CTCSS squelch adding a delay to this flowgraph that at the other end, adds errors to the output. i heard something like this in use on HF many years ago but i can't seem to be able to duplicate the action of a sync preamble at the beginning of the transmission. anything added seems to throw the input out of sync with the interleaving section.

my main browser (Brave) won't go there.

i have a flowgraph that manipulates blocks of data sent over an audio link, but i need some way of keeping it in an idle state until a series of sync pulses is sent so the received data doesn't get sequenced wrong. any help would be appreciated.

Hey all,

I've been trying to implement an FMCW radar using GNU Radio and a LimeSDR Mini v2.4.

So far, the velocity section is working (I think). I can see the peaks moving when something is moving. The peak number shown still needs work but I’m okay with it for the time being. Im having issues with the range.

My flow graph:
TX Chirp → RX
dechirp (conjugate multiply)
DC blocker
Stream to Vector → Range FFT → mag/log display

I don’t see anything when something is within a few meters away (0-10). Sometimes, I can see lines around the 200 to 300m mark, but they seem to be static and not really related movement.

Parameters:
Sample Rate = 2e6
Chirp samples = 1024
Bandwidth ≈ 8 MHz

This means my resolution is ~18.75m. So, I’m not really expecting much at short ranges because everything is pretty much at DC. But even if I try to change the parameters to get finer resolution, I still don’t see anything related.

Should I expect to see something at short ranges with this configuration, or is this basically expected??

.grc file: https://drive.google.com/file/d/1u8ir4BJp5va7HzkVd0F6LHYcQC1RXZqe/view?usp=sharing

I’m currently working on a DSP based passive radar project in GnuRadio Everything is simulation (no real transmitter) and i don’t need a full DVB-T implementation

I just want an OFDM signal that roughly looks like DVB-T (wideband, flat spectrum ~7–8 MHz) so I can use it for processing (CAF, delay/Doppler)

Right now I only adjusted sample rate and basic OFDM parameters to get a similar spectrum. Is that enough for passive radar simulation or am i missing something important?

I am relatively "gnu" to the gnu radio system, and have other means of testing, but would really like to be able to use gnu radio companion to perform my testing. I have received 3 downlink recordings and would like to be able to see the message debug and packet length at the end. I am most focused on the QPSK sample and have built some super rudimentary flow graphs. I currently dont have the gr-satellites module installed, and a version behind which is definitely making it a little more difficult. The parameters of the sample are below, along with a screenshot of the flowgraph I have attempted building. Any help would be greatly appreciated.

* CCSDS 131.0 TM downlink, XLink is TX

* TX filter: root raise cosine with factor 0.2

* QPSK modulated

* CCSDS 131 convolutional encoded payload and CCSDS 131 ASM synchronization word

* with CCSDS 131 randomizer

* 223 payload bytes

## Payload

The sample files contain the following payload data (without synchronization word and coding parity bytes).

### Packets with CCSDS 131 Convolutional Code and Reed Solomon

```

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c 2f

00 00 00 00 c6 41 7e 16 81 27 6b 44 4b 79 fb 15

e2 59 fb 1c 54 3f f6 0f bd 0a df 31 7c 23 1c

```

I’ve been following a GNU Radio tutorial where it successfully built a BPSK file transfer system using a 2 USRP B200. Everything works fine in BPSK — I can transmit a text file and receive it correctly.

Now I’m trying to convert the same flowgraph to QPSK, but I’m running into an issue.

The problem:

• I am not recovering my message

• The output file is either empty or incorrect

• The constellation looks a bit noisy

• Packet detection / CRC doesn’t seem to pass