Wearables Platform Eases IoT Device Prototyping

Historically, wearable designs have been difficult to prototype. The core problem is one of size. Most off-the-shelf development boards and systems are designed for a benchtop environment where size and weight are not crucial.

The larger board sizes make it easy for manufacturers to provide low-cost development support using relatively simple PCB manufacturing lines. A relatively large amount of board real estate also supports traditional header connectors for expansion. The large pin size and spacing on these header connectors make it easy to use one-off breadboards and very low cost prototype production services as custom I/O expansion.

Although one can build a highly functional system using benchtop oriented development systems that can execute the functions of a wearable, it fails with respect to the need for a system that trial users and early adopters can use as though it were a real product. A fitness wearable that is uncomfortable and heavy will fall short when it comes to usability and other vital in-theater tests and experiments. What is needed is a platform that provides most if not all the flexibility of a traditional development board, but in a form factor that makes sense for wearable device design.

Platforms such as MikroElektronika’s Hexiwear provide a way of building applications and testing them in a realistic user environment. At its core, the Hexiwear platform provides an integrated MCU and peripheral solution in wearable form supported by an open-source development environment. More importantly, it is packaged in the form factor of a compact hexagonal module that can easily be attached to a wristband for use as an IoT-enabled smartwatch. Alternatively, it can be fitted into a pendant ring for use as a brooch or for integration into items of clothing.

The form factor also suits uses in the wider smart home environment where it can be deployed as a removable element in a wall-mounted module or larger mechanical system. Smart home focused projects that have been based on Hexiwear include a smart bathroom scale that transmits the measured weight to the user’s smartphone, a doorbell with the ability to report activity to homeowners remotely and display custom messages to visitors, and a smart refrigerator magnet able to report the internal temperature to users on the Hexiwear’s display.

The Hexiwear platform is based on a Kinetis K64F MCU featuring an ARM® Cortex®-M4 core running at up to 120 MHz, supported by numerous peripherals including ADCs, a DAC, timers, and serial interfaces (Figure 1).

Figure 1: Block diagram of the core Hexiwear device. (Image source: MikroElektronika)

The wearable device includes a Bluetooth Low Energy (BLE) SoC and eight sensors optimized for wellness and other typical IoT applications, such as a six-axis accelerometer and magnetometer, three-axis gyroscope, pressure sensor, temperature and humidity sensors, and optical heart rate sensor. It also includes a 1.1 inch OLED color display.

Most of the onboard peripherals communicate using the I²C bus. Expansion is possible through the MikroBus, arranged as two parallel eight position header connectors. This allows the connection of MikroElektronika’s Click boards as well as custom expansion modules and those of other vendors. The MikroBus connector pin spacing was designed to be compatible with standard 100 mil-pitch breadboards, allowing easy initial prototyping on custom I/O modules.

The MikroBus provides access to several serial I/O buses as well as providing analog, PWM and interrupt pins. In addition to I²C, connection is possible through SPI and UART interfaces. Modules already available that use the Click format include GPS receivers, RFID readers, GSM transceivers, and even a lightning sensor based on a coil antenna.

The range of motion sensors onboard the Hexiwear have allowed the platform to move into applications beyond wearables and the home. The combination of an accelerometer, a gyroscope, a magnetometer, and a pressure sensor, make it possible to create an inertial measurement unit with ten degrees of freedom for GPS-free aerial navigation. One user has applied this to create an onboard flight monitoring system for aerial drones and quadcopters. The Hexiwear is small and light enough to be carried by the drone. The application supports flight in poor visibility conditions by providing accurate feedback on the drone’s position and heading. The different motion sensors help compensate for the drift of others when used with sensor-fusion techniques. The pressure sensor helps improve accurate reporting of altitude.

An accelerometer such as the NXP FXOS8700CQ used in the Hexiwear is based on a MEMS structure. A single-dimension accelerometer uses a flexible cantilever attached to an electrode that holds a mass able to move relative to a second electrode. The overall structure acts as a capacitor. As the mass moves, the distance between the capacitive plates changes, leading to a change in the capacitance. By tracking these variations in capacitance, the sensor interface can detect changes in acceleration along the cantilever’s direction of movement. Three mounted orthogonally to each other provide three-axis detection.

The tendency of the accelerometer’s moving weight to oscillate leads to short term variations in capacitance and sensitivity to vibration. A gyroscope, on the other hand, is based on vibrating micromachined arms that register increased amplitude as the device is rotated. Like a larger gyroscope which relies on spinning elements, the measurements are relatively insensitive to short-term shocks and external vibration. However, the gyroscope is prone to drift and is more sensitive to temperature changes.

The combination of readings from the gyroscope and accelerometer, as well as the magnetometer in the FXOS8700CQ, provides the ability to remove most of the sources of motion noise. In a relatively simple sensor-fusion application, a complementary pair of filters (Figure 2) can remove the bulk of the noise from each of the sensor types. For example, taking angular data to calculate a tilt angle, a low-pass filter helps remove the short-term errors from accelerometer readings converted into angular coordinates, and a high-pass filter removes the long-term drift and temperature fluctuations from the gyro. Comparison with magnetometer readings can provide confirmation of direction.

Figure 2: Complementary filters for accelerometer and gyroscope processing.

These sensors can be applied and combined for wearable applications developed using the Hexiwear. One example is a fall monitor for elderly people. Another is a personal heart monitor for people looking to improve their fitness. Both are applications that demonstrate the effectiveness of sensor fusion, and the ability of multiple sensor types to produce a reliable output.

If we apply the sensor fusion techniques used in the drones mentioned above to a fall detector, it is possible to build a sensor that is far less likely to be susceptible to raising false alarms because of short-term noise appearing on the accelerometer input. If worn on a belt or wrist, the gyroscope will detect the rotation of the body or arm during a fall, and the accelerometer will register a sudden increase followed by an abrupt stop and a period of little movement. Taken together, software can recognize the pattern of a fall. A number of research papers have investigated the typical motion profiles of falls that can be used to derive appropriate thresholds in a fall detector application. Machine learning techniques based on motion data captured from fall tests have been shown to help the development of more robust detection techniques. Having combined data from multiple sensors helps reduce the risk of false positives, while ensuring a low risk of false negatives.

People recovering from a major congestive heart incident can use the sensors deployed in a Hexiwear in a similar way. In this case, the inputs will include signals from the Maxim MAX30101 heart rate sensor. Light exercise is very important to recovery from congestive heart failure, but it is just as important to not over exert. By tracking movement in combination with heart rate, a wearable application can help determine whether the patient is meeting his or her exercise targets and is not over stressing the heart. Anomalous readings for heart rate against the motion data can be used to trigger alarms that are relayed by the host smartphone to health professionals. A fall detector could similarly be augmented with the heart rate data to help determine the state of the wearer after an event.

The hardware I/O, processor and sensors are only part of the equation when building an application using Hexiwear for wearables or other sensor-driven uses. To ease the creation of applications, the platform is supported by a complete open-source toolchain and libraries that are available through the GitHub online repository, and ARM’s mbed code library, among others. The libraries include modules for cloud connectivity, providing access to services such as WolkSense.

The core of the Hexiwear’s development suite is the NXP Kinetis software development kit (SDK). This is a toolchain based on the Eclipse and GNU codebases. The IDE is based on Eclipse, which is supported by the GNU compiler collection (GCC) and GNU debugger (GDB). Once the Kinetis tools are downloaded and installed, the user can add modules from the GitHub Hexiwear repository. An alternative development environment is Zerynth, which provides a way for programmers more familiar with Python to start developing for the module.

The GitHub downloads include sample boot loader and project files that can be used as templates for the target application. Typically, download and hardware support is enabled through the Hexiwear docking station (Figure 3), with communication over USB handled through drivers downloaded from mbed.

Figure 3: Block diagram of the Hexiwear and docking station combination. (Image source: MikroElektronika)

The example code modules provided by GitHub typically use a simple looping main() structure. The application proceeds through each of the statements in the main() function and then loop back to the beginning. A common tactic to prevent over activity on the battery powered platform is to insert a wait(x) function at the end of the main() loop. Even with such a simple structure, the core of a health monitoring wearables application is there. However, an operating system such as mbed OS or FreeRTOS supported by a number of the modules on the Hexiwear GitHub repository provides a more flexible option, with the ability to instantiate multiple cooperating threads that can be triggered by hardware interrupts from the various peripherals.

A typical application for an IoT wearable is an activity monitor that reports status on a regular basis to a smartphone or tablet over BLE. In a simple main() structure, the simplest way to organize the application is to poll the sensors of interest on each pass, filter the data and then buffer the processed values. Although it is feasible to communicate data over BLE on each pass, this is likely to drain the battery quickly and is largely unnecessary. One approach is to implement a global counter variable and to buffer the data in a queue on each pass until the counter threshold is hit. A simple if-then statement can determine whether the BLE access function is triggered. This collects data from the buffer, re-establishes the connection to the smartphone and sends the data. The Hexiwear front panel provides the ability to pair the target smartphone over BLE initially, avoiding the need to code that functionality within the application, at least for prototyping purposes.

Access to the BLE module is available through C++ class defined in the Hexi_KW40Z.h header file. This provides a number of functions to send and receive data over BLE. The default version of this class includes packet definitions set up for transferring health data as well as weather and movement sensor data.

In a multithreaded implementation mediated by an operating system such as mbed, the application can be divided into multiple threads. In a health monitor, the typical structure would be to have one or more sensor recording threads feeding into a processing and filtering thread. A separate thread then takes care of BLE communication. One strategy is to use timer interrupts accessed through a callback function, such as lptmr_Callback(), to wake the threads at regular intervals. The BLE communications thread will usually be on a longer cycle than that of the sensor recording threads. These threads can buffer their data so that the filtering thread runs only as often as the BLE communications thread.

However, it may be important to filter and process the data as quickly as possible in the case of a monitor that needs to raise an alarm in response to anomalous data. In this case, a separate BLE thread may be needed to send out alarm messages in response to a trigger condition being identified by the processing thread. Alternatively, a flag may be set that is used by the BLE thread when it wakes to send both alarms and data. The choice will depend on how quickly the smartphone app needs to respond. In many cases, the BLE timer interval will be short enough to support this latter architecture.

Conclusion

Through the use of additional Click modules, functionality can easily be expanded to support, for example, the detection of humidity and other environmental factors that may be pertinent to the wearer. As a result, the Hexiwear platform provides flexible and easy-to-use support for a wide variety of IoT applications. Not only for wearables, but for other types of sensor-oriented devices as well.