ALLPCB
Overview
Historically, wearable prototypes have been difficult to develop because of form-factor constraints. Most off-the-shelf development boards and systems are designed for desktop environments where size and weight are not critical.
Larger board dimensions let manufacturers use relatively simple PCB production lines to provide low-cost development support. The available board area also accommodates conventional pin connectors for expansion. Large pin sizes and spacing on those connectors make it easy to use solderless breadboards and low-cost prototyping services for custom I/O extensions.
Although powerful systems can be built from desktop-oriented development platforms that support wearable functions, they often fail to meet the usability and ergonomic needs expected for end users and early adopters. Uncomfortable or heavy fitness wearables are unsuitable for realistic user trials and other in-the-field testing. What is required is a platform that preserves much of the flexibility of traditional development boards while adopting a form factor appropriate for wearable designs.
Hexiwear Platform
Platforms such as MikroElektronika's Hexiwear provide a way to build applications and test them in real user environments. The Hexiwear platform integrates an MCU and peripheral solution in a wearable form factor supported by open development tools. The module uses a compact hexagonal enclosure that easily attaches to wristbands to serve as a smartwatch-like IoT node, or it can be mounted in a pendant, brooch, or integrated into clothing.
The form factor is also suitable for broader smart-home deployments, where it can be used as a removable element in wall-mounted modules or larger mechanical systems. Hexiwear-based smart-home projects include smart bathroom scales that transmit measured weight to a smartphone, doorbells that report activity and display custom messages to visitors, and refrigerator magnets that report internal temperatures using the Hexiwear display.
Hardware
The Hexiwear platform is based on NXP Kinetis K64F MCU, which uses an ARM Cortex-M4 core running up to 120 MHz and supports a variety of peripherals including ADC, DAC, timers, and serial interfaces (see figure 1).
The wearable module includes a Bluetooth Low Energy SoC and eight sensors optimized for health and typical IoT applications: a six-axis accelerometer and magnetometer, a three-axis gyroscope, a pressure sensor, temperature and humidity sensors, and an optical heart-rate sensor. It also includes a 1.1-inch color OLED display.
Most onboard peripherals communicate via an I2C bus. Expansion is provided through two parallel eight-pin headers arranged as MikroBus connectors. This allows connection of MikroElektronika Click boards as well as custom expansion modules and third-party boards. The MikroBus pin spacing is compatible with standard 100-mil breadboards, which simplifies initial prototyping of custom I/O modules.
MikroBus exposes multiple serial I/O buses and provides analog, PWM, and interrupt pins. In addition to I2C, interfaces are available for SPI and UART. Available Click modules include GPS receivers, RFID readers, GSM transceivers, and even lightning sensors based on coil antennas.
Sensors and Sensor Fusion
The motion sensor suite on Hexiwear enables applications beyond wearables and home automation. The combined accelerometer, gyroscope, magnetometer, and pressure sensor can form an inertial measurement unit with multiple degrees of freedom suitable for GPS-denied aerial navigation. One user applied this functionality to create an onboard flight-monitoring system for aerial drones and quadcopters. Hexiwear's compact weight and size make it appropriate for unmanned flight. The application provides accurate feedback on position and heading to support flight in low-visibility conditions. When used with sensor-fusion techniques, the different motion sensors help compensate for each other's weaknesses. The pressure sensor improves altitude reporting accuracy.
Accelerometers such as the NXP FXOS8700CQ used in Hexiwear are built on MEMS structures. Single-axis accelerometers use a flexible cantilever attached to electrodes, with a proof mass that can move relative to a second electrode. The structure acts as a capacitor. As the mass moves, the distance between capacitor plates changes, producing a change in capacitance. By tracking those capacitance changes, the sensor interface detects acceleration along the cantilever's motion axis. Three orthogonally mounted elements provide three-axis detection.
Short-term variations in capacitance due to the moving mass make accelerometers sensitive to vibration and transient oscillations. Gyroscopes, by contrast, are based on vibrating mechanical elements that register increased amplitude when the device rotates. Like larger rotating gyroscopes, MEMS gyros are relatively insensitive to short shocks and external vibration, but they are susceptible to long-term drift and temperature variations.
Combining gyroscope and accelerometer readings with the magnetometer inside the FXOS8700CQ enables removal of most motion-noise sources. In simple sensor-fusion implementations, complementary filtering can suppress most noise types from each sensor class. For example, when calculating tilt angles from angular data, a low-pass filter reduces short-term errors in accelerometer-derived angles, while a high-pass filter eliminates long-term gyroscope drift and temperature-induced bias. Comparison with magnetometer readings provides directional confirmation.
Applications
These sensors can be combined in wearable applications developed with Hexiwear. Examples include fall detectors for older adults and personal cardiac monitors for people managing health conditions. Both applications demonstrate how sensor fusion yields robust outputs by combining multiple sensor types.
Applying the sensor-fusion techniques used for drones to a fall detector can reduce false alarms caused by short-term accelerometer noise. When worn on a belt or wrist, a gyroscope can detect body or limb rotation during a fall, while the accelerometer records a sudden increase followed by an abrupt stop and a period of low activity. Software can recognize fall patterns. Research literature provides typical motion curves for falls that help determine appropriate thresholds. Machine-learning techniques trained on motion data from fall tests have been shown to yield more robust detection.
Patients recovering from major congestive cardiac events can use Hexiwear-deployed sensors in a similar way. In that case, inputs include signals from a Maxim MAX30101 heart-rate sensor. Mild exercise is important during recovery, but overexertion should be avoided. By correlating activity with heart rate, a wearable can help determine whether a patient meets exercise goals without undue stress. Abnormal heart-rate responses to exercise can trigger alerts that a companion smartphone may relay to healthcare providers. Heart-rate data can also enhance fall detectors by helping to assess the wearer's condition after an event.
Software and Development Tools
Hardware I/O, the processor, and sensors are only part of the equation when building wearable or other sensor-driven applications with Hexiwear. The platform is supported by a complete open-source toolchain and libraries available from online repositories such as GitHub and ARM mbed. These libraries include modules for cloud connectivity and services.
The core of the Hexiwear development kit is the NXP Kinetis Software Development Kit (SDK). This toolchain is based on Eclipse and GNU toolchains. The IDE is Eclipse-based, with support from GCC and GDB. After installing the Kinetis tools, users can add modules from the Hexiwear GitHub repository. Another development path is Zerynth, which enables Python programmers to begin module development.
GitHub downloads include example bootloaders and project files that serve as templates. Downloads and hardware support are typically enabled via the Hexiwear dock, with drivers handling USB communication for mbed downloads.
Example modules on GitHub often use a simple main() loop structure. Applications execute each statement in main() and then loop back to the start. A common strategy to prevent excessive battery drain is inserting a wait(x) function at the end of the main loop. Despite the simple structure, the core of health-monitoring wearable applications is present. Many Hexiwear GitHub modules also support operating systems such as mbed OS or FreeRTOS, which enable instantiation of multiple cooperating threads that can be triggered by hardware interrupts from various peripherals.
A typical IoT wearable application is an activity monitor that periodically reports status to a smartphone or tablet over Bluetooth Low Energy. In a simple main() structure, the easiest organization polls sensors on each pass, filters data, and buffers processed values. Sending data over BLE on every pass is possible but can quickly drain the battery and is often unnecessary. One approach is to implement a global counter variable and buffer data in a queue each pass until a threshold is reached. A simple if-then statement determines whether to trigger BLE transmission, which collects buffered data, reestablishes a connection to the smartphone, and sends the data.
The BLE module is accessible through C++ classes defined in the Hexi_KW40Z.h header, providing functions to send and receive data over BLE. Default class implementations include data-packet definitions for health, weather, and motion-sensor transmissions.
In OS-mediated multithreaded implementations, the application can be divided into multiple threads. In a health monitor, a typical structure feeds one or more sensor-recording threads into processing and filtering threads, while a separate thread handles BLE communication. One strategy is to use timer interrupts accessed via callback functions (for example, lptmr_Callback()) to periodically wake threads. The BLE communication thread usually has a longer period than sensor-recording threads. Threads can buffer data so the filtering thread only runs as often as the BLE thread does, conserving power.
However, when a monitor must respond quickly to anomalous data and issue alerts, it may be important to filter and process data as fast as possible. In that case, a distinct BLE thread may be required to send alert messages in response to triggers identified by a processing thread. Alternatively, the BLE thread can wake on a flag set when an alert is detected. The choice depends on how quickly the companion smartphone app must respond. In many cases, BLE timer intervals are short enough to support the latter architecture.
Conclusion
Functionality can be easily extended with additional Click modules to detect environmental factors such as humidity that may be relevant to the wearer. The Hexiwear platform therefore provides flexible and accessible support for a range of IoT applications. It is suitable not only for wearable devices but also for other sensor-oriented devices.
