In-Depth Explanation of Low Power Bluetooth Chips and IoT Application Development

Good evening, everyone! I am very glad to have the opportunity to share this session with you. I am Cai Bingquan, the Embedded Department Manager at Jieli Technology, currently responsible for the research and promotion of Bluetooth RF technology. Today’s content will mainly cover the following four parts:

1. Evolution of Bluetooth technology

2. Key performance requirements and implementation challenges of low power Bluetooth chips

3. Detailed explanation of the AC630N low power Bluetooth chip characteristics

4. IoT application development practices based on AC630N

True low power Bluetooth was born from version 4.0. Below is an introduction to classic Bluetooth, which has performed very well in Bluetooth audio products. The Bluetooth headphones and speakers you see on the market are successful applications of classic Bluetooth. The reason Bluetooth versions continue to be updated is mainly to meet more application scenarios. Compared to other 2.4G technologies, Bluetooth continuously improves to compensate for its application shortcomings, gradually becoming a unifier of wireless protocols, which you can learn more about through its logo and name origin. (Editor’s Note: https://www.logonews.cn/bluetooth-brand-story.html)

Next, let’s take a look at the current state of Bluetooth. Bluetooth 4.0-4.1/2 mainly aims to build and improve a suitable low power Internet application. Here, I would like to mention the application of mesh, which has unified and standardized various proprietary meshes customized by manufacturers on the market. In the era of the Internet of Things, the first problem to solve is the standardization of communication protocols. It’s not that the concept didn’t exist before the birth of mesh, but it further improved and standardized communication protocols.

Then, the Bluetooth 5.0 version, in my opinion, gives low power Bluetooth scalability. We know that throughput and distance are actually on opposite ends. Such designs allow Bluetooth products to cover more scenarios. For example, short distances but with high throughput, or long distances but with reduced throughput, thus meeting different developer needs. The later 5.1 version adds a more precise positioning function under the premise of the aforementioned IoT layout. It’s not that previous versions couldn’t achieve positioning, but rather an improvement in precision. Many traditional manufacturers use 4.0, 4.1/2 for positioning, then combine signal strength methods with algorithms to achieve positioning, thus mainly improving accuracy here. The 5.2 version further standardized and expanded a previously phenomenal TVS Bluetooth headset, breaking the limitation that Bluetooth audio is only between one or two headsets, allowing it to share among more devices.

Next, let’s look at how the first low power Bluetooth expansion is achieved. From the above diagram, we can see that it underwent an update from top to bottom, including hardware updates. This means that classic Bluetooth and low power Bluetooth actually belong to two different modes of Bluetooth, independent of each other and cannot connect with each other.

Through the above figure, we can see a comparison of the advantages and disadvantages of low power Bluetooth versus traditional Bluetooth. From data characteristics, connection speed, connection quantity, transmission rate, security encryption level, etc., we can see some differences. Compared to classic Bluetooth, low power Bluetooth is more suitable for applications with lower data volumes, and connection speed has been improved, breaking the connection number limit; however, the rate has decreased, and the effective length of data packets has also shrunk; yet security levels are higher, using 128 Bit AES encryption; in terms of profiles, they are still compatible.

Because Bluetooth has two different modes, the concepts of Bluetooth smart ready and Bluetooth smart were born. For example, traditional Bluetooth audio headsets, Bluetooth headsets used in cars, Bluetooth printers, etc., Bluetooth video is rarely seen, but classic Bluetooth can also transmit video. In between are dual-mode Bluetooth devices that are compatible with both Bluetooth modes. Thanks to the support of laptops and mobile phones for Bluetooth updates, this is also an unmatched advantage that Bluetooth has over other 2.4G protocols, gaining ecosystem-level support. You will find that commonly used electronic products have Bluetooth versions above 4.0, which means they are basically smart ready devices that can connect simultaneously with traditional Bluetooth audio. For low power Bluetooth application scenarios, it mainly targets scenarios with fewer transmissions and more sensitive power consumption. Some devices are repeatedly used, such as mice, keyboards, and printers, where using Bluetooth smart would be more appropriate.

Next is Bluetooth 4.1, where I selected several important updates. The first is privacy 1.1, which mainly extends Bluetooth addresses, making devices harder to track. This improves the rigid demand on the Internet, namely how to enhance user privacy and security levels. This will become particularly important in the era of the Internet of Things.

Another is the introduction of mesh, which breaks through the previous point-to-point connection and broadcast communication behaviors, making mesh communication possible. Bluetooth mesh is suitable for low power Bluetooth, which is version 4.0 and above. As mesh uses a flood-based message transmission mechanism, it is a simple yet reliable network. Although its efficiency is not the highest, from a technical positioning perspective, it meets the requirements.

Next, let’s look at an application scenario paired with cloud servers, where Bluetooth is used in edge computing applications. The left side shows endpoint devices, such as switches, humidity sensors, temperature sensors, infrared, etc.; these pieces of information are gathered through mesh and then reported to the cloud simultaneously through mobile phones or other proxy nodes, forming a network.

Bluetooth 5.0, as a major version update, mainly consists of the following updates: 2x speed, 4x distance, 8x throughput, and network coexistence, i.e., improved coexistence capabilities within the 2.4G frequency band.

First, let’s look at the updates related to speed and distance from its air packet format. By using the 2M PHY data format, the transmission speed within the same time is double that of the past; from a long-distance perspective, by sacrificing symbol rate as a premise to improve receiving sensitivity (it is important to distinguish here that symbol rate and data rate are two different concepts; developers care about data rate, which is the bit rate; it refers to how many symbols in the air represent one data, called symbol rate), it can improve link budget, theoretically allowing transmission distances to reach four times that of the past.

Next, let’s look at another special update: new broadcasting behavior. It derives new broadcast packets based on traditional broadcasting, expanding not only the packet types but also the traditional channels. It uses not only traditional broadcast channels but also to avoid channel congestion, using 37 data channels (previous broadcasts only used channels 37/38/39). Additionally, new frequency hopping features have been introduced, optimizing network coexistence from the perspective of wireless time and frequency. Comparing the two channel selection algorithms of Bluetooth, we can see that its inputs have increased, leading to better complexity and more difficult-to-track frequency point algorithms, mainly to avoid mutual interference and multipath fading effects.

Bluetooth 5.1’s main updates focus on: positioning services, adding antenna arrays and fixed frequency expansion outputs without whitening processing.

Let’s look at an angle of arrival (AoA) scenario. Through antenna arrays and fixed frequency output, the baseband has the capability to calculate the angle at which each signal arrives at the antenna. The above image shows its two receiving devices, calculating from the arriving devices through different algorithms, such as triangulation or other methods to determine the target’s position. Its computational ability is concentrated on the receiving device with a fixed layout, not on the asset side, suitable for tracking simple devices where the receiving device knows its own position, while the device itself has no capability to know its own position.

Another method is the angle of departure (AoD) method. Compared to the AoA method, AoD calculates its position by receiving signals from different antennas through the mobile device. Here, the asset is replaced by a mobile phone, and the computational ability is still mainly concentrated on the receiving end, which is the mobile device. This is a significant difference between the two methods, as well as a difference in computational distribution.

The first performance indicator that low power Bluetooth needs to pay attention to is power consumption. Power consumption is mainly divided into dynamic power consumption and static power consumption. Dynamic power consumption includes the instantaneous power consumption during Bluetooth transmission/reception and the active power consumption of the system/SoC chip. Static power consumption refers to low power consumption when the system is idle, which can be further divided into several static power consumption states such as Bluetooth transceiver state switching, system sleep, etc.

Another important performance indicator is speed. Speed includes two points: connection speed and response speed, and the related parameter is the connection interval. The choice of transmission PHY and the size of the transmission packet will affect the data throughput.

The reliability of data depends on whether to use broadcast or connection forms to determine if there is an acknowledgment mechanism and whether effective transmission is carried out.

Additionally, regarding the encryption mechanism, Bluetooth encryption has two modes, each with four levels of settings.

Next, I will focus on two important parameters that will affect performance indicators and user experience. The first is the connection interval. The top part of the above image shows the connection interval segments. What impact does it have on performance? If the connection interval is lower, it indicates that the communication interval is smaller, which will increase the power consumption of the host and slave; as the number of communication opportunities increases, data throughput will also rise; while the data delay between the master and slave will decrease. Conversely, if the communication interval widens, indicating infrequent communication, we can see that the power consumption of both the master and slave will significantly decrease; simultaneously, data throughput will decline; and the data delay between the master and slave will increase, which are all undesirable outcomes.

Is there a way to achieve low power consumption while maintaining data throughput and delay? This introduces the second key parameter, called latency value.

First, let’s look at the two extreme cases of slave latency value. When the slave latency value is very small or close to zero, it means communication occurs at every interval. In this case, compared to when the slave latency value is high, the power consumption of the slave will increase due to increased communication intervals; however, the slave latency value does not affect the other three (master power consumption, throughput, and slave data delay) because it only applies to the slave; the master-slave data delay will decrease. If the slave latency value is high, the power consumption of the slave will decrease, but the master power consumption, throughput, and data delay will remain unchanged, while the master-slave data delay will increase.

If the master’s latency follows the same trend as the previous example, we can see that the data delay between the combinations will also decrease. When the slave latency increases, we hope to sacrifice the organization to achieve the best results in power consumption, delay, and throughput. We can also see that due to the effect of communication intervals, the communication interval relatively worsens, but the master’s guidance remains unchanged, resulting in reduced power consumption. This is what we hope to achieve, sacrificing the master while maintaining the slave in a balanced performance state.

The design of latency is mainly aimed at saving power consumption of slave devices, such as common Bluetooth remote controls, mice, and keyboards. It can maintain response speed while ensuring device power consumption. Let’s take a look at the power consumption breakdown of low power Bluetooth in broadcast state. The above image is an example of a broadcast packet with a 500-millisecond interval, where broadcast packets are present on three communication channels. The two key factors are communication time and current, represented by current to indicate power consumption.

The power consumption of a broadcast packet within a cycle can be estimated. How is it estimated? It can be divided into multiple regions. The first region is the sending state of the slave device; the second is the time interval, mainly for switching purposes; the following is the receiving window, where a scan request packet may be received; then there are two states for Bluetooth transmit/receive switching back to a baseband idle state; and the red area here represents the system sleep state; the very front red area is the Bluetooth preparation time.

Now let’s look at an example of connection packets with a 100-millisecond interval, where the key parameters are still time and current. We can see that its state switching is somewhat different; once the master-slave connection is established, communication becomes simpler, experiencing stages of sending, switching, receiving, and idle.

Taking the earlier example of a broadcast packet with a 500-millisecond interval, let’s assume the transmission power is 8 mA, reception power is 6 mA, system idle is 3 mA, system sleep is 0.03 mA, and payload is 0 Byte. Plugging into the formula, the estimated power consumption corresponds to a current of 69 microamps. Another example is connection power consumption, taking a connection interval of 100 milliseconds and latency of 0; its power consumption will be 93 microamps. If latency is used and set to 99, power consumption will drop to 36 microamps.

As mentioned regarding the latency feature, there will be a significant improvement in power consumption for low power Bluetooth. The challenges in implementation mainly involve designing chips to minimize the time of high power operations, such as transmission, reception, switching, etc.; another is operating power consumption. Any reduction in factors within a formula will help improve power consumption, but the main impacts are still the listed items, and the longer the sleep time, the lower the power consumption will be.

Now, let’s look at the AC63 series after understanding the characteristics of Bluetooth and some performance indicators and implementation challenges, which have achieved which Bluetooth features and overcome which implementation challenges.

The AC63 series is an ultra-low power Bluetooth dual-mode SoC system-level chip that has passed Bluetooth SIG 5.0 certification. In terms of power consumption performance, it features an ultra-low power management system that supports built-in LDO and DCDC; at the same time, it supports the Bluetooth SIG mesh feature in applications and connects to Tmall Genie, with more third-party connections to be added later. The main application scenarios are as follows; we provide complete application solutions to minimize customers’ secondary development.

The above image shows the specifications and box diagram of AC63. It supports an internal flash structure, a 32-bit RISC-based CPU, and also supports AES encryption.

This is an introduction to the chip resources: on the left side, the upper limit frequency of the 32-bit CPU is 120 MHz, 56k data RAM, 8k I-Cache, built-in flash supports different capacities of 256k and 512k, supports all external I/O wake-up (a very important feature for low power applications), 2 full-speed USB, bus and rotary encoder, IRTC clock and alarm; on the right side are Bluetooth specifications: supports 1M/2M and Coded PHY (suitable for high throughput and long-distance layouts), supports standard profiles, (taking a broadcast packet with a 500-millisecond interval as an example) standby power consumption is about 70 microamps, sleep power consumption is 30 microamps, standby power consumption is 2 microamps, supports internal DC/DC, supports temperature from -40℃ to 125℃ (with different specifications), and operating voltage from 1.8V to 5.5V (with different specifications).

The above image shows different models of the 63 series and the differences between models. The differences mainly reflect the flash capacity, whether DC/DC is built-in, charging, operating voltage, and operating temperature. The naming rules reflect these differences. The 63 series has two specifications, allowing selection of the most suitable model based on application needs.

In addition to the traditional SDK release method, AC63 also supports synchronous online release and has a dedicated GitHub repository. First, let’s understand the introduction of the SDK.

First is the setup of the development environment. Since the chips are independently developed, including independently developed CPU, instruction set, and compiler, it is necessary to independently install a compilation tool before starting application development; additionally, there is a development upgrade tool, primarily for burning the corresponding hex files for debugging during the early stages of development.

Then, there are some introduction documents, mainly introducing chip specifications and SDK information that everyone is concerned about before development, including SoC data sheets, SDK historical versions, and SDK quick start introductions. At the same time, complete application solutions are provided, and more application solutions will be continuously released to reduce customers’ secondary development time.

The compilation environment supports both Codeblock IDE and make file compilation environments, and before compiling, different methods must be chosen to start applications based on the compilation environment. If selecting Codeblock IDE, you need to enter the corresponding project directory to open the project file; if it is a make file compilation environment, some macro variables need to be manually modified; it is important to ensure that the toolchain and upgrade tool are in a normal connection state and enter programming mode before downloading the program.

We are working on deep learning-based semantic navigation, combining image recognition with depth cameras, recognizing a person in an image, and knowing the person’s position on the depth map. When I draw on this, I know it is a person; when it is a static obstacle, I know it is a box.

As you can see, the SDK has an operating system and is structured based on events. The abstraction of events and APP helps decouple applications, allowing users to focus on developing application logic without worrying too much about hardware details. Below are some examples of the SDK, supporting classic Bluetooth SPP transparent transmission, LE transparent transmission, and as a module command application. Another is a dual-mode HID device; these are the project files.

This is a simple structure introduction of the mouse SDK. You can see that the main development focuses on business logic, how to trigger events, how to obtain different states, such as mouse buttons, rotary encoders, optical sensors, and Bluetooth device events, which are then processed by the system APP and sent.

You can see that applications can run on different chip platforms; this is an introduction to Bluetooth mesh. The mesh features already support relay, proxy, friend, and low power, supporting provisioning bearer support (PB-GATT and PB-ADV) and provisioning role support (unprovisioned device). It also connects to third-party Tmall Genie.

Also, I would like to introduce our upcoming Bluetooth applications in IoT/Beacon/Multi-link/vendor wireless.

Today’s presentation ends here. Thank you all!