I am new to BLE/Bluetooth programmming. As known,BLE/Bluetooth is an entire module.Recently I found that, the NimBLE provides the Host Stack or Controller part of Bluetooth.https://github.com/apache/mynewt-core . Here they mention that it supports the mix and match of any host stack with any controller.
So, is it that the HCI layer(through which the host stack interacts) and the Controller (lower bluetooth layer) implementation of all the modules same or is it vendor specific?
If I choosse a host stack from the NimBLE, does the implementation of HCI allow me to operate with any vendor's controller or is that the HCI layer should be implemented with vendor specifications and dependent on the controller.
I assumed that the controller part of the Bluetooth /BLE module has the basic RF and communication section,which will be the same for all modules for its interoperability. I am sorry if the question is trivial.
Any host stack with a hci interface should work with any hci controller, as long as they both have support for the same transport method (UART, USB etc.)
Sometimes, in particular for usb you also need a specific host driver that opens up the transport interface for the particular device. For UART some vendors requires some vendor specific setup packets being sent over UART that configures baud rate etc before hci can start.
Also the host and controller should have a common feature set. For example you can't do much with a host that only supports Bluetooth classic and a controller that only supports BLE.
Some hci controllers implement custom vendor commands to offer extra features over the standard commands, such as for example set custom public Bluetooth device address. A host must also support these commands in order to make use of them.
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.
My question is very basic.I need to know where does all Bluetooth profile such HID, HFP or HSP loaded in Bluetooth stack? Is it in Host layer or in Bluetooth Hardware Chipset such as USB dongle/module or in both Host and Chipset Side?
According to my understanding, we can implement Bluetooth profiles on Host side using packages like BlueZ but at same time Bluetooth chipset which is connected to Host should need some sort of firmware and logic(like CSVD, A-law ) inside its chipset.
A quote found in BlueZ Android package doc: "Wideband Speech support in HFP it is required that BT chip assumes mSBC codec". This means Host layer can implement that Profile only if BT chipset provides the low-level support like mSBC.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which support the Profile 'X'".Please agree or disagree with my understanding.
PFA diagram of my understanding
Position of profile and its low-level firmware
I need to select a USB Bluetooth dongle compatible to Raspberry Pi and customize the HID and HFP using BlueZ.
Advance Thanks to all Bright minds!
There are multiple ways how Bluetooth functionality is implemented in a system based on how much is implemented in the controller and host.
Everything in the controller - App, Upper stack, may or may not HCI(lower and upper stacks communicate through HCI commands and events), Lower stack. Example: Most of Bluetooth Mouse, Keyboard etc, where a single controller is responsible for everything (Bluetooth, RTOS/scheduler, Controlling LED's in the device, etc)
App in Host and lower and upper part of stack in controller. May or may not implement HCI in controller.
Example: Where we use a dedicated Bluetooth chip and integrate it with the Device. Here device will transmit application data to the Dedicated Bluetooth chip. All the Bluetooth protocol related things will be done from BT controller/chip. If you are using an HC-05 module with Arduino module, Arduino will transfer the serial data to the HC-05 module.
App and upper stack in host and lower stack in the controller. Bluez, Bluedroid and all other stacks in Operating systems are of this type. This will communicate with the controller with HCI commands and events.
Example: Mobile phones, Computers, TV with Bluetooth etc (Devices having a powerful Application processor)
So lets assume you are asking about the 3rd type. In this case your assumption is correct. Here all profiles are implemented in the host only. But protocols/codec needed to support them will be implemented in the controller(either firmware or hardware block). For example GAP(For BR-EDR) is implemented in the host but encryption and decryption algorithms are implemented in the controller as Firmware or hardware blocks. For A2DP profiles audio codec/decoders will be implemented in the controller. BT chip then transfers this audio data to host with I2S or other protocols. For BLE Security manager profile, encryption/decryption algorithm is implemented in the host itself, But whitelist, auto connection etc, will be implemented in the controller.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which supports the Profile 'X'".Please agree or disagree with my understanding.
For BlueZ use case this is correct. You need to use the controller with the required hardware capabilities(Firmware + hardware resources).
For the scenarios 1 and 2 the profiles and supporting protocols will be implemented in the controller.
The scenario:
I have one device (Android Phone) that I can control and I want to analyse the Bluetooth capabilities of a different device of which I have limited control/ information - I can only accept/ reject pairing, but I don't known what versions or features are supported (this is that I want to find out).
Question:
From the recorded HCI logs (in the Android Phone), can you determine what version/ technology was actually used in a successful pairing?
In other words, how can you tell whether Bluetooth low energy was used or the Classic Bluetooth (BR/EDR)?
Note: I am not looking for:
the LMP advertisement of the "remote host" as this will only tell
which Bluetooth version is supported (e.g. 4.1) but will not tell
which technology is actually used
also, not looking for the remote extended features telling what
technologies are supported (such as BR/EDR and LE) but without giving
details about which technology is actually used
Thanks :)
If the LE link is set up, HCI LE Meta Event 0x3E with sub event LE Connection Complete 0x01 will be seen in the logs. See core spec v5 Vol 2, part E.
If pairing occurs over the LE link, then SMP PDUs related to pairing will be seen in the HCI logs as pairing occurs on the host. See core spec Vol 3, Part H.
In LE, GATT is used to discover services of the remote device.
If the BR/EDR link is up, HCI Connection Complete event 0x03 will be seen in the logs. In BR/EDR, SDP is used to discover services of the remote device.
I have been asked to figure out how to achieve bluetooth communication through an off-the-shelf dongle (in this case a dongle utilizing the Broadcom BCM2045 chip) using the FTDI Vinculum 2 (VNC2) USB controller. I have custom firmware written for the VNC2 to communicate with a generic USB device with the VNC2 acting as the host, and I can successfully read the VID and PID from the dongle as well as the USB device class, subclass, and protocol. I can also send data to the dongle using the bulk data endpoint and I believe the device is receiving though I have no way to tell at the moment.
So I believe I can communicate with the dongle, the problem is I have no idea WHAT to communicate to it in order to set it up in discoverable mode or to pair it with another discoverable device, nor how to actually transmit data through the wireless link once it is paired. I don't even know if there exists a standard communication protocol for this type of thing or if every device will be different. I have a vague understanding of the bluetooth protocol stack and it is my understanding that I won't be required to fully understand that as it should be implemented in the dongle on one end and in the android smartphone that we hope to connect to on the other end. Like I said, I can currently send data to the bulk endpoint, is it true that this endpoint is only for data transfer over the wireless link and I will need to connect to a different endpoint in order to send setup/configuration messages to the dongle?
In short, I need to know what data to send over the USB bus to control any generic bluetooth dongle if possible or at least one specific bluetooth dongle. I have a USB port sniffer but the complexity of the output while using the dongle to communicate is staggering and I doubt I'll ever figure it out.
Thank you in advance.
Bluetooth dongles communicate with host software stack using HCI (host control interface), which is defined in the Bluetooth spec. For reference, you can look at source code for the open source BlueZ stack (standard linux stack). You could run BlueZ on linux talking to your USB dongle, and use hcidump to capture actual packets going across HCI. You can also check out hcitool and hciconfig for performing specific actions.
I'm trying to do something with this HCI module I got, which uses a CSR Bluecore6 chip. I'm very new to this, so I'd just want to make it perform inquiry scan only (i.e. make it discoverable). To do that, do I need to implement a bluetooth stack or do CSR chips already support that? The datasheet of the module isn't very helpful. Since it's a HCI module only, do I need to implement it inside an external MCU or within the chip?
Any other advise on what to expect will be much appreciated!
Thanks
If it is an HCI module then it will only support the standard bluetooth HCI interface and you must provide a stack on your MCU. CSR also provide a stack implementation (http://www.csr.com/products/19/csr-synergy) for most embedded devices.
you don't need a full stack just to perform inquiry / page scan, you can try to connect the module via its HCI interface to a PC or external MCU and send HCI commands to setup the scans, there are few PC tools lie the hciconfig tool on Linux