Handle overflows with two synchronized BladeRFs

[Vinc]

Hi,
long story short I made 4 RX channels recorder with two BladeRF micro xA9. Their trigger pins are connected and master device clk_out is connected to slave clk_in.

Im using asynchronous mode and saving samples basing on their metadata (timestamp). If there is no overflow there is no problem. But when overflow occurs some samples are "lost". And thats okay. Thats why I want to use timestamps. But here is the problem:
Lets say master device has overflow. Difference between timestamp of first buffer after overflow and buffer before that overflow is for example 71744 where in my case default difference should be 8192 hence 71744-8192=63552 lost samples. But when I correlate recorded MasterRX1 channel and SlaveRX1 channel from a sample where overflow occured for master then there is a shift of 61568 (screenshot, File1 = MasterRX1, File2 = SlaveRX1). So the actual shift does not match timestamp shift.

Link to image:
https://imgur.com/a/2tz01bi

I did the same thing handling overflows on USRP 2955 (X310) with double Twin RX daugherboards (4 RX channels) and everything worked there.

Versions I use:
'''
bladeRF> version

bladeRF-cli version: 1.9.0-git-fe3304d7
libbladeRF version: 2.5.1-git-fe3304d7

Firmware version: 2.4.0-git-a3d5c55f
FPGA version: 0.15.3 (configured from SPI flash)
'''

Is there a chance to get help?
Is there another way to handle overflows? I know how to lower the chance to get overflow, but I want to be sure that algorithm keeps running correctly even when it occurs.

Best regards

[dwest]

What software are you using to transmit? MATLAB, GNUradio, etc.?
 
I am also working on a project where I have two synchronized bladeRF Ax4's that is getting overflow problems. I initially was trying to perform a loopback using a single SDR with all channels which was performed using a MATLAB API wrapper. I was only able to catch the tail end of the transmission when I used:

num_samples = 1024; % Number of samples
num_buffers = 4; % Number of buffers
buffer_size = num_samples; % Buffer size in samples
num_transfers = 2; % Number of active USB transfers
timeout = 5000; % Timeout in milliseconds

% Configure RX streaming
device.rx.config.num_buffers = num_buffers;
device.rx.config.buffer_size = buffer_size;
device.rx.config.num_transfers = num_transfers;
device.rx.config.timeout_ms = timeout;

% Configure TX streaming
device.tx.config.num_buffers = num_buffers;
device.tx.config.buffer_size = buffer_size;
device.tx.config.num_transfers = num_transfers;
device.tx.config.timeout_ms = timeout;

Link to image: https://imgur.com/We6yXzD

I obtained an addtional Ax4 and connected the J51-1 and J51-3 trigger connectors for both boards, the transmitter SDR J92 clock out to the receiver SDR J93 clock in with a U.fl female to female cable which you have already completed.

I followed https://github.com/Nuand/bladeRF/tree/m ... i/sync_trx and created a master and slave file. I also created a windows batch file to automate the process. But my output is not receiving anything.

Link to image: https://imgur.com/BiCVS3q

I am using sampling rate of 2MHz and a bandwidth of 1MHz with a 2.45 GHz center frequency.

I'm hoping we can get some resolution to this issue and commented to see if you have made progress and to see if anyone else has solutions for us.

[Vinc]

I used C++ with libbladerf library.

I am not sure how much this matters but I was using Linux in this case. I remember that I had problems on windows and thats why I moved to Ubuntu. I do not remember excatly what problems I had.

I remember that I had problem with saving samples to csv files. If recording was too long csv file wouldnt work correctly if I remember well. And problem with .bin file was that I couldnt record two channels per one device with bladeRF-cli. But that was in some other versions of FPGA/library etc.

Unluckily I did not solve my problem the way I wanted, but instead I made my code to just start over again if overflow occures.

[sabrina23]

Hi Vinc,
When the overflow occurs on the master device, do you observe any corresponding status flags or timestamp anomalies on the slave device’s metadata?
Chill Guy Clicker

[helgaella99]

Hi,
long story short I made 4 RX channels recorder with two BladeRF micro xA9. Their trigger pins are connected and master device clk_out is connected to slave clk_in.

Im using asynchronous mode and saving samples basing on their metadata (timestamp). If there is no overflow there is no problem. But when overflow occurs some samples are "lost". And thats okay. Thats why I want to use timestamps. But here is the problem:
Lets say master device has overflow. Difference between timestamp of first buffer after overflow and buffer before that overflow is for example 71744 where in my case default difference should be 8192 hence 71744-8192=63552 lost samples. But when I correlate recorded MasterRX1 channel and SlaveRX1 channel from a sample where overflow occured for master then there is a shift of 61568 (screenshot, File1 = MasterRX1, File2 = SlaveRX1). So the actual shift does not match timestamp shift.

Link to image:
https://imgur.com/a/2tz01bi geometry dash lite

I did the same thing handling overflows on USRP 2955 (X310) with double Twin RX daugherboards (4 RX channels) and everything worked there.

Versions I use:
'''
bladeRF> version

bladeRF-cli version: 1.9.0-git-fe3304d7
libbladeRF version: 2.5.1-git-fe3304d7

Firmware version: 2.4.0-git-a3d5c55f
FPGA version: 0.15.3 (configured from SPI flash)
'''

Is there a chance to get help?
Is there another way to handle overflows? I know how to lower the chance to get overflow, but I want to be sure that algorithm keeps running correctly even when it occurs.

Best regards

USRP’s UHD driver is battle-tested for multi-channel sync, with hardware-level timestamp alignment (via PPS or clock refs). BladeRF’s trigger sync is solid for start alignment, but overflow recovery seems less robust—possibly a firmware/FPGA quirk (v0.15.3) or libbladeRF’s async handling. Nuand’s forums hint at similar timestamp discontinuity issues (e.g., 2017 overrun threads), often tied to host I/O or buffer mismatches.
The 2048-sample discrepancy smells like a buffer-alignment bug—maybe the master drops an extra 2048-sample chunk post-overflow, but the slave doesn’t, and timestamps don’t reflect it. I’d:

Log timestamps and actual_count around overflows to confirm.
Test sync mode for cleaner recovery.
Cross-correlate post-overflow to realign, treating timestamps as a guide, not gospel.