does bladerf 2.0/micro support YateBTS

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

spina
Posts: 8
Joined: Tue Sep 18, 2018 7:46 am

does bladerf 2.0/micro support YateBTS

Post by spina » Tue Sep 18, 2018 9:10 am

Hi,

The Nuand product page about the new bladerf 2.0 micro states that it supports YateBTS via libbladeRF bindings.

And I'm confused about this.

First, the bladerf radio module implemented in YateBTS (yate/modules/radio/ybladerf.cpp) does not seem to support the bladerf 2.0 product IDs. AFAICT, it supports legacy and new VID:PID (1d50:6066 and 2cf0:5246) for the bladerf family, but not the bladerf 2.0 (for eg. the micro xA4 has VID:PID = 2cf0:5250).

Code snippet of ybladerf.cpp bellow shows that it won't go far, IMHO:

Code: Select all

	// OpenMoko 0x1d50 Product=0x6066
	// Nuand    0x2cf0 Product=0x5246
	if (!((desc.idVendor == 0x1d50 && desc.idProduct == 0x6066) ||
	    (desc.idVendor == 0x2cf0 && desc.idProduct == 0x5246)))
	    continue;
Then, I know YateBTS relies upon specific versions of the FPGA (something as old as 0.1, I think) it uploads to the bladerf on startup.
You can find them in the directory yate/share/data. There's one for the x40 and another for the x115, but I can't find any suitable for a micro xA4.
Configuration properties in ybladef.conf that would permit to specify the path of such a FPGA are also missing (I mean properties like the ones defined for the bladerf family: fpga_file_40 and fpga_file_115).

And last, YateBTS does not rely upon libladerf bindings anymore, for a long time now.

My question is then dumb stupid: do I miss something obvious as I can't see how this micro xA4 would be compatible with YateBTS ? Or, said otherwise, how YateBTS would be compatible with the bladerf 2.0 devices.

By the way, I think the FX3 download page at Nuand (https://www.nuand.com/fx3_images/) might be misleading, as it states, in the mini CHANGELOG of firmware version 2016-04-07 - v2.0.0:
/Yate/YateBTS does not yet detect this new VID/PID.
Yate users should use v1.9.1 for the time being. Please stay tuned for updates.
AFAIK, Yate detect this new VID/PID, speaking of 2cf0:5246, since revision 6108, with commit message:
Additional check for Nuand's vendor and product when choosing a device to open.
This commit is more than two years old now, updating the FX3 download page would not hurt ;-)

I welcome any help to figure out how I might run YateBTS on this micro xA4, I should miss something obvious. Thanks.

Kind regards,
spina.

PQ@Telma
Posts: 4
Joined: Thu Sep 20, 2018 9:28 am

Re: does bladerf 2.0/micro support YateBTS

Post by PQ@Telma » Thu Sep 20, 2018 9:36 am

I have very recently acquired a Bladerf 2.0 micro xA4 to run YateBTS and it just doesn't work despite Nuand's claim it should.

In short: "modules mbts/ybts do not find any transceiver".

Super disappointed.

robert.ghilduta
Posts: 32
Joined: Thu Feb 28, 2013 11:14 pm

Re: does bladerf 2.0/micro support YateBTS

Post by robert.ghilduta » Thu Sep 20, 2018 12:08 pm

There is currently a libbladeRF 2.x bladeRF patch in the works, that is being beta'd. It has taken slightly longer than we expected to get it production ready. We will prioritize the production release of the libbladeRF 2.x YateBTS support for next week. Please stay tuned, we will have an announcement.

spina
Posts: 8
Joined: Tue Sep 18, 2018 7:46 am

Re: does bladerf 2.0/micro support YateBTS

Post by spina » Fri Sep 21, 2018 8:11 am

Thanks, this sounds good news, though I'm not sure to actually understand.

AFAIK, YateBTS transceiver implementation does not rely upon libbladerf, and a message posted by a Nuand engineer (rtucker) seems to acknowledge this point:
The Yate project implemented their own driver to directly control the bladeRF's hardware, bypassing our C library entirely. Since it's built to control a specific version of the FPGA, it will not work with newer FPGA versions (which use a different control interface) without significant overhaul.
Ref: https://www.nuand.com/forums/viewtopic.php?t=4198

Consequently, I can't see how a patched libbladerf would help, since it's not even used.

So, should we read your answer as we're working on a bladef 2.0 FPGA that supports YateBTS ?
Which would be great, though I can't see how it would work without patching also YateBTS, at least to:
+ add corresponding VID/PID to ybladerf.cpp
+ make YateBTS upload the appropriate FPGA to the device, according to its VID/PID (might introduce some fpga_file_a4 configuration property in ybladerf.conf)

IMHO, patching only libbladerf could help to support older versions of YateBTS, from the era when a transceiver was actually implemented upon libbladerf. But won't achieve any compatibility with current versions, and could not be taken as the bladerf 2.0 family supports YateBTS.
BTW, I think telling that the micro xa4 supports YateBTS via libbladerf bindings is an oxymoron in the first place. Or at least misleading: not everyone reading this will understand that it means the micro xa4 supports outdated and unmaintained versions of YateBTS.

Or I still miss something obvious, which would be great.

Thanks in advance for your help, and your work.

Kind regards,
spina.

PS: May be I could help. I mean, if you can provide an FPGA for a micro xa4, compatible with YateBTS transceiver implementation, I'd be happy to write the YateBTS patch to support it. I agree this is the easy part of the job, but I unfortunately does not have the comprehension required to help working on the FPGA.

robert.ghilduta
Posts: 32
Joined: Thu Feb 28, 2013 11:14 pm

Re: does bladerf 2.0/micro support YateBTS

Post by robert.ghilduta » Fri Sep 21, 2018 10:11 am

That is indeed correct, the previous version of YateBTS does not use libbladeRF. The newer version however will, and it's implications are akin to the work we put in to develop the OpenBTS-UMTS transceiver. The switch from non libbladeRF to a libbladeRF implementation therefore is quite the changeset but should be quite worth it. From now on YateBTS will be able to benefit from all of the updates and new features in libbladeRF.

spina
Posts: 8
Joined: Tue Sep 18, 2018 7:46 am

Re: does bladerf 2.0/micro support YateBTS

Post by spina » Fri Sep 21, 2018 12:05 pm

These are actually very good news.

Reading YateBTS will (again) change its mind, and go back to a transceiver implementation based upon libbaldeRF, is itself a good point. It's obviously the sane way to unify your devices support. It might also represent quite some work, and I understand the delay. As you said, it should be "quite worth it".

Reading this work will also benefit to the OpenBTS-UMTS transceiver is definitely a plus.

Just to not starve my curiosity: so, you will soon contribute a somewhat large (and architectural) patch to the YateBTS project ? Considering that YateBTS does (currently) support only the Nuand bladeRF devices, and the architectural nature of the patch you will submit, could you elaborate a bit about the relationship between the projects/companies ?
It's just curiosity, and you might safely ignore this question.

Thanks again for your answer, and the big work which is currently going on.

Kind regards,
spina.

l-fy
Posts: 3
Joined: Tue Oct 02, 2018 3:34 am

Re: does bladerf 2.0/micro support YateBTS

Post by l-fy » Wed Oct 03, 2018 12:49 pm

Hello everybody,

We are working on the YateBTS support for BladeRF 2. We are very excited about the new board, because the support in YateBTS will also add support in the YateENB (the LTE which is a part of the comercial side - MIMO, anyone :) ).
The new board support will be in another module not ybladerf. We've modified the radio API in yate and curently working on the ybladerf2 which will use the libbladerf.
In the past we've choose of not using libbladerf because when we did the support for the bladerf the threading model between yate and libbladerf didn't match. That is not the case anymore. kudos Rob.
Also the firmware we use is an old version because it was tested of being stable for mobile carriers production environment (which means stable auto calibration and all kind of other measurements).
Fortunately we don't think we will need to keep that policy for the new board ;)
So stay tuned because in the next couple of months there will be a YateBTS + BladeRF2 = Love again.

Diana Yate Cionoiu

PQ@Telma
Posts: 4
Joined: Thu Sep 20, 2018 9:28 am

Re: does bladerf 2.0/micro support YateBTS

Post by PQ@Telma » Fri Oct 05, 2018 5:59 am

As a client of Nuand who based his purchases on what was advertised publicly, I see things in a slightly different way:

1. In August, Nuand is proudly announcing the new BladeRF 2.0 as fully compatible with OpenBTS, YateBTS, srsLTE, etc.

2. In October, we are all told ("hello everybody") that we should welcome as a fantastic news the fact that the said compatibility could be fixed by Christmas...

3. Let aside that in the meantime - with a complete "silence" regarding this issue - there is simply NO transceiver available for these devices...

4. Finally, the owners of BladeRF 1.x (I am one) also remain completely stuck because there are NO sytem updates which could have installed libladeRF 2.x (Ubuntu 18.10, Debian buster, Arch Linux, etc.).

Really, it is not serious and highly disappointing.

l-fy
Posts: 3
Joined: Tue Oct 02, 2018 3:34 am

Re: does bladerf 2.0/micro support YateBTS

Post by l-fy » Fri Oct 05, 2018 7:23 am

Hi PQ@Telma:

srsLTE and YateBTS are 2 different projects.
Their respective transceivers are made by their own developers.
We (YateBTS) working closely with Nuand to get this done as soon as possible.
But we are committed to a high standard of quality, as we always been. And the famous triangle goes like this: cheap, fast or good. You can have any 2 but never all 3 in the same time. Which one 2 do you prefer?

Regards,
Diana Yate Cionoiu

spina
Posts: 8
Joined: Tue Sep 18, 2018 7:46 am

Re: does bladerf 2.0/micro support YateBTS

Post by spina » Fri Oct 05, 2018 12:05 pm

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 ?

Kind regards,
spina.

Post Reply