Bluetooth Implementation: Technology for a Smarter Life (Part 2)

In my last blog, we had talked about some amazing application ideas of Bluetooth. Ideas without implementation supremacy are just like faded dreams. So, in this article I would like to discuss about the competencies required for developing a Bluetooth based product.

Numerous semiconductor companies are providing System on chip (SOC) having capability of both Bluetooth Classic and Bluetooth Low Energy (BLE). While selecting SOC we have to look for some major attributes like price, Bluetooth access range, power consumption and most importantly vendor support. Very recently Bluetooth SIG introduce Mesh Networking for Bluetooth device, soon its compatibility will also play key role. Developing consumer products, definitely involves HCI layer problems, that can be resolved only with chip vendor support. Bluetooth chip will be programmed for the host commands before we start operating it.

Hardware can be designed in two ways( please see figure 1). One of the approaches is to have a different HOST and Bluetooth controller. The other approach is to have both HOST and Bluetooth Controller in a single SOC. In this, the application will be dumped in HOST CPU that would control the Bluetooth chip. The choice of approach depends upon functionality requirement, memory, processing speed and pricing.


Figure 1 Bluetooth Architecture Diagram

Next, we need to select an Operating system(OS) for our system, which could either be an RTOS or Linux based OS. Both are feasible and have already been implemented in commercial products. Since, in Bluetooth we want multiple profile and services to work simultaneously, it’s very important to have an excellent OS threading and scheduling mechanism, in order to avoid multi-tasking issues on application layer. Some of the important pre-requisites of successfully porting OS to SOC are prior knowledge of OS concepts, kernel and device driver.

Now, we want a Bluetooth stack which needs to be ported on OS. We can either develop this on our own or use one of the open source stack. In order to save time, we can opt for an open-source stack to fast track our development. Open source stack usually provides various profiles for Bluetooth classics and essential service for BLE, but we need to explore options to actually make it work with our environment. We need to dedicate time and effort to browse through the vast galore of Bluetooth SIG documents, profiles and services specification documents. Experience on protocol development can easily help one understand data packets, parsing techniques and subsequently implementing them for decision making.This would help one to skip unwanted open source codes. Making open-source stack to work with embedded device involves resolving issues related to multitasking profiles, eliminating Linux dependency according to OS and efficiently managing power on-off sequence of Bluetooth chips. Everything else requires a call-back base code understanding and socket base programming knowledge.

The below figure ( Figure 2) highlights the lower layer of Bluetooth architecture. In firmware, HCI layer isolates Controller from the Bluetooth chip. Only the HCI commands sent by Controller over Physical BUS can direct the operations of Bluetooth hardware. In response, there will be HCI event or error codes to Controller. In the event of error codes at HCI layer, it would be advisable to contact the concerned Bluetooth SOC vendor.



Figure 2 Lower layer of Bluetooth

Ideally the power on sequence provided by the SOC vendor should work in the first few attempts failing which we might have to focus our attention towards the data sheet for better understanding of chip configuration and sequence. This may be time consuming if the SOC is a new entrant in the market.

In the event of a power-on, series of HCI commands and events will be shared in between Host and Controller to get configurable information about Bluetooth chip. For BLE, transmission power and advertisement default properties will be set using HCI command. For Bluetooth classic, we need to create database having information about our services that are implemented and device information. Hence, while initiating connection, database information, can be used for capability sharing. Accordingly initiator/responder can accept /reject connection. This is addressed as Service Discover Protocol (SDP).

Security is a major concern for the entire IoT sector including Bluetooth. To deal with this issue, there are different authentication mechanisms that depend on the capabilities of initiator and responder. Security Manager Protocol (SMP) monitors the authentication and Man in the middle (MITM) attacks during and after connection. Probably, I will write about this in my upcoming blogs.

In Figure 1, profiles like HFP, A2DP, and ICP etc. can be implemented for Bluetooth classic. Most profiles need a RFCOMM socket. This is similar to any server-client socket programming, enabling a server for a specific profile and keep it in listening mode. On an incoming request from client end for that specific profile, accept it and create channel. The mechanism varies for different profiles.

BLE needs an L2CAP channel for the BLE central device to get connected with the peripheral device. GAP, ATT and GATT, will help in profile addition, packet formation, transmission and advertisement.

Usually BLE development kits vendors provide source-code stack of transport and above layer. Application developers will only be having the list of GAP/GATT APIs to read-write advertisement packets and display the same in central device UI. This can possibly limit the product functionality as per customized requirement. If development-kit vendor is not ready, we could possibly tweak changes especially for customized products. A better approach would be to have an open source or self developed stack, which can enhance the performance, as the stack is developed keeping the specific end product in mind.

Blog Credit:

This blog has been written by Mr. Harish Kumar Singh, Hardware and Software Engineer, Technosphere.

About Technosphere:

Technosphere, provides end to end engineering services and IOT solutions. It helps clients design IoT Devices, Solutions with multiple sensors, embedded firmware, hardware and communication capabilities to connect to the cloud.

As a Bluetooth SIG Member, Technosphere can help you build products using Bluetooth technology, thus empowering you to shape the future of IOT technology.

Contact us now for all your Bluetooth technology related requirements.

Have Any Questions?

Connect with us now, for all your IOT Solutions and Engineering Services Requirements

Back to Top