Apart from what we require before starting a project, there are certain tips that make everything move faster once development commences. Over the years, we’ve seen a number of major problems come up time and time again. But we’ve also learned that they can absolutely be avoided. Our list of things to keep in mind describes the pitfalls we’ve encountered on past projects and provides advice on what not to forget while developing a hardware device designed to communicate with a mobile phone via Bluetooth.
Before Starting Development, Engineers Should Be Provided With:
- Thorough documentation of device internal setup, inner states, its components and communication protocols.
- A list of services and characteristics provided by the device, their capabilities (Read/Write/Notify), data types including size and UUIDs.
- Testing devices — the more, the merrier. Ideally, these should be in their final version, but we need at least something to start with. The minimum required number of devices is one per developer.
- Anything special we should know about.
What To Keep In Mind During Development
FW Update Option
It should be possible to update the FW in all devices via the app. There are many ways to achieve this, all of which always depend on internal implementation of the device. Please keep in mind that this should be as easy as possible from the app’s point of view. We highly recommend implementing this feature in the FW in a way in which the app only downloads the FW files from secure API and then copies it to the device using the BLE protocol. You can use a checksum file for corrupted files validation that can be copied along with the FW file itself.
It’s very helpful to provide a characteristic for the update progress reporting as well, so that the user can be informed of the update status. This is one of the most common problems we’ve experienced and it should be one of the first features working on the device, right after the connectivity functionality. If the FW update works, we can ship the apps with this feature implemented and a device developer can provide end users with enhanced functionality at any time.
Connectivity
Please keep in mind that there are different connection scenarios for BLE devices. Just a few examples are:
- Your device may need to be paired with a phone before the actual communication starts;
- Some devices require the user to enter a PIN;
- Some devices connect out of the box;
- In a few special cases, you might need to implement an extra security layer — including various network API calls — in order to verify that the valid device is really being connected.
We need to know exactly which case applies to you, so that we can tailor the connection experience to perfectly suit your needs.
While designing the connectivity stack, please note that there are some differences between the iOS and the Android systems’ connectivity stack (like different communication speed, security implementation, pairing dialog triggering, etc.). Please try to make sure that all of this is considered. You should always check the official OS documentation in order to pinpoint various edge cases and possible problems along the way, and then try to design the HW to be as flexible as possible to connect seamlessly in any scenario for which it is designed.
As a part of our project onboarding process, we always try to make sure that the device can connect to both Android and iOS phones before we start writing code. Connectivity problems are especially hard to solve during the later phases of the development. While testing your device during development, you can use the nRF Connect application. (Google Play link here and Apple App Store link here). This app has many features and is very well tested with various phones, as well as with different types of HW. If this app struggles with connecting to your device, it will probably have problems with your app as well.
BLE Service Changed Characteristic Implementation
It’s very important to make sure that the Service Changed characteristic (0x2A05) is implemented correctly. Since the specification of the services can change very often during development, it’s very important to be able to let the mobile phone know of these changes so it can clear the cache and reset the stored list of characteristics it can interact with. (See how to use service change characteristics here and how to indicate BLE 'Service Changed' [0x2A05] here.)
Connection Stability
When testing the device connectivity, we highly recommend verifying that the connection to the device is stable within the estimated range from the device. You can test this behavior with one of the previously mentioned apps to make sure that the device will maintain the connection even when the user moves away from the device (if this is what you need).
You should also consider providing a test housing of the board. After being put into the case, BLE devices quite often start functioning differently, either because the material of the case is shielding the signal or because the case is poorly designed and is causing the device to overheat.
BLE Chip Selection
If you’re in the initial phase of development and are looking for which chip to use in your device, we recommend using a Nordic Semiconductor product (nordicsemi.com). They have a very good support team, many developer forums where people (very often directly from their team) help you solve various problems, great testing tools, and their products also support the latest technologies — such as NFC — that can come in handy.
BLE Beacons
This is a very nice feature to consider ideally in the early stages of development. If your use case can leverage this feature, you can implement a BLE beacon stack on your device. Even if not used in the early stages or in the MVP, this can be useful later on and is a great thing to already have solved. Beacon behavior can, for example, notify the user that he/she is close to his/her device, show the appropriate pop-up notification and automatically connect, recommend market products to the user and much more. The initial effort is absolutely worth it in most cases. (You can find out more about beacons here.)
Number of Simultaneous Connections
When designing your product, bear in mind that there is a limit of possible simultaneous connections at any given moment. Even though BLE specifications claim that BLE currently supports up to 20 parallel connections, from our experience, the real limit varies based on the type of HW used (both on a phone and your device; some legacy phones can support only two devices connected simultaneously, which can play a major part in your product design process and its caveats). The claim of supporting 20 parallel connections assumes an ideal environment without any interference, which is hardly achievable in normal conditions. HW developers should always consider all scenarios. STRV can provide the needs for testing, and we can even help with the initial connectivity tests in order to achieve the best possible project kick-off.
Anything to Add?
This was a quick overview of recommendations we’ve accumulated throughout our years of experience. Still, it doesn’t mean we’re not missing anything. Do you have any other tips you swear by? Please, let us know! Reach out or comment, and happy Bluetoothing!
