Smart Water Bottle BLE Integration

In this blog post, we examine how a smart water bottle communicates with a mobile application using the Bluetooth Low Energy (BLE) communication protocol. The customer’s concept is designed to motivate users to maintain a healthy lifestyle by regularly consuming water and monitoring their hydration habits.

A comprehensive functional overview of the entire solution is available here.  

This post focuses on the technicalities of the BLE communication protocol as it facilitates interaction between the mobile app and the smart water bottle. We invite you to join us in this exploration, regardless of your technical expertise, as we aim to simplify complex concepts for easy understanding. 

Introduction to Bluetooth Low Energy

Bluetooth Low Energy is specifically designed to transmit small data volumes while consuming minimal energy. The adoption of the BLE communication protocol was motivated by the necessity for extended device operation times without the need for regular charging, coupled with a requirement for ongoing data exchange. This protocol is particularly well-suited for scenarios that demand frequent short-range data transmissions. In the scope of our project, BLE facilitates the bottle’s capability to consistently relay vital information to a mobile application, including metrics on water consumption, battery level, temperature, and other key parameters. A significant benefit of BLE is its low energy usage, which is essential for portable devices such as our water bottle, ensuring substantial operational longevity without frequent recharges. The subsequent sections will delve deeper into the technical intricacies of the BLE communication protocol and its application in our project. 

BLE General Data Protocol: Formats and Commands

The BLE communication protocol is fundamentally grounded in structured data exchange, defined by a specific frame format. In our project, each data frame comprises several essential elements: 

SYNC: The initial byte of each frame, indicating the start of data transmission. 

LEN: Determines the frame’s total length, encompassing ID, type, and the data. 

ID: A unique identifier for the frame, distinguishing one message from another. 

TYPE: Specifies the frame’s purpose, defining the operation type within communication. 

DATA: The actual information transmitted between devices. 

CSUM: A checksum used to verify the integrity of the transmitted data. 

This structured approach ensures accurate and error-free data exchange between the mobile app and the bottle, crucial for the system’s reliability and efficiency. Let’s explore a data frame example in BLE communication, clarifying each component. Imagine a mobile device sending a request for temperature data from the bottle’s Inertial Measurement Unit (IMU). 

Example of a Data Frame:

This frame example demonstrates how a mobile device can request temperature data from the bottle’s IMU. The frame’s structure and values provide clear, precise communication, essential for the system’s correct functioning. 

A central component in communication is the Opcode (Operation Code), which defines the specific command or request being sent. In the data frame structure example given earlier, the Opcode is designated by the TYPE key’s value (`0x50`). This Opcode indicates that the mobile device is requesting temperature data from the smart bottle. Upon receiving this request, the bottle understands it needs to measure the temperature and relay this data back to the mobile device. For most requests made by the app, there is a corresponding response from the bottle that includes relevant data or the execution status of the command. For instance, in response to a temperature data request from the mobile app, identified by Opcode `0x50`, the bottle might return a data frame with an Opcode, such as `0x51`, indicating it’s a temperature response. Thus, the Opcode pairing of `0x50` and `0x51` is employed for the exchange of temperature measurement data via the IMU sensor in the BLE communication protocol of our project. 
Each Opcode is crafted to perform a distinct function, forming an integral part of the smart bottle’s overall management system. The majority of Opcodes exist in pairs, typically as “Request Phone->Bottle / Response Bottle->Phone.” In our project, Opcodes facilitate a variety of tasks, including time synchronization for data accuracy, water level monitoring for tracking user consumption, syncing offline cache, setting hydration reminders, activating night mode, indicating low power, managing LED controls, and executing Full Bottled Water Calibration Request, among others. 

Establishing BLE Connection

A foremost task in any Bluetooth Low Energy (BLE) system development is the implementation of the BLE communication protocol within the code. This holds true whether it’s for wearable device firmware or software for mobile and desktop devices that enable device-app interaction. Our solution is no exception. Let’s examine the key states and operations that establish BLE communication between devices. 

Advertising Mode: This mode allows the bottle to broadcast signals that include essential connection information, like its unique name and the last four characters of its MAC address, facilitating easier identification in the app. The broadcasted data informs about the bottle’s current connection status, indicating whether it is paired with the app or awaiting connection. Normally, the bottle broadcasts these signals every second at 0 decibels milliwatts (the standard signal strength emitted by BLE devices typically ranges from -20 dBm to +10 dBm), balancing signal range and energy efficiency as per BLE standards. In case of connection loss or USB connection, the bottle automatically activates Advertising mode to re-establish the link. During night mode, to avoid disturbances, broadcasting lasts a minute before turning off. If connected to an auto-reconnecting app, the bottle will resume the connection post USB use. Activating night Advertising simply requires opening and closing the lid or using a USB cable, ensuring round-the-clock control. 

First Connection and Bond Request: The diagram illustrates this process, which is a critical stage in pairing a smart bottle with a mobile phone. The bottle is in a constant state of advertising (ADV), making itself discoverable to nearby devices. When a user wants to connect their mobile phone to the bottle, they start by opening the corresponding application on their phone and scanning for the bottle. Once the bottle is detected, the app initiates a connection.  After the initial connection, the user can send a bond request from the app. This request is a security measure that, once approved, allows the bottle to store bond information and respond accordingly, thereby establishing a secured connection. Once bonded, the bottle and the phone maintain this connection. This bonding ensures that the bottle and phone can communicate securely and exchange data as needed. The bottle can now respond to data requests sent from the phone.  

As an indicator of this successful connection, a blue LED on the bottle will remain statically on for 5 seconds. If the bottle and the app are not bonded, this LED signal prompts the user to perform the bonding process, ensuring that the bottle is ready to interact with the app and send bond requests if necessary. 

Reconnecting with the Correct Bonded Device: This process describes the steps for re-establishing a connection between a smart bottle and a mobile phone that have been previously paired. The smart bottle is always in advertising mode (Always ADV), making it visible and ready to connect. When a user wants to reconnect, they open the mobile application, which scans for and identifies the previously bonded bottle. Upon selecting the bottle, the phone sends a check for the bonded status. The bottle then verifies the bond information and responds. If the bond is confirmed, the connection is sustained, signifying that the bottle and phone are correctly paired and communication can proceed securely. After the bond is verified, the phone can send data requests to the bottle. Since the devices are already bonded, the BLE connection does not trigger the blue LED signal, which typically indicates an initial successful connection. The app is designed to send bond confirmation information along with the device ID to maintain the connection. This streamlined process ensures that once the smart bottle and app are bonded, reconnection is efficient, maintaining the bond without additional user input unless the bond information changes or a new device is introduced. 

Reconnecting with the Incorrect Device: This process outlines the protocol for when a smart bottle attempts to reconnect with a device that is not the correctly bonded mobile phone. In this scenario, the smart bottle remains in a continuous advertising state (Always ADV), signaling its availability for connection. When a user initiates a connection through the mobile app, the app scans for the bottle and tries to connect. The phone then sends a request to check if it is the device previously bonded with the bottle. The bottle checks the received bond information and responds. If the bond information does not match the bottle’s records—indicating it is not the correct bonded device—the bottle will not sustain the connection and will disconnect. The bottle is programmed to connect only with the correct, previously bonded phone. If the phone attempting to connect is not the one with the matching bond information, the bottle will automatically sever the connection. The app should send BOND confirmation information with the device ID if it is indeed the correct phone. If the bond information is incorrect, indicating a wrong device, the bottle will remain disconnected. This process ensures that the bottle only maintains connections with authorized devices, enhancing security and user experience by preventing unauthorized access. 

Unbonded Device: This process detailed in the diagram is a key procedure that facilitates the secure disconnection and removal of existing pairing information between a smart bottle and a mobile phone, ensuring that the bottle can be reset for a new connection. The bottle, always in an advertising mode (ADV), is visible for connection. When a user attempts to connect via the mobile app, the app scans and attempts to connect to the bottle. The phone sends a request to check if the bottle has any bonded information on file. If the bottle confirms that it is bonded, the connection is maintained. However, if the user wishes to disconnect or if the phone is no longer available—for instance, if it is lost—the app can send an unbond request to the bottle. Once the unbond request is received, the bottle will respond and proceed to remove the bond, effectively unpairing itself from the phone. In cases where the phone is lost and cannot send an unbond request, the bottle has the capability to initiate the unbond process on its own through a special sequence of actions. The user can plug in a USB cable, turn the cap upside down, tap twice on the lid, and wait for a purple LED flash. This sequence indicates that the bottle has successfully unbonded itself from the lost device. This feature ensures that the user can maintain control over their smart bottle’s connections and can securely manage device pairings, even when the original paired device is no longer accessible. 

All these processes are implemented both at the code level of the mobile application and at the firmware level of the smart bottle. This holds true for nearly any other interaction between the app and the smart device. Therefore, for low-level integrations of IoT devices and the implementation of custom functionality, the technical team must possess the requisite expertise in firmware development. We invite you to explore a dedicated blog post about this project, where we have thoroughly described our work on developing custom firmware for this smart device.

BLE Services and Debugging Protocols

In our commitment to maintaining product stability and quality, we have integrated a suite of debugging and manufacturing protocols. These protocols encompass a standardized format for debugging messages, streamlining the process of analyzing and addressing issues. Additionally, they include functionalities for testing the components of the bottle, ensuring each part operates as intended. To aid in diagnostics and staff training, we provide practical examples of request-and-response scenarios. 

Utilization of Bluetooth services is integral to our system. These services facilitate essential features such as delivering detailed device information, encompassing manufacturer details, model specifics, and both software and hardware versions. This comprehensive data aids the application in accurately identifying the bottle, thereby ensuring seamless compatibility across various device models. Moreover, our implementation of Battery and OTA (Over-The-Air) services offers robust options for battery charge monitoring and efficient, real-time firmware updates. 

Let’s collaborate

Are you seeking an experienced team of experts specializing in integrating smart connected devices through BLE protocol? That’s exactly who we are. With numerous successfully delivered IoT projects under our belt, we confidently tackle challenges of any complexity. Whether you come to us with a partially developed solution or need to start from scratch, we will see it through to a successful launch.

Contact us, and we will provide you with more detailed information about our experience and capabilities in developing comprehensive IoT solutions across various industries.