Sample Rate is Halved When Using BLADERF_FEATURE_OVERSAMPLE

[cwozny]

When using the new oversample feature, the sample rate seems to be effectively half of what gets set in bladerf_set_sample_rate(). This was tested by using a signal generator and feeding in a pulsed waveform with a 48 us duration. With oversample feature enabled, 8-bit resolution, and 50 Msps sampling rate, the pulse duration was incorrectly being measured as ~24 us. With default feature enabled, 8-bit resolution, and 50 Msps sample rate, the pulse duration was correctly being measured as ~48 us.

This was tested minutes apart and the only code delta was in this commit: https://github.com/cwozny/sdr_channelizer/commit/a36a758cb4c5a370b7851fd3c206c6b1297c71b8

I also tried to enable oversampling after setting the sampling rate due to an issue that @rthomp10 fixed with commit 86d68ee, but this didn't correct the sampling rate either.

Plots included for reference, note the time per division showing the pulse duration being halved when using oversampling.

Board: Nuand bladeRF 2.0 (bladerf2) Serial #: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx VCTCXO DAC calibration: 0x230b FPGA size: 77 KLE FPGA loaded: yes Flash size: 64 Mbit USB bus: 0 USB address: 1 USB speed: SuperSpeed Backend: libusb Instance: 0

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

Firmware version: 2.4.0-git-a3d5c55f FPGA version: 0.15.0

[alex-appetiti]

I've also come across the same issue, and was wondering whether or not the Nuand team had any updates.

My setup:

• I'm using libbladeRF 2.5.0 (as per nix)
• USB3.0
• Firmware 2.4.0
• FPGA 0.15.3

• After opening the device, I do the following setup:

  • bladerf_enable_feature using BLADERF_FEATURE_OVERSAMPLE + true. (Edit: I've also tried not using this, no difference in results).
  • sample rate to 20MHz via bladerf_set_sample_rate.
  • bandwidth to 20MHz via bladerf_set_bandwidth
  • bladerf_init_stream with the format field set to BLADERF_FORMAT_SC8_Q7_META and samples_per_buffer set to 65_536
  • bladerf_enable_module true for 0 (RX0)
  • bladerf_stream with bladerf_channel_layout_BLADERF_RX_X1 (0)

  Note that I have also repeated the experiment for RX_X2 and enabling both modules as well.

  A first curiosity is had when looking at one instance of a callback:

  • Looking at the num_samples argument, for 16bit I get 65_536 and 8bit I get 32_768 (half).
  • When counting the number of messages I get, for 16bit I get 128 and 8bit I get 64. This number seems to always be the num_samples divided by 512 (the USB3.0 block size in SC16_Q11 samples). Going under this number, I get discontinuities in the timestamp, going above, I seem to start dangerously invading the other buffers.
  • When counting the actual number of samples received, for 16bit I get 65_024 and 8bit I get 65_024.
  • Given the 16 byte = 4/8 sample metadata header for each message, this adds up to 65_536 for both.

The curiosity aside, just by profiling the time it takes to get 50,000,000 samples, in the 16-bit version I get them in 2.5s, whereas in the 8-bit version I get them in 5s, suggesting that the sample rate is actually 10MHz.

[alex-appetiti]

As an update - I've now tried to set the sample_rate via the bladerf_set_rational_sample_rate function instead of the bladerf_set_sample_rate function, and the timings now match, although I do get the following warning Unhandled case in ad9361_tx_quad_calib line 3023 clkrf 10000000 clktf 20000000.

I'm a bit confused as looking at the source it seems that bladerf_set_rational_sample_rate is just converting to an integer then calling bladerf_set_sample_rate anyway.