Hello,
I am an intern at a company. After having developed a few Low Energy applications using BlueZ, the DBus-way and the mgmt way, I was ready for my new assignment. The applications I developed were targeted at an embedded ARM platform running Linux without DBus. The new application I need to develop needs to connect to a device, receive some values using indications, then disconnect.
To my amazement my employer told me that they wanted me to explore alternatives to BlueZ, as they were unsure of the?reliability and especially the performance. They sent me a Wikipedia page listing several embedded Bluetooth stacks, like BlueCode+, and asked me to prove, for every single stack, why Bluez was 'better'. My initial response was "Because it is the official supported Bluetooth stack for Linux, our target development OS." Exploring the other solutions, I could not find any rationale as to why I would choose a different protocol stack.
My question therefore is, what would justify switching from Bluez to a different stack? Are there any specific problems or oddities in Bluez that would make it a poor choice for an embedded platform? I haven't come across any indication as to why Bluez would make a less suitable choice as stack. Are there any benchmarks I could test or view in terms of performance and reliability? Is there even a difference in performance and reliability? I am not asking you to do my homework, but a pointer to any sort of rationale behind possibly switching would be appreciated.The application I am asked to develop is non-commercial, so licensing is not an issue.
I am also not asking this to use as an argument in a discussion with my employer, I just want to correctly perform my assignment by choosing a suitable stack and have a solid knowledge as to why I am using that specific bluetooth stack, so I can explain it when being asked during an assessment.
Thank you in advance for your help!
Have a great day,
Ad Zeevaarders
Hi Ad,
> I am an intern at a company. After having developed a few Low Energy applications using BlueZ, the DBus-way and the mgmt way, I was ready for my new assignment. The applications I developed were targeted at an embedded ARM platform running Linux without DBus. The new application I need to develop needs to connect to a device, receive some values using indications, then disconnect.
>
> To my amazement my employer told me that they wanted me to explore alternatives to BlueZ, as they were unsure of the reliability and especially the performance. They sent me a Wikipedia page listing several embedded Bluetooth stacks, like BlueCode+, and asked me to prove, for every single stack, why Bluez was 'better'. My initial response was "Because it is the official supported Bluetooth stack for Linux, our target development OS." Exploring the other solutions, I could not find any rationale as to why I would choose a different protocol stack.
>
> My question therefore is, what would justify switching from Bluez to a different stack? Are there any specific problems or oddities in Bluez that would make it a poor choice for an embedded platform? I haven't come across any indication as to why Bluez would make a less suitable choice as stack. Are there any benchmarks I could test or view in terms of performance and reliability? Is there even a difference in performance and reliability? I am not asking you to do my homework, but a pointer to any sort of rationale behind possibly switching would be appreciated.The application I am asked to develop is non-commercial, so licensing is not an issue.
I have heard of at least 3 instances where companies choose a different stack than BlueZ for their Linux system. All of these were small embedded systems running Linux and they all were looking into BLE support. The end result was that they paid good money for a proprietary stack and hoped to get good support and integration. Reality was they did not and switched back to BlueZ and had things up and running within less than 2 weeks.
The world is clearly shifting towards BLE and BlueZ can actually be configured as BLE only. There are options in the kernel that you can disable and also configurations options in userspace. That reduces the stack and memory size and also reduces the requirements for qualification.
BlueZ is pretty 14+ years old by now. It has been everywhere and in all kinds of products. The advantage that it runs from tiny peripherals, over set top boxes, to tablets, phones, laptops and cars, means the stack has gotten extensive testing. It is the same code base no matter where you run it. That is something no other stack manufacturer can provide. Mainly since they just keep branching a version for a customer and then forget about it. If you buy a stack, you pay for that branch and every modification extra you need will cost you an arm and a leg. With BlueZ, it is free and you get also the testing for all the other markets and companies that are using BlueZ.
I think interoperability wise BlueZ is hands down the best stack. It does get tested at UnPlugFests and has tons of internal unit and end-to-end tests that verify many areas.
If you are looking at Bluetooth stacks, then BlueZ is also the only one that has its core hardware abstraction and core layers implemented in the kernel. That is something that you will not find anywhere else. It is extreme stable code and also clean code. All interfaces are documented as well.
>From my knowledge is that even pentesting houses uses BlueZ as prime test example for their tools. Mainly since you are unable to crash BlueZ remotely. The code is written in a way that is robust against remote attacks. Look for security presentation about Bluetooth and you see what I mean. Most of them can be found online.
In case you are looking for BLE, you might just look for features that you care about. For example LE Secure Connections support is already part of BlueZ. The only other OS that I know of is iOS. All the other stacks have ignored LE SC support. Keep in mind that Bluetooth 4.2 got released over a year ago and BlueZ has LE SC support since exactly 1 year now. LE L2CAP Connection Oriented Channels is another of these features. Try to find that in other stacks.
BlueZ code size is large. That is just a fact. However it contains analyzing tools, emulator tools, testing tools, sample code and a lot more. It also comes in various flavor, BlueZ upstream, BlueZ for Android, BlueZ Peripheral that can be build and used. They are different frontends that share a lot of code. Some use D-Bus, some use Unix socket and some use no IPC at all.
However if you look at Bluedroid from Android, then you will see that that code base is huge as well. And that is just the stack. It contains no tools around it and its debugging capabilities are bad.
Look at the debugging capabilities of BlueZ and the tools we provide. If something goes wrong, can you analyze what goes wrong and if that is on your side or the remote side. Or do you have to purchase 30k EUR Bluetooth protocol analyzer and still can not figure out what went wrong.
> I am also not asking this to use as an argument in a discussion with my employer, I just want to correctly perform my assignment by choosing a suitable stack and have a solid knowledge as to why I am using that specific bluetooth stack, so I can explain it when being asked during an assessment.
We can not fight FUD (fear, uncertainty and doubt) since BlueZ does not have a marketing department. So you will have stack and silicon manufacturers coming in and try to sell you their stacks for a lot of money. If you buy into that FUD, then you might get screwed over later. As I said, I have it from 3 companies that paid good money and still ended up using BlueZ.
If you run Linux and don't use BlueZ, you are just making your life harder and more complicated for no reason.
Regards
Marcel
Hi,
On Fri, Nov 27, 2015 at 5:51 PM, Simon Wood <[email protected]> wrote:
> On Fri, November 27, 2015 1:32 am, Ad Zeevaarders wrote:
>> Hello,
>>
>>
>> I am an intern at a company. After having developed a few Low Energy
>> applications using BlueZ, the DBus-way and the mgmt way, I was ready for
>> my new assignment. The applications I developed were targeted at an
>> embedded ARM platform running Linux without DBus. The new application I
>> need to develop needs to connect to a device, receive some values using
>> indications, then disconnect.
Well you can in fact use most of the protocols without D-Bus, in fact
that what we did in BlueZ for Android.
>> To my amazement my employer told me that they wanted me to explore
>> alternatives to BlueZ, as they were unsure of the reliability and
>> especially the performance. They sent me a Wikipedia page listing several
>> embedded Bluetooth stacks, like BlueCode+, and asked me to prove, for
>> every single stack, why Bluez was 'better'. My initial response was
>> "Because it is the official supported Bluetooth stack for Linux, our
>> target development OS." Exploring the other solutions, I could not find
>> any rationale as to why I would choose a different protocol stack.
Most of the userspace stack will probably perform worst than BlueZ and
cannot offer the same level of integration with Linux kernel both at
the driver level, USB, UART, etc and other protocols like 6LowPAN
which will probably make them less reliable as well. I actually never
seem any other stack that has emulation support and doing end to end
tests like BlueZ can do.
>
> Hi,
> This maybe of no interest, but I wanted to point out another alternate
> 'community written' stack....
>
> http://bluekitchen-gmbh.com/btstack/
>
> Started as a completely Free project, but was then relicensed to be 'free
> for non-commercial'. Depending on what you need it might be usable for
> your projects.
If I would have started a new stack for Linux Id probably use the
kernel parts otherwise it is pretty much bluedroid all over again.
> BTW you have a hard task if employers just don't like Bluez :-( To me (as
> just a user) the code size would be the major detractor, but it does work
> pretty well.
There are actually a lot of tools involved in BlueZ, just the emulator
and the monitor already account for quite a big part of the userspace.
Anyway Im pretty sure the authors of this btstack do use BlueZ tools
to develop since they have things like HCI_DUMP_BLUEZ.
> Good luck,
> Simon
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
On Fri, November 27, 2015 1:32 am, Ad Zeevaarders wrote:
> Hello,
>
>
> I am an intern at a company. After having developed a few Low Energy
> applications using BlueZ, the DBus-way and the mgmt way, I was ready for
> my new assignment. The applications I developed were targeted at an
> embedded ARM platform running Linux without DBus. The new application I
> need to develop needs to connect to a device, receive some values using
> indications, then disconnect.
>
> To my amazement my employer told me that they wanted me to explore
> alternatives to BlueZ, as they were unsure of the?reliability and
> especially the performance. They sent me a Wikipedia page listing several
> embedded Bluetooth stacks, like BlueCode+, and asked me to prove, for
> every single stack, why Bluez was 'better'. My initial response was
> "Because it is the official supported Bluetooth stack for Linux, our
> target development OS." Exploring the other solutions, I could not find
> any rationale as to why I would choose a different protocol stack.
Hi,
This maybe of no interest, but I wanted to point out another alternate
'community written' stack....
http://bluekitchen-gmbh.com/btstack/
Started as a completely Free project, but was then relicensed to be 'free
for non-commercial'. Depending on what you need it might be usable for
your projects.
BTW you have a hard task if employers just don't like Bluez :-( To me (as
just a user) the code size would be the major detractor, but it does work
pretty well.
Good luck,
Simon