Developing a wearable electronic product involves juggling design constraints and compromises in ways that are quite a bit different from a conventional non-wearable design.
In this article, I’m defining a wearable product as a body-worn device, with its own power source, that doesn’t restrict the movement of the wearer. Examples would be a pair of smart glasses, or a smart watch.
While design constraints are applicable for any type of design, they become more critical for wearable devices. For example, the use of a fan, or even a heavy heatsink, isn’t an option in a wearable product. This makes thermal management more critical.
The battery size, and thus energy storage capability, is also a limiting factor for wearable devices.
User interfaces also need to be carefully thought out. Common user interfaces, such as pushbuttons and touchscreens, will take up too much of the premium real estate in a wearable device.
Other user interface methods such as eye tracking, gesture controls, speech recognition, and touchscreens are used instead.
If your product incorporates multiple wireless features (for example Bluetooth and cellular) then the antennas will also take up quite a bit of space, and it becomes challenging to position them so that they don’t interfere with each other when space is so limited.
For a wearable product, the primary considerations from the user’s perspective are:
- Functionality: Camera, audio, GPS, user vitals, etc.
- The form factor: It has to look sleek and attractive.
- Size and weight: The design must be as small as possible so its not obtrusive.
- Product comfort for the user.
- Performance factors, including battery life and charging time.
From the design engineer’s point of view, a design must be produced that meets the above requirements. It also needs to have the proper safety margins that can be consistently reproduced. Compromises will usually need to be made before finalizing the specifications.
First, determine if essential requirements are feasible. A good starting point is the physical size. If you can’t meet the size criteria then the product is not feasible.
The physical size and product form factor determines the battery size and shape, the available real estate for user interfaces, and the maximum size of all the electronics.
A bit of back and forth usually happens in this stage to reach an acceptable compromise. Sometimes, even increasing a dimension by 1mm can result in dramatic improvements in battery capacity, for example.
As for the hardware, the initial list of hardware functional requirements might include everything from Wi-Fi, Bluetooth, GSM/LTE radio, audio, camera, video display, GPS, accelerometer, 3D gesture sensor, barometric pressure sensor, ambient light sensor, distance sensor, biometric sensor, wireless charging, haptic feedback, and so on.
All of this needs to be powered by a battery that lasts for a reasonable number hours on one charge with all features running.
The software might call for image recognition and voice recognition, maps, video displays with video overlays and other augmented or virtual reality features, and constant web connection to services such as Alexa.
Obviously, all of these requirements cannot be met with the current state of the art technology. So, expectations must be set as to what is achievable, and an iterative process engaged to arrive at some mutually agreeable product specifications.
From the design point of view, anything that can be used to reduce power consumption and size, and thus heat generation, should be actively considered.
Consider the following questions in regards to your own product:
Do Wi-Fi, BT and other wireless functions need to be simultaneously active at all times?
Can you add sensors such as accelerometers, magnetometers, proximity sensors, pressure sensors etc. to determine the exact state of the device at any time? This helps determine what part of the system will be active at a given time.
What can the firmware and application software contribute to achieve low power consumption, while, at the same time, not taking away any functionality where it counts? For example, can the processor be put into sleep mode, or throttled back when the device isn’t actively being used?
If the device includes a display can it be shut down if the content has not changed in a while, or if it is not in a position where it can be read by the user. Can it be dimmed if the ambient light is low? Can the GPS receiver be shut down if no motion has been detected since the last position update?
The use of a less resource-constrained proxy to offload the wearable workload should be seriously considered. A smartphone is the usual proxy for a wearable product.
Your device can communicate with a smartphone using just Bluetooth, and then the smartphone can provide Wi-Fi, cellular connectivity, and a high-speed processor.
In some cases, the phone can even act as a secondary user interface. Such a scheme is employed in the iWatch, for example. Without a phone as a proxy, it is simply impossible, given the current state of technology, to have all these wireless features in the form factor of a watch.
After the initial set of expectations have been set, it is time to work on the hardware. First of all, you need to choose the proper SoC (System on Chip). The SoC should natively interface with as many of the sensors and actuators as possible.
If a camera is required, then it makes sense to choose a SoC with a camera interface. The same applies to displays, Wi-Fi, Bluetooth and other features. The SoC should also be chosen to be power efficient.
Because of the limited space available for wearable devices, a highly integrated chip solution is preferred over using several discrete chips. This limited space usually also eliminates the possibility of using any kind of pre-certified module.
One of the key features to look for is the feature size of the process used to fabricate the silicon SoC. Generally, the smaller this is, the denser the chip will be.
Since the chip sizes do have limitations due to fabrication process yields, this means that the denser the chip, the more functionality it can pack on a single chip.
If wireless functionality is required, choose an SoC that integrates as many of the required wireless radios as possible. Also choosing an SOC with an integrated RF switch can reduce the number of antennas needed. Or, it eliminates the need for an external antenna switch if sharing a single antenna.
For example, both Wi-Fi and Bluetooth use a carrier frequency of 2.4GHz so they can share a single antenna, which reduces space requirements. Most such SoC’s also have multicore processors with integrated memory that are tightly coupled, with one or more cores dedicated to running the application software.
Sometimes, it isn’t possible to get by using a single SoC. In those cases, the various chips should all have compatible communication channels such as SPI, I2C or USARTs.
To simplify the power delivery and management, the SoC’s should be chosen to run off a common set of power rails. If a higher voltage rail is needed for wireless functions, the SoC should also incorporate its own DC/DC switching converter to space compared to using discrete converters.
Qualcomm, Texas Instruments, ST, and others manufacture such SoC’s. So, some research may be required to find one that meets the above requirements.
Unfortunately, some of the most integrated solutions come from Qualcomm, who primarily only works with larger companies, not startups.
It is also worthwhile to consider using an FPGA (Field Programmable Gate Array) chip to integrate the functionality that would normally have required multiple chips. This can require quite a bit of development time though.
Ultimately, on top of the reduction in the overall size, the product cost will typically be reduced when using an FPGA.
The ultimate solution is going with an ASIC (Application Specific Integrated Circuit) which is a chip custom developed for a single application.
However, development of an ASIC is generally too expensive and complex for startups. This option should only be considered once the sales volumes justify the high upfront development costs.
Sensors and Actuators
Sensors and actuators are what users usually perceive as a wearable product’s core features. There are quite a few miniature devices on the market that are geared toward the wearable market.
These include MEMs microphones, bone conduction speakers, multi-axis gyros, barometric sensors that detect what floor of a building the user is on, and many others.
As stated earlier, there are additional sensors that provide feedback about the state of the device without expressly providing any feedback to the user. These may commonly be incorporated so as to minimize the power consumption when the device isn’t in use.
Texas Instruments, Bosch and ST are good places to start for sensors.
The battery in wearable device deserves significant consideration. To start, it has to have high energy density to keep the entire device operating for its intended run time.
The use of li-ion battery technology is an essential requirement for wearable devices. Even then, the proper supplier must be carefully selected.
Some batteries have higher voltage and higher energy density than others. This has to be balanced with safety, which is generally more stringent for a wearable product for obvious reasons.
Protection of the battery should be given the proper attention. This applies not only to electrical protection, but also the mechanical housing of the battery.
For example, the battery should be snug, and not rattle around in its housing. At the same time, it should have some space to allow for the swelling that will naturally occur over time.
Keep in mind that lithium-ion batteries have the potential to be very dangerous if not handled and designed properly.
Another thing to consider is irregular-shaped, or curved, batteries. They can allow the best use of the available space, but will need to be custom designed in almost all cases.
A big downside of using a custom design battery, is that the battery will require various safety certifications which can add to the project’s upfront costs.
Whereas, off-the-shelf batteries can be purchased that already have the necessary safety certifications.
Finally, since the battery is generally non-replaceable, it must have good life cycle characteristics (i.e. how many times can it be recharged).
Combining that requirement with a custom battery design means that life cycle testing needs to be performed. Since this testing can take a long time, the battery design needs to be finalized early in the design phase.
Battery charging is generally done through charging contacts such as through a microUSB connector. Since these contacts are exposed to sweat and dust, proper consideration should be given to ensure reliable charging.
Wireless charging and solar charging are generally not feasible for wearables because they require fairly large surface areas for the receiving coil, or solar cells, in order to generate enough energy to charge the battery in a reasonable amount of time.
Putting all the components together will commonly require multiple thin-substrate PCB’s that are stacked together. The use of flex PCB’s should also be considered in order to maximize the available space.
The interconnections must not be overlooked, and the connectors need to be very small with high reliability.
Thermal management will heavily dictate the placement of components on the PCB. In the first place, the reliability of a component will be diminished if it gets too hot.
Another consideration is that the user may not want to feel a body-worn device that is uncomfortably warm, even though it may still be quite safe for the components themselves.
So, the part of the device that is actually in physical contact with the user should be kept free of high heat dissipating components. There are actually published limits for acceptable maximum temperatures for devices that contact human skin. These limits vary depending on the actual type of material.
With regards to the battery cavity, it should also be designed with some form of relief vent. It should point away from the user in the event of a (hopefully rare) catastrophic failure.
A wearable device is generally subjected to a lot more mechanical abuse than a normal stationary product.
So, a more rigorous shock, vibration, drop and tumble testing regime is required to ensure reliable operation over the product’s lifetime.
I highly recommended that you track failure rates and analyze the failure types. Be proactive in spotting potential serious issues before they become catastrophic ones.
Designing a wearable device is inherently more complex and expensive than designing a similar functioning non-wearable product. The severely limited space is a major design constraint that generally requires significant tradeoffs.
Battery life and product size are the two primary tradeoffs required when designing a wearable product.
Don’t forget, since the product will be worn by the user you will need to add additional safety requirements.
Other content you may like:
- How Can I Determine the Complexity (and Cost) to Develop My Product?
- How to Select the Best Power Source For Your Hardware Product
- FAQ: Can an Arduino or Raspberry Pi Be Used in a Commercial Product?
- Bluetooth or WiFi – Which is Best for Your New Wireless Product?
- Review of Bluetooth Low Energy (BLE) Solutions