I'd like to second PQ@Telma.
AFAICT, he's right that currently, which means till "a couple of months", bladeRF 2.0 devices are NOT compatible with any transceiver based application:
- neither compatible with implementations that communicate directly to the device through the FPGA (YateBTS from 5.x to 6.1), since appropriate FPGA are not available
- nor compatible with implementations based upon libbladeRF 1.x (older YateBTS versions, OpenBTS, OpenBTS-UMTS, OpenLTE, srsLTE, OpenAirInterface), since libbladeRF 2.x is not backward compatible with libbladeRF 1.x
And I think your point, Diana, about choosing between "cheap, fast or good" is quite unfair: it seems he's purchased a bladeRF 2.0 device based upon the features claimed by the official products presentation at Nuand's web site, among which the compatibility with YateBTS and srsLTE. IMHO, and joking, you've just omitted to offer him the choice to get what he's paid for.
I understand you're doing your best to work things out properly for YateBTS, and I agree that srsLTE is another project.
But I still think the product page would have been better worded as:
bladeRF 2.0 devices will be compatible with YateBTS and srsLTE when i) we at Nuand have stabilized libbladeRF 2.0, and ii) we at YateBTS have updated our software accordingly and iii) them, at srsLTE, have updated their software accordingly.
Things are actually even a bit worst: almost any software that used to work
with libbladeRF 1.x (for e.g. OpenBTS, OpenBTS-UMTS, OpenLTE, srsLTE, OpenAirInterface), won't even compile with libbladeRF 2.x.
For now, only GNU Radio is actually supported, thanks to robertghilduta commits to the gr-osmosdr project. If, and only if, you compile your whole SDR stack: for e.g. within Linux userland, latest Ubuntu (18.10) and Debian (sid) packages still provide gr-osmosdr 0.1.4 and libbladeRF 1.x, thus no chance there to use any bladeRF 2.0 device out of the box.
And, unfortunately, libbladeRF 2.0 not being backward compatible with libbladeRF 1.x may cause headaches to users/developers/maintainers that would slow its adoption:
- Distributions maintainers have the choice to push the new libbladeRF 2.0 library, breaking all user applications but GNU Radio that used to work with libbladeRF 1.x (provided they also push a release of gr-osmosdr with this summer commits from robertghilduta), or pine libbladeRF to 1.x, to not break user applications for legacy devices, but striping any chance to support bladeRF 2.0 devices; headaches for a distribution maintainer, especially who maintains an LTS, stable branch, etc, kind of release.
- If, as a user, I own devices of both types (say a x40 and a xA4), I have the same dilemma: build my software stack upon libbladeRF 1.x, keep using all my favorite applications, but regret my xA4 purchase, OR build my software stack upon libbladeRF 2.x, be happy to play with my brand new xA4, but sadly can't use any of my applications anymore; a pain for users
- As a developer, whichever bladeRF device I own or not, I also have to choose whether I write my code with a development stack based upon libbladeRF 1.x or libbladeRF 2.0, thus targeting different users/devices; a pain for developers, too
- All points above apply more or less directly to any supported platform: MS Windows, Mac OS X, and obviously Linux.
I take your argument that quality requires time
. Indeed. And I understand designing and maintaining an API is not an obvious job.
What I don't understand is why libladeRF 2.x, in order to support the new devices, had
to break all applications that used to work, and nearly all your users base workflow ?
AFAIK, libbladeRF 1.x was not that big (which does not mean it's not complex) and I can't see the technical reasons that would have made it impossible to extend the API to support the new devices, and
preserve, for some time, API and semantic related to /not so legacy/ devices and applications. Mark deprecated
the parts you definitely want to eventually remove. That is backward compatibility, you know all this.
It seems that references to YateBTS, srsLTE, or any other software but GNU radio, though still present in the product family presentation, have been removed from the detailed product pages of the respective bladeRF micro devices on the Nuand web site, which is a fair move.
Though, it's been too late
for users who had already
purchased any bladeRF 2.0 device in the hope of running their habitual applications via libbladeRF bindings
That's another area where I found your answer to PQ@Telma was a bit unfair.
BTW, I'm trying to port OpenLTE to libbladeRF 2.x, and once I've patched it to match the new channel/direction API of libbladeRF, which makes it now builds, I've asked the forum for any advice or documentation to get any further. It's only a few days ago, and I'm not upset with it hasn't yet deserved any kind of help or support.
My concern is srsLTE and OpenAirInterface, for example, are well alive and maintained projects, and might at one point in time
switch to libbladeRF 2.x.
At the other side, OpenLTE is a bit outdated, and unmaintained
, but still widely used, and I think one of the applications bladeRF users may wish to run. And this applies also to OpenBTS, OpenBTS-UMTS, and probably others niche software I'm not aware of.
Hence, I think sharing a few advices or documentation with users, that are inclined to help update these software to support libbladeRF 2.x, could benefit to everyone. Couldn't it ?