Official bladeRF forum

Posted: **Tue Feb 10, 2026 7:46 am**

Hi everyone,
I’m new to development with bladeRF and I’m running into some unexpected behavior that I’m hoping someone here can help explain.

We recently purchased three bladeRF 2.0 micro xA4 boards for testing. I’m using GNU Radio, installed via radioconda, for my project. I was able to get the bladeRF working using the native bladeRF source block, but I’ve been seeing several issues that I did not encounter when using a HackRF.

For initial testing, I used a HackRF and everything behaved as expected. However, since we need reliable operation up to 5.8 GHz, we switched to bladeRF, and that’s when the problems started.

1) Effective sample rate appears ~4× slower than expected

I have the bladeRF sample rate set to 1 MS/s. Using a Custom Python Block in GNU Radio, I count the number of samples received from the bladeRF and measure the elapsed time.At 1 MS/s, I would expect to receive 1 million samples in ~1 second. Instead, it consistently takes about 4 seconds to receive 1 million samples.
For comparison, running the exact same Python code with a HackRF produces the expected result (1 million samples in ~1 second).
Has anyone seen this kind of “slow-motion” behavior with bladeRF before?

2) GNU Radio UI freezes and unexpected terminal output

Another issue I’m seeing is that the GNU Radio UI frequently freezes while the flowgraph is running. At the same time, a large amount of seemingly random data is being printed to the terminal. This output is not generated by any of my code, and it appears even in very simple flowgraphs (for example, a single bladeRF source feeding a null sink). The terminal spam seems to correlate with the UI becoming unresponsive.

Is this expected behavior, or a known issue with bladeRF logging or buffering?

3) FPGA compatibility warning

I also consistently see the following message when running my flowgraph:
[INFO @ host/libraries/libbladeRF/src/helpers/version.c:106]
FPGA version (v0.16.0) is newer than entries in libbladeRF's compatibility table.
Please update libbladeRF if problems arise.

I’m currently using the bladeRF packages provided by conda-forge (radioconda). Could this FPGA compatibility warning explain the reduced effective sample rate or other instability?

Here is my python code:

Code: Select all

"""
Embedded Python Blocks:

Each time this file is saved, GRC will instantiate the first class it finds
to get ports and parameters of your block. The arguments to __init__ will
be the parameters. All of them are required to have default values!
"""

import time
import numpy as np
from gnuradio import gr


class blk(gr.sync_block):
    """Embedded Python Block - measure time for 1M samples"""

    def __init__(self, example_param=1.0):
        gr.sync_block.__init__(
            self,
            name='Sample Timing Block',
            in_sig=[np.complex64],
            out_sig=[np.complex64]
        )

        self.example_param = example_param

        self.sample_count = 0
        self.start_time = None

    def work(self, input_items, output_items):
        n = len(input_items[0])

        # start timing on first samples
        if self.start_time is None:
            self.start_time = time.time()

        # count samples
        self.sample_count += n

        # check for 1,000,000 samples
        if self.sample_count >= 1_000_000:
            end_time = time.time()
            elapsed = end_time - self.start_time
            print(f"Elapsed time for 1,000,000 samples: {elapsed:.6f} seconds")

            # reset for next measurement
            self.sample_count = 0
            self.start_time = None

        # pass samples through unchanged (or scaled)
        output_items[0][:] = input_items[0] * self.example_param
        return n

Official bladeRF forum

bladeRF 2.0 running slower than expected in GNU Radio (radioconda setup)

bladeRF 2.0 running slower than expected in GNU Radio (radioconda setup)