Guide for Product Owners deploying Bluetooth Products: BLE Debugging
Smartwatches, air pod, medical devices like HR monitor, fitness trackers, item locators and so-called wearables all commonly rely on Bluetooth technology for its communication. The products are ubiquitous and omnipresent and more IoT devices are today adopting the technology (protocol) into their products especially with the Bluetooth Low Energy (BLE) standard for low power consumption. As long your gateway device can connect to a cloud service to send and receive data the balance of power, size, price and form-function fit make Bluetooth an ideal choice for IoT solutions. The challenge for many of such products is constant connection to phone via a third party app written on the phone’s operating system makes it quite challenging to debug. Launching a new device that uses BLE or has one that you support? Read this guide for tools and strategy.
When it comes to debugging any hardware like your PC, as the saying goes: ‘Have you tried turning it OFF and ON again?’ is not really a solution to a device that is in the field and needs 24/7-connectivity. So what can you do?
While your IoT product maybe a small device at the hands of your user, there is a significant amount of work needed in order to ensure a seamless customer experience and support. If you have a BLE device in the market, you would be familiar with the issues. A typical customer support token on your CRM system may look like: ‘I purchased xyz, but the device is suddenly stopped working, etc…’ or while still in testing an alpha/ beta user reports an issue but there is no way of getting a console log, traces and/ or replication steps to actually reproduce the issue so root-cause analysis can be performed and appropriate support provided.
First and foremost you need a strategy for customer support as well for your development team to ensure the IoT product can be debugged and issues are both replicable and actionable. Based on our real world experience of working with BT IoT devices, we have put together the following tools and strategies to ensure your IoT solutions do not let either you or your users down.
System Debugging
Be aware that various factors impact the performance of a BLE system including wireless environment, tradeoffs in low power protocol design, radio loss and design should help later help isolate them from real system issues e.g. hardware shorts or software failure. Both Apple and Google make changes to their stacks, and when you add the difference in phone BLE chipsets, you can get some surprising results. Different phones with the same OS can sometimes behave very differently (especially the case with Android).
As with the various moving parts to the system it is critical to understand each component and factors affecting those components standalone or when integrated; we need to understand each piece of this puzzle before we can put them together and solve the puzzle!
Let us being with the strategy. This must cover debugging across the IoT technology stack as below which should cover hardware, software, radio and cloud services part of the IoT ecosystem.
The key phases to the strategy are and each phase has their own set of tools:
Phases: Design, Evaluate, Isolate, Replicate, DEBUG.
1. DESIGN
In the design phase, you develop the system to proactively address testing and debugging for any possible user issue scenario to deliver a robust IoT product. The phase will usually involve creation of a PRS (Product Requirement Specification) with built in test cases.
2. EVALUATE
This is the development phase of the product and the builds have to be constantly updated to incorporate platform update and changes. In this phase the test cases designed earlier are built and tested typically with beta users and updated. When building and deploying your solution you need to build for the entire IoT device ecosystem and be in a position to support the flow of data amongst each phases.
3. ISOLATE
As testing begins and whenever issue report or logs come in, the first imp. part of strategy is to isolate if it is a hardware or software issue. If you have followed the above procedure correctly there should not be a software issue. However, it is best to validate it here with a hardware debug tree and check if unit works correctly with a 3rd party application or test app (e.g. TI or Nordic BLE apps if protocols are supported or a custom developed app delinked from UI for testing purposes).
4. REPLICATE
In software what cannot be reproduced, cannot be fixed. It is hence critical to be able to reproduce issues. While checking if the object is not null beforehand can suffice in non-vital information but for vital parts, the object must be re-initialised or otherwise given a value is good practice on both client and server side. This may point to an error in the code/logic and is only resolvable by editing the code, so be extremely cautious releasing new firmware updates for a batch. You must build mission critical test cases to mitigate the risks while make careful updates on application side (app issues can at least be monitored and fixed in your next app spin cycle).
5. DEBUG
Usually when we debug and receive an issue report, the first step would be to check the logs to see if we can spot any non-fatal errors (didn’t crash, but threw an exception) which could help lead to the source of the problem, while there we check the app version and the firmware versions as well as what phone and Android version. If a problem is found, we’ll make changes in the code and release a new version and ensure user update their app to the latest version. In this way we slowly started to fix or develop work arounds any know issues to ensure users get the best BLE product experience; once other underlying stacks are updated e.g. a new Android OS version is released we are able to test and update each test case for each of our business customers that rely on our software. We do all of this via what we call a console application to check if a number of parameters are stable and functioning as expected.
SERVICE/ SUPPORT
This is the final part where once issues are identified, replicated and diagnosed, updates need to be issued and customer support team needs to be briefed on relevant actions to take. As evident from above any IoT device no matter how big or small need to go through a number of stages in order to have a robust solution for your users and support your dev teams. At Connect-In we have gone through each of these phases and developed a custom console (desktop application) that can be used with our firmware or application on your devices.
CUSTOM CONSOLE
How can we make use of the console for a generic BLE device?
It would be rather simple for the console to show data on other devices as the data itself is not specific to a particular device. The data is stored in a series of records, so long as the values are stored and be read from a database correctly, they can be viewed by the console. For example, you create a dummy device with signal data by creating:
dataRecord:
- deviceId: String (Device UUID)
- timestamp: Long (time of reading)
- specifiedData: Integer (Data reading needed)
- state: String (BLE state: Connected, Connecting… Disconnected, Bluetooth disabled, WiFi on/ off, etc) which you can further customise.
To be able to gather more intelligence for debugging and viewing it on the console application, you need to ensure correct breakpoints are inserted in each of your application code base. As described above a Bluetooth IoT product can be quite complex and at Connect-In Consulting we help our clients navigate all of these issues, stay ahead of the competition with BLE and IoT product design, qualification and support your development of Mobile & IoT solutions. With Connect-In Xupo Console, tools and strategies you will be well equipped to bring and maintain your BT IoT products in the market. You can get in touch via the link below to request your free copy of BLE ebook with full debugging guide and helpful tips.
Visit us: www.myxupo.com/bluetooth