Initially I built the Zephyr bluetooth application for native linux and run it in conjunction with Bluez on a BLE controller.I understand that in this, Linux OS and Bluez are used along with Zephyr host stack.
Now, I have flashed bluetooth application from Zephyr stack (samples/bluetooth/beacon)to NXP board successfully. Here there is no bluez used.
For this case, I have a few basic understanding questions:
1. Is the OS functionality also embedded in the bin file that is created after application is compiled. I mean I understand bluetooth stack is Zephyr, but which OS is used on board ?
2. Also, is there any functionality similar to hcitool in Bluez in Zephyr bluetooth stack?
3. Is there any functionality like btmon or hcidump?
To answer your questions:-
Zephyr is an OS itself - it is a Real-Time Operating System (RTOS)
that runs on top of many different types of hardware, just like how
Linux is an operating system that runs on top of many different
hardware. Zephyr is mainly written in C and under the hood talks
directly to the specific processor using its registers and the
vendor's stack. You can find a list of all supported boards
here.
Not identical to hcitool, but there is an hci layer example that
allows you to send raw hci commands. You can find more details on
this here and here. At the end of the day, you may not
need to use hci because it is a low layer and you can probably
achieve the same functionality through higher leve API. All Zephyr's
Bluetooth examples can be found here.
Again, nothing like btmon on Linux how you can see the raw HCI
packets for each command, but Zephyr does support different
Bluetooth logging options depending on the hardware used. More
information on this can be found here.
I hope this helps.
Related
I would like to have a discussion about modifying Bluetooth stack and thinking about what are the important factors that should be considered in general. I have proposed some solutions related to the IP for Bluetooth and now I am in the step to decide which one is more suitable to implement. My different solutions could be implemented on top of GATT or as an adaptation layer on top of L2CAP or on top of Link Layer. My questions are
is there any difference in the energy consumption if the solution is implemented on the top of the Link layer or on top of, for example, L2CAP?
is the Bluetooth stack implementation open source? is the firmware of LL open source?
what else should I consider for the selection of the layer positions?
Is operating system important? why?
The Bluetooth HCI Commands and Events are interoperable; Only the vendor defined(proprietary) HCI commands and Events are not. Top of the HCI layer is called Host. Bottom of the HCI is called Controller.
For Example: BlueZ (Initated by Qualcomm and maintained by Intel now) stack is usually present on Linux. But the Bluetooth Controller might be from Broadcom. They are interoperable until the HCI commands follow the Bluetooth Specifications.
Both L2CAP and GATT are layers above HCI. The Power Consumption always is dependent on Application. Radio Modem and the CPU Core are the most power consuming part of the Bluetooth Communication. The CPU core needs to put the Radio IP to sleep whenever it is not needed. There needs to be an Idle Thread which monitors the application activity and put the Radio to sleep and wakeup.
Most of the Bluetooth Protocol are Finite State Machines and can be implemented using State (Event-driven) design pattern.
Do not give the memory management overhead to applications; it needs to be taken care by the Bluetooth stack.
There are couple of Open source BLE stacks as mentioned by #Youssif here.
I dont understand your 4th Question though.
i am new to Linux and Bluetooth. i know that the standard implementation of the bluetooth protocol stack is bluez. I know that alsa is not supporting bluez anymore and if you want to use audio over bluetooth, you need pulseaudio. so pulseaudio should support HSP/HFP since version 6 and bluez 5.x. Know i was wondering if i can connect a usb-dongle to my hardwareboard (raspberryPi) there is a serial connection to the board. is that right? so the Dongle has the BT-STack and you can use alsa audio over USB like an USB HEadset?
i hope someone can help me.
The answering this vast addressable question is not that easy. I have few hints which will help you to narrow down.
BlueZ is user layer stack to communicate or use the functionality of Linux Kernel Bluetooth subsystem and provides helpers to developers.
USB Dongle itself doesn't have any stack and I don't really understand your question in that sense. To brief, USB Bluetooth Dongle is just the hardware device with Bluetooth functionalities. To make it functional, you need Linux Kernel Bluetooth system support enabled and either you can directly make use of "socket" system calls to pair,connect etc., or use BlueZ to develop applications with API's
BlueZ itself doesn't provide API's for developers, instead it makes use of the DBus to provide methods, properties and signals with vast range functionalities. Check here
If you interested in Audio Playback using Bluetooth, then you should register your media player and audio sink with BlueZ with according media DBus Interfaces.
To add, I am currently developing a framework library to wrap the DBus functionality provided by BlueZ for friendly development of applications. Check this repo and it is currently in initial development phase.
I have a device with a few custom GATT services, and I would like to write a Linux program to interact with it. After some searching I found out that Linux is using BlueZ to handle the Bluetooth LE protocol. I'm using Ubuntu 15.10 with BlueZ 5.35, but I cannot figure out how use this BlueZ from a user-space program. I cannot find an API documentation anywhere, no tutorials, examples, nothing. Is it even possible to use this BlueZ stack to do anything other than just connecting to Bluetooth devices with default services? And if so, where is the documentation? (Preferably C/C++ API but at this point anything goes)
Have a look at attrib/gatttool.c in the bluez sources [1]. Gatttool is a command line utility for connecting to BTLE devices using the C "API". The GATT interface is not exposed in libbluetooth though.
A newer alternative to gatttool and thus another example to learn
from is the btgatt-client, which you can find in
tools/btgatt-client.c (to enable compilation configure bluez with
--enable-experimental).
Besides the C interface bluez integrated a DBUS interface.
bluetoothctl is an example tool using the DBUS interface. The code of
bluetoothctl can be found in client/ [2].
Another example program using the C interface of bluez is the Anki
Drive SDK [3]. It packaged the bluez GATT C interface in its own
library libbzle [4]. When using the C interface you have to connect a
socket when establishing a BTLE connection. The gatttool does this
via the GATT interface, which in turn uses glib iirc. But you can
also do this using syscalls (socket, connect, ...) as explained e.g.
here [5]. This document also explains:
Unfortunately, as of now there is no official API reference to refer to, so more curious readers are advised to download and examine the BlueZ source code.
Gilbert Brault also extracted the GATT interface from bluez [6] and links to a rudimentary doxygen documentation of the GATT interface [7] with the following disclaimer:
This is a work in progress with the intent of documenting all important functions and data structures
Also Szymon Janc gave a nice overview in his talk "Bluetooth on Modern Linux" at the Embedded Linux Conference 2016 [8]. Starting at 42:00 he talks about the unexposed C interface. But in general he seems to recommend the DBUS API (see "Tips" slide at 45:30). Some DBUS documentation can be found in doc/gatt-api.txt [9] and Python examples using the DBUS interface can be found in test/.
Hope this helps.
[1] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/attrib/gatttool.c
[2] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/
[3] https://github.com/anki/drive-sdk/
[4] https://github.com/anki/drive-sdk/tree/master/deps/bzle/
[5] https://people.csail.mit.edu/albert/bluez-intro/c404.html
[6] https://github.com/gbrault/gattclient
[7] http://gbrault.github.io/gattclient/index.html
[8] https://www.youtube.com/watch?v=tclS9arLFzk
[9] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt
I feel your pain. I needed to add user input from a custom BLE peripheral, a simple remote pushbutton, to an embedded program running under Linux (Stretch) on a Raspberry Pi. I was stunned by the needless complexity and Spartan (not a compliment) documentation of the BlueZ API. All the BlueZ “examples” are written from the perspective that Bluetooth is the center of the universe and the user wants to support every Bluetooth device ever invented. In my case I knew exactly the device, service, and GATT characteristics I needed to interact with, and I wanted a minimum overhead task that would do its thing in a low priority thread.
It turns out a BLE central client is pretty straightforward using BlueZ, but it was an arduous road starting with the source for the BlueZ utility bluetoothctl in release 5.49. I accomplished my needs using only three unmodified source files from the BlueZ distribution and excerpts from an additional three source files. Since the BlueZ source is inextricably dependent on D-Bus and the Gnome GLib main loop, I grudgingly included them.
Following OlivierM's generous lead, and in hopes that my embarrassingly massive investment in time saves someone else a month of their life, I have posted my example Bluetooth BLE client on GitHub: https://github.com/jjjsmit/BluetoothBLEClient
It would arguably be simpler and quicker to write a shell script on Linux to do what you need to do. The BlueZ commands are relatively simple and straightforward, and there are many tutorials and questions on how to use it.
Tutorials:-
http://www.jaredwolff.com/blog/get-started-with-bluetooth-low-energy/
https://learn.adafruit.com/reverse-engineering-a-bluetooth-low-energy-light-bulb/control-with-bluez
https://lilyhack.wordpress.com/2014/02/03/ble-read-write-arduino-raspberry-pi/
http://joost.damad.be/2013/08/experiments-with-bluetooth-low-energy.html
Questions:-
Using Bluetooth low energy in linux command line
Bluetooth Low Energy: listening for notifications/indications in linux
How can I connect to the FitBit Zip over Bluetooth 4.0 LE on Linux with bluez?
Once you are more familiar with using the commands manually you can then write a minimal shell script so that this is automated for you.
I had a similar issue which is to interact with a BLE device with a GATT C/C++ API. I have realized there was no such API existing.
The way I fixed my issue was to write my own GATT library. I have pushed the code on Github: https://github.com/labapart/gattlib
I use this library in my own BLE project and it fulfils my needs. I created few examples https://github.com/labapart/gattlib/tree/master/examples that use the library to encourage people to use it and have better feedback.
I recently found out that Qt has Bluetooth Low Energy support as host since Qt 5.7. Qt Bluetooth LE. It is available under LGPLv3 or commercial license, and exposes a C++ API.
How is bluetooth low energy implemented at a device driver level in linux?
Is there a new bluetooth stack code for every new bluetooth version ?
Bluez is the stack for Linux Bluetooth. New version of Bluetooth have resulted in changes in the code, but it's not a complete rewrite or anything drastic like that. Newer versions of Bluetooth are typically extensions of the existing protocol with the exception of Low Energy. Low Energy is completely supported at the kernel level in Linux, but there aren't a lot of convenience libraries for higher level interaction with LE.
Due to the incompleteness of Bluez with LE I've had to interact with the kernel code directly in order to implement functionality with LE. Also, I had to use older kernels that aren't supported by Bluez 5.x and had to use Bluez 4.x.
Already Tim and jhonnash have provided comprehensive information to your question. However, I would like to add one more information from Android Mobile point of view.
New version of Android uses Bluedroid as Bluetooth stack. This is quite different from Bluez.
Bluez has functionality distributed both in user space and kernel space. All the protocols like RFCOMM, HCI and L2CAP are implemented at kernel level and Profiles are implemented at User space. As Tim mentioned, to support Low energy, Bluez has to provide support at kernel level as well as at user space. This some times get difficult to track and understand. Any new changes may require modification in kernel as well as in user space code.
On the other hand, Bluedroid has some advantage over Bluez. Bluedroid has implemented its complete functionality at user space. Due to which any new functionality only needs to be added at user level code. No dependency on Kernel code.
Also, to answer your question of "Is there a new bluetooth stack code for every new bluetooth version ?" No complete rewrite is required for new version of Bluetooth as Bluetooth new versions are backward compatible, so only those portion of codes are added to the already existing stack which is new.
Regards
As your question is not completly clear that's why I also try to give all the possible protocols available to access bluetooth low enery stack for linux.
In UHID Driver "HoG (HID over GATT/Bluetooth-Low-Energy): GATT is a Bluetooth protocol implemented in user-space. When user-space opens an LE (low-energy) connection to a Bluetooth device, the device can advertise HID capabilities via GATT."
As GATT service is properly defined in this link.
There can be other protocols than GATT to access the Low-energy devices. HID Over GATT implementation is done in this manner.
I am going to have a project that can get data from devices that support Health Device Profile(HDP) in Windows.
I find Bluez but it is only available in Linux. Is there any alternative in Windows? Thank You
There are multiple suppliers of Bluetooth stack for desktop Windows. The only one that I know supports HDP directly is Toshiba (though I've no experience with it). So, instead once can add the HDP support outside of the stack software. However, HDP[1] uses the L2CAP protocol which is lower level that RFCOMM protocol that most apps use, and unfortunately Microsoft's Bluetooth stack does not provide a user-level L2CAP API. I started work on a driver to allow user-mode access to the kernel-level API (provided by MSFT in Vista and later) but never finished it. For the other main stacks BlueSoleil doesn't provide a L2CAP API, but Widcomm does.
[1] http://www.alanjmcf.me.uk/comms/bluetooth/Bluetooth%20Profiles%20and%2032feet.NET.html#_Toc266869895