Common issues with developing Bluetooth Wearables (BLE)

By Sabih Siddiqui

Bluetooth Low Energy (BLE) is a low-power wireless technology for short-range communication between smart devices. Introduced in 2011 as Bluetooth 4.0, it enables smartphones or devices running on iOS, Windows, and Android to connect to up to seven devices simultaneously. However, manufacturers have the final say on the number of connected devices, which most makers recommend being limited to no more than four.

The Bluetooth Low Energy (BLE) standard is designed to consume much less power than its predecessor. It enables apps to communicate with devices without guzzling power, such as sensors, heart rate monitors, and fitness trackers. It stays in sleep mode until a connection is established. Although this isn’t ideal for phone calls, it is critical for applications that need to exchange small amounts of data regularly. This standard is also preferable for quick data transfer as transfer speeds can reach 1 Mb/s. Currently, it is one of the most widely utilized wireless technologies.

Key terms and ideas

Here’s a glossary of crucial BLE terms and concepts:
  • Profile of Generic Attributes (GATT)

    The GATT profile is a generic protocol for delivering and receiving short chunks of data known as “attributes” via a Bluetooth Low Energy (BLE) channel. GATT is the foundation of all existing BLE application profiles.
  • Profiles

    Several Bluetooth SIG profiles define Bluetooth Low Energy devices. Per its profile, a device should behave in a certain way in each application. A device may support various profiles. For instance, a gadget may have a heart rate monitor, battery level indicator, or both.
  • Attributes protocol (ATT)

    The Bluetooth Low Energy (BLE) protocol stack comprises the Attribute Protocol (ATT). It specifies how data is represented in a BLE server database and the techniques for reading and writing it. A fitness tracker, for example, collects information about your steps and heart rate. It functions as a server, storing this information until a client, for example, a smartphone, requests it. This information is saved as attributes on the BLE server.
  • Characteristic

    Characteristics are always components of a service and represent data and information that a Server wishes to make available to a client. For example, clients can read the battery’s remaining power in a device by reading the Battery Level Characteristic.
  • Descriptor

    Descriptors are qualities that describe a characteristic value. Among descriptors, one might find a human-readable description, a range of acceptable values, or a unit of measure specific to a value.
  • Service

    A service has sever al characteristics. You may, for instance, offer a service titled “Heart Rate Monitor” that contains features like “heart rate measurement.”

Issues with Bluetooth Low Energy

According to the recent Bluetooth Low Energy 5 release, SIG considers that BLE 4.x has two significant disadvantages:
  • Too limited range

    Unlike cellular and Wi-Fi devices, users cannot utilize them for long-distance wireless communications. It has a range of up to 200 meters in LOS (Line of Sight)
  • The speed is too slow

    Because of wireless transmission/reception vulnerability to interception and attack, its speed is plodding.
However, some people disagree. Almost no other publication (or speaker) emphasizes the importance of these difficulties for BLE. Instead, other issues are raised. Based on the expertise working with hardware vendors to design software and firmware, here are a few critical difficulties with BLE:

Bluetooth Safety

While Bluetooth Core Specification 4.2 provides adequate security across multiple layers, the issue stems from the other side: proper implementation. Device manufacturers do not appear to take security features seriously enough. Many wearable technology firms are eager to get their goods to market as soon as possible, with security sometimes thrown on as an afterthought. It is critical to emphasize this problem. If the initial connection and pairing are sniffed, Bluetooth v4.0 and v4.1 devices are unsafe (Bluetooth v4.2 is much more secure). Both devices must support LE Secure Connections to maintain security. Otherwise, it will be easy to determine who manufactured a specific BLE device. What’s the significance of this aspect? Here are a few pointers:
  • Case 1: Determine who is who

    A well-known method for determining which BLE devices are nearby is by using a “sniffer.” It is simple to link a gadget to a specific individual, such as a celebrity, CEO, or police officer leading an inquiry into your organization. It is frequently utilized in wearable devices. Many wearable devices contain personal information about a person’s health and living patterns. Privacy may be the most critical aspect for wearable BLE modules to maintain.
  • Case 2: Concerns about mobile payments

    Customers can use BLE to make payments. NFC remains more popular than BLE, the favored technology for in-store mobile payment transactions. It is because, for a BLE, the source is far away . NFC works within five cm of each other, but BLE sends signals across much greater distances. Malicious agents could potentially intercept BLE signals.
  • Case 3: General hacking

    Excellent practical research demonstrates clearly how malicious actors may intercept BLE traffic. They can reconstruct intercepted packets into connection streams. An attack against the key exchange mechanism is feasible, rendering the encryption worthless against passive eavesdroppers. Further, a sniffer may also follow connections created during the sniffing time.

Mesh interaction

Every day, the number of gadgets interacting with one another grows. That is why it is critical to be able to work in a mesh network. BLE is typically used for point-to-point and point-to-multipoint communication. However, no clear information is provided about how many BLE nodes might be in a network with a mesh architecture without substantial downtime and battery drain. Because the theoretical limit is roughly 500 nodes, the hope is that a single BLE node can “speak” to several hundred nodes simultaneously.

Bluetooth LE devices are designed for lightning-fast connection, the transmission of short bursts of tiny packets of data, and disconnection. As more links occur in a mesh network, it will result in a longer setup time due to faster battery depletion. However, ZigBee was explicitly created for Smart Home technology, which uses a mesh topology. Lower energy consumption is feasible for ZigBee Smart Energy devices, but there is still no clarity on what current or voltage these chips consume.

BLE Cost Beacons are a relatively new concept that is still not inexpensive. The cost of BLE chips and beacons ranges from $1 to $8 (based on alibaba.com search information). This price is comparable to the ZigBee chip and module range. However, NFC and RFID tags are significantly less expensive. Individual tags are in the price range of $0.10 to $0.60, depending on the specifications. Perhaps comparing NFC tags to BLE beacons is a little off. However, it should be affordable if someone wants to use BLE for mobile payments. Because of the cost and interoperability of financial transactions, NFC has an advantage over BLE in busy establishments, where a customer has never visited, large retailers, or perhaps, public transportation. Compared to NFC, the investments required for BLE payment transactions are now higher.

What needs to be done?

These are crucial factors to consider if you’re developing a BLE-enabled app.

Improve the onboarding experience

It’s possible that your Bluetooth device needs some further configuration before it can function. Drawings, images, and videos are essential materials to include in the onboarding process, particularly if you want the user to press a button, scan a code, or attach your gadget in a specific manner. Images and videos can save you time that would otherwise be spent on copywriting and translations. Users profit from this since they can see what they need to do. It also demonstrates that you are serious about your product and willing to go the extra mile to provide the most satisfactory experience possible.

Request permission

Another crucial point to consider while developing a BLE mobile app is permissions. BLE apps require approval for Bluetooth and, in some cases, location services to function effectively.

So, what are your options?

Consider the content that the user reads: remember to explain why you’re requesting permission and how they will affect the user experience so that users can make informed decisions. Keep things brief to improve reading.

Consider when to ask for permission : if you don’t want to make a wrong first impression, don’t bombard the user with requests immediately. Instead, spread it out during the onboarding period or show it the first time you use the feature. It is critical to ensure that it makes sense to the user and is justified.

Support follow-up dialogs:inform users of their missing benefits if they decline one of your necessary permissions. It could also be a mistake, in which case the user should be able to correct it.

Make it easier to recognize a gadget

Bluetooth devices utilize lengthy unique IDs that are difficult to remember. Make someone’s life easier by masking some complexity if they must deal with many gadgets. Buttons, signal range, QR codes – numerous cues can assist in determining the correct device. Furthermore, in the case of many devices, allow users to modify their names or icons to make them more familiar.

Test the app with users on several devices

Although QA testing of any app is recommended, real-world scenarios can yield eye-opening information. You might see something new when you put your clients in front of the app and the device. It’s an invaluable tool for testing assumptions, identifying roadblocks, and identifying potential improvements.
Bluetooth Wearable

About the Author

CTO and Chief Architect

Sabih is a proven technical leader who joined the TechBlocks family in 2009. He enables his team to be top performers in their field to deliver increased value to our clients through internal client alignment, strategic vision, cost control and outside the box thinking leading to powerful solutions to meet the growing needs of our clients and their customers. Sabih is known for building strong relationships with our clients and is actively involved in new business activity. He is one reason why our Fortune 500 clients continue to leverage TechBlocks’ institutional skill and knowledge for new and recurring projects.

Need Help With Your Project?

TechBlocks helps Digital Health trailblazers with their wearable engineering through companion app development, firmware engineering, and quality assurance projects.