BladeRF / Recording is corrupted after ~100M samples

[Semnodime]

Expected Behavior

Recording a signal longer than 100M samples should not interfere with signal integrity.

Actual Behavior

After recording ~100M samples both the appearance in the live preview as well as the measurement in the recorded file confirm that test signal pulses are reduced in length and their regularity is compromised.
This implies that the signal is somehow altered, maybe in samplerate, maybe buffers are dropped, maybe something else.

I have recorded the signal via the native bladeRF-cli for reference and can ensure, that the bug is not due to bugs in the firmware of the bladeRF.

As I currently don't have a setup to record a pure sine wave, I cannot determine the exact moment when signal integrity is lost.
I speculate the threshold is actually near 102,3M / 102,4M samples and might be related to some binary counting scheme (2^10 = 1024).
EDIT: After 101M samples already signal integrity appears to be compromised, so it does not appear to be related to 2^10.

Steps To Reproduce

1. Install Linux Mint 20.1 Cinnamon
2. Run apt update && apt upgrade
3. Install the latest urh from source
4. Install bladeRF dependencies via apt install git libusb-1.0-0-dev libtecla-dev help2man
5. Build the latest libBladeRF and bladeRF-cli from source cmake -DBUILD_DOCUMENTATION=ON -DENABLE_BACKEND_LIBUSB=ON -DINSTALL_UDEV_RULES=ON -DENABLE_LOG_FILE_INFO=ON -DENABLE_LIBTECLA=ON ../
6. Plug in the bladeRF into USB3 with SuperSpeed
7. Download the latest bladeRF firmware and flash it
8. Download the latest FPGA image and define it as autoloading
9. Setup a test signal with fixed pulse lengths
10. Open urh
11. Record your test signal at 5MS/s-60MS/s sample rate for at least 150M samples. (I cannot prove nor disprove the bug at 2.5MS/s sample rate)
12. Save and Open capture
13. Measure pulse length before 100M samples and after
14. See error

Screenshots

Platform

• OS: Linux Mint 20.1 Cinnamon
• URH: 2.9.2
• Python: 3.8.10
• Installed via git / built from source
• bladeRF-cli: 1.8.0-git-5a146b2a
• libBladeRF: 2.4.1-git-5a146b2a
• bladeRF_fw_latest.img: 2021-01-12 - v2.4.0
• hostedxA4-latest.rbf: 2021-10-04 - v0.14.0

Additional Context

Apparently, urh's libbladeRF is outdated.

[INFO::Device.py::start_rx_mode] BladeRF: Starting RX Mode
[INFO @ host/libraries/libbladeRF/src/helpers/version.c:79] Firmware version (v2.4.0) is newer than entries in libbladeRF's compatibility table. Please update libbladeRF if problems arise.
[INFO @ host/libraries/libbladeRF/src/helpers/version.c:103] FPGA version (v0.14.0) is newer than entries in libbladeRF's compatibility table. Please update libbladeRF if problems arise.
[INFO::Device.py::log_retcode] BladeRF-OPEN: Success

[jopohl]

Can't reproduce. Captured with my BladeRF at 10 MS/s over 400M samples and observed no differences in pulse lengths. Regarding:

Apparently, urh's libbladeRF is outdated.

Since you built URH from source it uses the libbladeRF from your system.

[Semnodime]

The problem arises due to the buffer on the FPGA board being maxed out and samples being dropped (e.g. when the USB connection does not provide the high data rate continuously).
A detection mechanism in urh would be nice, but checking the "buffer full" indicator led on the FPGA board is a minimal solution.