bladerf_set_sample_rate failed when using dump1090 with bladeRF xA5
sdr42c opened this issue · 9 comments
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.
Can you report this to nuand? I don't have equivalent hardware to test on, and this seems like a hardware or libbladeRF problem.
I exchanged a few emails with their support. They suspect it is related to this section:
Lines 267 to 280 in a13356d
Can I assist by providing access to the hardware?
That code is not reached in your case - on your system it's failing earlier, here:
Lines 231 to 234 in a13356d
I think the calibration that times out is triggered automatically within libbladeRF.
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$
Can you raise this with Nuand as AFAIK dump1090 is using their API correctly and the failure is internal to their library.
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"
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.
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.
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.