Still problematic: BladeRF becomes unusable after changing sample rate

[metasim]

This is a request to reopen #778, as we're constantly having the same problem reported.

Symptoms

Whenever the sample rate is changed, the driver hangs or times out.

Here are two examples of the types of errors rendered.

[ERROR @ /privatehost/libraries/libbladeRF/src/backend/usb/libusb.c:1090] Transfer timed out for buffer 0x14d04fe00
[ERROR @ /privatehost/libraries/libbladeRF/src/streaming/sync.c:350] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms

and

ad9361_validate_enable_fir: Invalid: ratio ADC/2 / TX_SAMPL * 16 > TAPS(max 64, adc 480000000, tx 60000000)
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:860] _rfic_host_set_filter: ad9361_set_tx_fir_en_dis(phy, enable) failed: An unexpected error occurred
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1102] bladerf2_set_sample_rate: could not set TX filter mode: An unexpected error occurred
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1002] bladerf2_set_rational_sample_rate: dev->board->set_sample_rate(dev, ch, integer_rate, &actual_integer_rate) failed: An unexpected error occurred
[2024-10-17T19:44:14Z ERROR sources::soapy] Unable to set sample rate to 2 MHz: Other: setSampleRate() -1 - An unexpected failure occurred

Versions

❯ bladeRF-cli -e version

  bladeRF-cli version:        1.9.0-git-41ef6346-dirty
  libbladeRF version:         2.5.0-git-41ef6346-dirty

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

We're currently using the SoapySDR wrappers, as we use a number of SDRs (but bladeRF is our favorite). It's hard for us to pull SoapySDR out of the dependency chain, so I'm hoping someone could off advice of things to try to debug and track this down. Changing sample rate on the fly is a requirement for the system we're building.

[Heshyo]

Do you stop the streams before changing the sampling rate?

[metasim]

@Heshyo I've tried it both ways. Stopping the stream first makes it occur less often, but doesn't eliminate the problem. The only workaround I have is to actually close the device and reopen it and set the new sample rate before activating the stream again.

[metasim]

This issue can somewhat be reproduced using the bladeRF-cli alone:

set frequency rx 1.0G
set samplerate rx 1M
rx config file=samples.csv format=csv n=100M
rx start
rx wait 100ms
set samplerate rx 10M
rx wait 100ms
set samplerate rx 2M
rx wait 100ms
set samplerate rx 40M
rx wait 100ms
set samplerate rx 6M
rx wait 100ms
set samplerate rx 60M
rx wait
rx stop

Output:

  RX1 Frequency: 1000000000 Hz (Range: [70000000, 6000000000])

  Setting RX1 sample rate - req:   1000000 0/1Hz, actual:   1000000 0/1Hz

  Setting RX1 sample rate - req:  10000000 0/1Hz, actual:  10000000 0/1Hz

  Setting RX1 sample rate - req:   2000000 0/1Hz, actual:   2000000 0/1Hz

  Setting RX1 sample rate - req:  40000000 0/1Hz, actual:  40000000 0/1Hz

[ERROR @ /privatehost/libraries/libbladeRF/src/streaming/sync.c:350] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms
[ERROR @ /privatehost/libraries/libbladeRF/src/backend/usb/libusb.c:1090] Transfer timed out for buffer 0x1181c8000
  Setting RX1 sample rate - req:   6000000 0/1Hz, actual:   6000000 0/1Hz

  Setting RX1 sample rate - req:  60000000 0/1Hz, actual:  60000000 0/1Hz

  Error: Operation invalid in current state

I'm not 100% sure, anecdotally the issue seems to happen more when the sample rate goes from something high to something substantially lower.