Build fails against libbladerf 2.0 about soapybladerf

[sparklespdx]

This release notes file is relevant; the libbladerf interface has changed some of the types of the arguments to accommodate the new board and they have provided typedefs.

https://github.com/Nuand/bladeRF/blob/master/host/libraries/libbladeRF/doc/doxygen/relnotes_2_0_0.dox

[guruofquality]

We probably want to keep the old API compiling as well, so it probably needs some creative feature checks in the cmakelists to detect the API different, define a few ifdefs (unless they are present in libbladerf.h already) and ifdef the bejesus out of whatever parts of the code changed.

Its a slightly more nuanced modification, bladerf api is now multichannel, all of the usage of _dir2mod(direction), need to now include the channel and use the BLADERF_CHANNEL_RX/BLADERF_CHANNEL_TX macro. A few other calls are missing, And the streaming API also needs the appropriate updates for multi channel support. All of that and I suppose IFDEFs for old API use.

[sparklespdx]

sounds like a good plan. I am taking a stab at this, doesn't seem like it is super difficult.

One question I have is about the frequency type conversion; libbladerf is expecting something of type bladerf_frequency* (which is a uint64) and the SoapyBladeRF API is expecting a double. It's not safe to cast between these, right? What's the best way to handle that?

I suppose that the numbers we are dealing with might not be large enough to lose accuracy casting between the two types.

[guruofquality]

hold up, i have some unpublished changes for this. The only thing thats missing is the mimo stream support in read/writeStream. I will push when I get home later today.

[guruofquality]

@sparklespdx this branch if you want to try things: https://github.com/pothosware/SoapyBladeRF/tree/bladerfv2

It compiles and it may just work for single channel, the mimo stuff definitely needs the buffers unpacked

if you find and fix anything, send a pull request, thanks!

[sparklespdx]

this is awesome @guruofquality , thanks for working on this.

I know right off the bat that we will need some ifdefs for the loopback modes in bladeRF_Settings, and possibly the gain modes as well. I will make a PR.

I hooked up my board and tried the new build. We definitely have some signs of life! The build is succesful. I am having a bit of an issue with the default sample rate; it's out of our allowable range. Since the library throws an error I can't call SoapySDR.Device() successfully, nor can I use the probe tool with the Soapy cli utility:

root@f3a731d2a08f:/work# SoapySDRUtil --probe="driver=bladerf"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=bladerf
[INFO] bladerf_open_with_devinfo()
[INFO] bladerf_get_serial() = 8a952f477f514a11a049743f0c98a38b
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:2431] bladerf2_set_rational_sample_rate: bladerf2_set_sample_ratel failed: Provided parameter was out of the allowable range
[ERROR] bladerf_set_rational_sample_rate(1000000.000000) returned -2 - Provided parameter is out of range
Error probing device: setSampleRate() -2 - Provided parameter is out of range

I'll see if I can fix this tonight as well.