BladeRF Compatibility

[ralph-intelesense]

I'm working on a way to have Bladerf 2.0 work with this library. I used the the rtlreader.py as a starting point to try to get it working.

However, I do have some questions on the _calc_nosie() function and min_sig_amp variable. Are the numbers used inside these calculations specific to the RTLSDR? How did the value 3.162 come about for min_sig_amp? Why is _calc_noise calculated in that way?

Any help is appreciated.

[xoolive]

Hi there,

Great to hear you’re experimenting with BladeRF support!

Regarding your questions: the noise calculation method in rtlreader.py is really a workaround specific to RTL-SDR limitations. It’s not a good fit for BladeRF, and I wouldn’t recommend using that approach for your device.

RTL-SDR dongles are inexpensive, but the trade-off is a relatively low and somewhat unstable sampling rate. While they advertise 3.2 MS/s, the stable limit is usually closer to 2.56 MS/s (though some setups manage 2.8–3.2 MS/s on USB 3.0). At 1090 MHz, the Nyquist requirement means you ideally want twice the symbol rate to capture the signal transitions reliably. The simple 2 MS/s based demodulation in this library is more of a toy demonstration than a proper solution.

There is a more sophisticated demodulator (as used in dump1090) tuned for 2.4 MS/s. It yields roughly 30% more messages and is the de-facto standard for efficient ADS-B decoding, but it’s also more CPU-intensive and not ideal for pure Python implementations.

BladeRF is a completely different class of device: with sampling rates up to 40 MS/s, you can effectively "draw" the waveform. For reference, Jetvision uses around 16 MS/s and obtains significantly more decodes. With hardware like BladeRF, it makes much more sense to build a dedicated high-rate demodulation pipeline (e.g., 8 MS/s or 16 MS/s). That would be an excellent contribution to the ecosystem.

By the way, I’ve been consolidating some DSP components here:
https://github.com/xoolive/desperado
which I use in:
https://github.com/xoolive/rs1090 (Mode S, with the 2.4MS/s implementation)
https://github.com/xoolive/ship162 (AIS, no need for high sampling rates here)

Right now, I have support for reading from files, TCP sockets, SoapySDR, RTL-SDR, and I’ve just added PlutoSDR earlier today. The goal is to provide a unified synchronous and asynchronous interface to multiple SDR front-ends (By the way, it's in Rust). Eventually, I’d like to expose these through Python wrappers as well. There’s no protocol-specific demodulation in that layer, as each protocol has its own library, but the common sample-source interface should make things much cleaner.

It’s still a work in progress (some frontends cannot work as is in Python wrappers for reasons @abc8747 understands even better than I do...), but help is definitely welcome.

[abc8747]

re Python support for ship162: the only blocker really is the paho-mqtt dependency, requires a bunch of openssl configuration for various architectures, otherwise the Python bindings actually work pretty well!

[xoolive]

Oh I thought there was something with rtl-sdr-rs ?

[ralph-intelesense]

I've looked into flight aware's dump1090 for their bladeRF implementation, but it seems that it only works for the older versions of bladeRFs. If I was more experienced with C I could modify it to fit the BladeRF 2.0s, but I'm out of my depths on this one.

If there's a way I can modify the rtlreader.py to work with BladeRF 2.0 (even as a proof on concept), it would be much appreciated!