Wearable technology is having it's time in the sun right now with the sector still experiencing continued growth. This is dropping the price point of wearable technology over time and hence putting cheaper devices in the hands of more casual users, broadening the end user demographic. However it's not very often that explanations are published on how running wearable technology actually works in general from the hardware to the user interface. In this article we'll describe some of the key fundamental concepts from the perspective of the running gait analysis use case.
Let's kick off with the hardware, what's actually under the plastic covers of the device.
Bringing together all the hardware components is the circuit board. All of the components we are about to mention will be mounted on to the board. In a standard IMU* (inertial measurement unit) wearable that we might use for gait analysis the board will host the following key components:
The board in general requires a power source to function and the power can come from either a rechargeable Li battery or an old fashioned coin cell battery (CR2032). Commonly both are fitted to the board so that even if the rechargeable battery is dead the components can still function.
The typical standard sensor configuration usually includes an accelerometer, a gyroscope and in some cases a magnetometer, normally all measuring from the 3 principle axis, x, y and z. In newer devices it is becoming more common to also see a barometer. Sensors such as temperature and optical measures tend to be reserved for uses other than recording running gait metrics.
The processing unit, exactly as the name suggests receives the incoming raw signal from the sensors and filters it and is essentially the 'brains' of the device in terms of performing processing tasks. Data processing, how the device understands what it's measuring, is conducted by the firmware algorithms that are embedded into the processor. By the time the processor is finished its work, the data is generally highly sub-sampled and transformed into comprehensible numbers that are ready to be sent on.
Within the CPU it is now relatively common to host flash memory. This onboard memory means that data that has been collected and processed can be saved temporarily until there is a convenient opportunity to transmit the data away via a wireless signal. This functionality is key to wearable devices that record data whilst you run for long periods of time where you do not carry a phone or watch with you. At Runfisx we rely on this capability routinely during our gait assessments.
The wireless module is responsible for sending the signal away from the device to a receiving unit such as a phone, tablet or watch. For a lot of devices it is currently standard practice to use a dual mode setup where data can be transmitted by either Ant+ or Bluetooth Low Energy. Each of these protocols have their advantages and disadvantages and hence different devices might benefit from utilizing either one in different situations. These packets of data will eventually be read into your display unit application for you to view.
In some ways it can be said the firmware is where the magic is in terms of wearable devices. And for the most part this is true. The algorithms that make up the firmware that is embedded into the processor transform the raw and relatively meaningless data into something comprehensible that an end user could gain value from. However it is not just a matter of writing some basic code and then metrics just appear.
Writing good firmware code is an art in itself that requires an understanding of the movement patterns expected, the range of diversity of these patterns and a nuanced ability to know how to tell the processor how to understand them. Not only that it involves a lot of iteration. Some simple code may generate a metric but for that metric to be accurate and reliable and hold true for a multitude of possible end users is where the challenge is. Ultimately the original code will require a huge amount of refinement through beta testing with test subject runners in order to get to something that can be relied upon.
In the case where the hardware configuration contains multiple sensors it can be possible to drastically improve the accuracy and reliability of the data by applying some statistical computation that integrates the raw data from each sensor. This process is called sensor fusion and is becoming more and more common place. This approach can help the firmware engineer by providing them with a 'cleaner' dataset to begin their work with.
So if you have ever wondered why some wearable devices just tend to be more accurate and reliable than others - its most likely down to the quality of the firmware and just how rigorous the firmware refinement has been.
Once the wearable device has collected and stored it's data it will be sent wirelessly to some sort of display unit. The most common of these for running gait analysis are a watch, a phone or a tablet. At Runfisx we almost always interface with a tablet. The Bluetooth or Ant+ receiver within the unit will pull in the data packages, store them into a background database and then display them as prompted by the code written into the application. At the time of writing there is still a split in the type of databasing that different wearables offer. Some, such as Stryd for example are locked to a single user. Where as others that are designed for professional use such as iMeasureU, will host a multi-user database.
For us at Runfisix the quality of the user interface of the app is critical. Even if the firmware has done a fantastic job and the metrics themselves are extremely valuable, if the resulting data is not displayed effectively in the app, then the value of the entire system is ultimately compromised. It's worth noting that further data processing can be done by the app. Particularly in the case where data items need to be compared to one another, overall run data needs to be averaged/summarized or aggregate metrics need to be shown that combine a cluster of computed metrics together.
So with all this said what is it that makes a wearable useful for running gait analysis in our experience?
Mobile gait analysis criteria
In order for a wearable device to be considered useful for mobile gait analysis for us at Runfisix it must fulfill a few basic criteria.
1) Firstly it needs to be able to record autonomously without the runner needing to carry a phone or other receiving unit. This recording to memory has to be able to store at least as much data as would be generated from a 5 hour marathon effort.
2) Secondly it needs to calculate useful metrics that can describe something significant about the runner's gait characteristics. And these numbers need to be both sufficiently accurate and reliable.
3) Thirdly the data needs to download from the device quickly. If the download takes more than 2 minutes for a basic 20-30 min run then we don't really consider the device particularly usable.
4) Finally the user interface needs to be able to convey the important data in a way that is digestible and within relevant context. Clear data anomalies and trends need to be displayed in a way that helps the user rather than causing them mental friction.
Some example running wearable devices that are available to purchase include:
Garmin (run dynamics), Coros Pod, Stryd, RunScribe, Milestone**, RPM2, Moticon, Arion, Shft, dorsaVi, iMeasureU.
We hope you found this quick explanation article into the basic fundamentals of how running wearable devices work useful. In future articles we will reference back to some of these concepts with links to tie the posts together. If there is something we have missed that you would like know about wearables at a fundamentals level then please add a comment below.
*IMU. Inertial measurement unit: Is an electronic device that measures specific data on the movements of a person's body using a combination of accelerometers, gyroscopes and sometimes magnetometers.
**recently acquired by Under Armour