bladerf_set_sample_rate failed when using dump1090 with bladeRF xA5

[sdr42c]

While trying to use dump1090 with a bladeRF 2.0 micro xA5 I am getting multiple errors, seemingly related to the sample rate. I've tried with both the hostedxA5-latest and adsbxA5.rbf bitstreams.

I have compiled dump1090 from source as I am using the latest libbladeRF version that is not packaged for Debian bullseye.

This is the error out with the hostedxA5-latest.rbf bitstream:

>dump1090  --bladerf-fpga ~/hostedxA5-latest.rbf 
Sun Feb  6 18:42:51 2022 GMT  dump1090-fa unknown starting up.
bladeRF: loading FPGA bitstream from ~/hostedxA5-latest.rbf
Calibration TIMEOUT (0x16, 0x80)
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:369] _rfic_host_set_sample_rate: ad9361_set_rx_sampling_freq(phy, rate) failed: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1096] bladerf2_set_sample_rate: rfic->set_sample_rate(dev, ch, rate) failed: An unexpected error occurred
bladerf_set_sample_rate failed: An unexpected error occurred

Same error output with the adsbxA5.rbf bitstream:

>dump1090  --bladerf-fpga ~/adsbxA5.rbf 
Sun Feb  6 18:43:24 2022 GMT  dump1090-fa unknown starting up.
bladeRF: loading FPGA bitstream from ~/adsbxA5.rbf
Calibration TIMEOUT (0x16, 0x80)
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:369] _rfic_host_set_sample_rate: ad9361_set_rx_sampling_freq(phy, rate) failed: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1096] bladerf2_set_sample_rate: rfic->set_sample_rate(dev, ch, rate) failed: An unexpected error occurred
bladerf_set_sample_rate failed: An unexpected error occurred

Device and version info:

>bladeRF-cli --exec info --exec version

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

  bladeRF-cli version:        1.8.0-git-5a146b2a
  libbladeRF version:         2.4.1-git-5a146b2a

  Firmware version:           2.4.0-git-a3d5c55f
  FPGA version:               0.14.0 (configured by USB host)

dump1090-fa version:

>dump1090  --version
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                               dump1090-fa unknown |
| build options: ENABLE_BLADERF                                             |
-----------------------------------------------------------------------------
  detected runtime CPU features: ARMv7+NEON+VFPv4 
  selected DSP implementations: 
    magnitude_uc8                            neon_vrsqrte_armv7a_neon_vfpv4
    magnitude_uc8_aligned                    neon_vrsqrte_armv7a_neon_vfpv4_aligned
    magnitude_power_uc8                      neon_vrsqrte_armv7a_neon_vfpv4
    magnitude_power_uc8_aligned              neon_vrsqrte_armv7a_neon_vfpv4_aligned
    magnitude_sc16                           neon_vrsqrte_armv7a_neon_vfpv4
    magnitude_sc16_aligned                   neon_vrsqrte_armv7a_neon_vfpv4_aligned
    magnitude_sc16q11                        neon_vrsqrte_armv7a_neon_vfpv4
    magnitude_sc16q11_aligned                neon_vrsqrte_armv7a_neon_vfpv4_aligned
    mean_power_u16                           u32_armv7a_neon_vfpv4
    mean_power_u16_aligned                   u32_armv7a_neon_vfpv4_aligned
    count_above_u16                          neon_armv7a_neon_vfpv4
    count_above_u16_aligned                  neon_armv7a_neon_vfpv4

I am able to use bladeRF-adsb without issue on the same setup but ideally would like to run everything within dump1090.

[mutability]

Can you report this to nuand? I don't have equivalent hardware to test on, and this seems like a hardware or libbladeRF problem.

[sdr42c]

I exchanged a few emails with their support. They suspect it is related to this section: https://github.com/flightaware/dump1090/blob/a13356d801e75d17c15de5737fe0fc0d28a977e9/sdr_bladerf.c#L267-L280 Can I assist by providing access to the hardware?

[mutability]

That code is not reached in your case - on your system it's failing earlier, here:

https://github.com/flightaware/dump1090/blob/a13356d801e75d17c15de5737fe0fc0d28a977e9/sdr_bladerf.c#L231-L234

I think the calibration that times out is triggered automatically within libbladeRF.

[piwi3910]

the same problem also happens with the xA9

piwi@sdr01:~/dump1090/package-bullseye$ ./dump1090 --bladerf-fpga /usr/share/Nuand/bladeRF/adsbxA9.rbf
Wed Mar  1 12:02:58 2023 UTC  dump1090-fa 8.2 starting up.
bladeRF: loading FPGA bitstream from /usr/share/Nuand/bladeRF/adsbxA9.rbf
Calibration TIMEOUT (0x16, 0x80)
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:369] _rfic_host_set_sample_rate: ad9361_set_rx_sampling_freq(phy, rate) failed: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1096] bladerf2_set_sample_rate: rfic->set_sample_rate(dev, ch, rate) failed: An unexpected error occurred
bladerf_set_sample_rate failed: An unexpected error occurred
piwi@sdr01:~/dump1090/package-bullseye$

[mutability]

Can you raise this with Nuand as AFAIK dump1090 is using their API correctly and the failure is internal to their library.

[piwi3910]

already did, and they replied: "as https://github.com/Nuand/bladeRF-adsb is compiling correctly and is able to use the fpga with the file: https://www.nuand.com/fpga/adsbxA9.rbf correctly the problem doesn't lay with the lib or FPGA bitstream"

[mutability]

Okay. I'm not gonna get into a blame game with nuand. dump1090 is calling a regular libbladerf function which then fails with an unexpected error; if nuand can't help you further with where the problem lies, I'm not sure I can help.

[sdr42c]

Can you formally remove support for bladeRF in that case?

I do not disagree that Nuand has been uncooperative but, despite your assertion, the situation is in a stalemate due to deflection on both sides. I regret making a decision to buy into the bladeRF platform which was partly driven by (what I thought was) dump1090 support.

I am glad to provide access to my bladeRF hardware or anything else you think that would be helpful to break the deadlock, I hate to just complain.

[mutability]

We actually use the bladeRF code on older bladerf hardware that's out in the field, so I can't just remove support outright.

I can add a note to the README noting that there are some problems with newer hardware (or maybe a newer lib?) if you like?

Maybe the path forward is to build a minimal standalone demo of the problem (it should just be a case of running the same API calls that dump1090 executes in a little test app -- the failure happens early on, so this should be straightforward) and pass that on to nuand so there's no ambiguity around "but our ADS-B stuff works!". If there's something wrong in how dump1090 is using the API then I'm happy to fix that but currently I have no information about what needs to be changed.