search

jopohl / urh

Universal Radio Hacker: Investigate Wireless Protocols Like A Boss
GNU General Public License v3.0
10.99k stars 874 forks source link

BladeRF / Recording is corrupted after ~100M samples #925

Closed Semnodime closed 2 years ago

Semnodime commented 2 years ago
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

image image

Platform
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 commented 2 years ago

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.