Designing a connected product around a coin cell

Published on: 31st August 2018

There is an increasing demand for “smart” devices that are capable of measuring and reporting on their usage, but are similar in size and appearance to traditional devices that already have market acceptance.  This more often than not results in a coin cell battery being deemed necessary to keep the size and cost down.  In this article, Richard Gledhill, DCA’s Senior Software Skill Leader, looks at some of the challenges this poses.

Many of the challenges were faced during the development of DCA’s own “Card” connected dry powder inhaler concept.  It features a multi-dose disposable inhaler and a re-usable sensor module that attaches to it.  The sensor module monitors technique and compliance by measuring orientation, shock and inhalation profile.  As a connected medical device, Card needs a long battery life and medical-grade reliability and accuracy.  Its single, tiny coin cell must support interfaces to mechanical systems and sensors, a Bluetooth interface to a phone or tablet, and a regular but unpredictable usage pattern.

In Card, the monitoring is started when the patient opens the device; it must then take readings until the inhalation activity has finished.  Card stores the monitored diagnostics such as the inhalation profile in a log on the device.  A partner app running on a phone, connected via Bluetooth Low Energy (also known as Bluetooth LE or Bluetooth Smart), is used to visualise and provide guidance on the new data.  When the user’s phone is in range, Card automatically sends the dose diagnostics via Bluetooth so that the user can see the results.

Challenges such as accurate and consistent mechanical measurement of the flow, the compact physical dimensions and reliable data storage were significant enough in their own right.  Adding in the need for relatively power-hungry wireless communications and 5 years of operation on a single coin cell further increases the challenge.

The main development challenges related to the coin cell come from its very limited current capability and capacity.  These affect every aspect of the design: physical size, choice of mechanical parts, monitoring systems, data storage, Bluetooth connectivity, selection of microcontroller and other electronics components, even the architecture of the software itself.


So what does having such a tiny power source, with such a tiny power budget, actually mean in terms of product development?  Here we take a look in more detail at some of the challenges that arose during our development work on Card and similar projects.

Measuring physical characteristics such as pressure changes might be accomplished by using an optical transmitter and receiver which results in a pulse train that can easily be read by a microprocessor.  Counting the pulses allows calculation of the pressure change and therefore the inhalation profile of pressure over time.  However, running an optical transmitter such as an LED continuously takes more current than the battery can provide.  Pulsing the transmitter with bursts of energy is a well-documented solution, with these pulses potentially being extremely short.  However this only works until the pulses become so short that the transmitter no longer acts like a simple on/off switch and analogue side-effects begin to affect the received light values, making readings unreliable.  At this point, a more sophisticated approach is required, such as pre-charging a capacitor to improve the turn-on speed of the LED and make the best use of the pulse length available.

Once this problem has been solved, it is possible to take readings and establish the inhalation profile when using Card.  Storing the dose information to flash would, in normal circumstances, be considered a relatively trivial exercise.  Writing data to flash typically takes 5-10mA, although this is for a very short period of time (usually tens of microseconds), so it can be covered by existing bulk circuit capacitance.  What happens though when the area assigned to record storage in flash becomes full?  Normally, a strategy is used of erasing the oldest records to make space for new records; however erasing a sector of flash can take several mA for tens of milliseconds. If this happens fairly frequently, it can use up a considerable amount of power budget.  Therefore one potential solution we have explored on Card is to dimension the flash storage to allow storage of enough records such that there is no longer a requirement to erase any flash.


Once the measurements have been stored, this data must be sent from Card to a paired mobile device such as a phone.  Once again, the tiny current capability of a coin cell presents more challenges.  The inability to supply much current is well documented as being troublesome when used to power radio transmissions, due to their current-hungry, bursty nature – the data is transmitted in tiny bursts of energy lasting only microseconds, but each burst of energy requires a significant current of many mA, which is more than the battery can comfortably supply.  This can generally be managed by the use of suitable capacitors between the battery and the RF transmitter chip.  However this brings with it its own problems.  Leakage current through these capacitors can drain the battery in the background.  Therefore it is critical to manage the amount of data transmitted via Bluetooth to limit the number of capacitors and consequently the cost, PCB space required and background current drain.

The Bluetooth Low Energy wireless protocol is designed to assist the development of such low power systems, but there are still a number of challenges when using it at this level of available power.  For instance, making Card discoverable to phones involves a high rate of data packets being transmitted, advertising Card to any nearby Bluetooth device.  It may be that the default advertising packet rate is so high that the current limit available from the battery is exceeded and the system resets.  However, set the rate too low and the device either becomes incompatible with some Bluetooth phones, or takes unduly long to be discovered by a phone causing time-outs or failures.

A further complication is that repeated pairing with different phones or tablets may result in an area of flash containing the bonding information needing to be repeatedly erased.  If this issue is not handled, it will further reduce the battery life.  One possible solution that suited our requirements for Card is to redirect storage of the bonding information to a less energy-intensive storage medium, such as an area of RAM that is maintained when the device is not active, or an area of EEPROM.

"Sending that much data too fast could drag the battery voltage down, so intelligent throttling of the flow of data may be required."

Similarly, care needs to be taken when transmitting (relatively) large amounts of data.  Sending a single dose record may only be a small number of bytes, but synchronising Card with a user’s new phone without the full dose history on it could easily result in a few thousand records being requested from the phone, meaning many thousands of packets are exchanged between Card and phone.  Sending that much data too fast could drag the battery voltage down, so intelligent throttling of the flow of data may be required.


It might be deemed desirable to alert the user that the Card device needs to synchronise with the user’s phone – perhaps by flashing an LED.  This seems so simple, yet with the coin cell’s voltage varying between 3.0V and less than 2.0V, a simple arrangement may not work, particularly if, as was the case with Card, a DC/DC step-up convertor is not appropriate due to inefficiencies, energy losses and parts cost.  It may be necessary to pulse the LED using a charge-pump system, for instance, and varying the pulse duty cycle and speed depending on the battery voltage.  Even lighting an LED, then, can be a challenge.


To achieve the battery life required for a disposable device such as Card, the microprocessor must require an incredibly low current while the device is not in use – generally a microAmp or less.  This means in most cases that the device is effectively coming out of reset each time, rather than a standby mode, meaning that it has to go from a standing start to taking the first measurements within a very small amount of time.  For a mechanically-activated start which could be triggered when movement is just beginning, such as when a Card user opens the device and begins to inhale, this could literally be measured in milliseconds.  This is challenging across a range of temperature, stability and start-up requirements and will be an important factor in the choice of microprocessor.


On top of these core functional requirements, there are considerations for what happens at the very start and end of the device’s lifespan.  Programming on the production line could use up the coin cell’s valuable energy unless carefully handled, as could programming configuration, serial numbers or security parameters into flash.

Perhaps more of a problem is what happens as the battery comes to the end of its useful lifespan.  Its nominal (unloaded) voltage may still appear reasonable – perhaps still more than 2V – but as soon as any current is drawn from it, it may drop significantly, potentially below the minimum operating voltage of the microprocessor which is typically around 1.7V for many architectures.  Similarly, as the battery voltage drops, references and ranges for analogue inputs may be affected, together with anything driven from the battery directly such as the optical transmitters and receivers used for the Card dose measurement.  Any switched-mode power supplies will have to work harder to generate stable voltage supplies, further increasing the load on the battery and exacerbating the problem.  Energy-intensive operations such as Bluetooth transmissions and pairing may need to be slowed down or even disabled.  If such low-power occurrences are not handled gracefully, various parts of the system including the microprocessor may spontaneously reset or misbehave – hardly appropriate for a medical device such as Card.

And finally, one last thought.  What about when the device is sitting on the shelf, in between manufacture and first usage?  One option is, of course, to have a small strip of pull-tape between the battery and its contacts, but this could be problematic due to IP rating constraints.  It might also be necessary to have some data retained from manufacture, such as a real-time clock value.  In either case the current drawn must be virtually zero before first use.

"What about when the device is sitting on the shelf, in between manufacturer and first usage? might be necessary to have some data retention from manufacture, such as a real-time clock value."


All aspects of the design of a complete connected device such as Card which involve a coin cell are likely, therefore, to actually revolve around the coin cell itself.  This is a fundamental difference to designing devices with larger battery packs or a permanent power supply.  Our considerable experience in this area means that we solve many of the problems above on a regular basis – and many more that aren’t covered in this article, such as the differing behaviour of supposedly identical coin cells, temperature, transportation and storage effects, oxidisation layers within the coin cell and so on.

Looking forward, this area is likely to become even more challenging and exciting as Bluetooth begins to be replaced in some situations with ultra-low power cellular network access through technologies such as NB-IoT and LTE-M (also known as LTE Cat-M1).  Could we see a coin cell powering these devices?  As battery technology and cellular technology evolve towards each other, we wouldn’t rule it out…


Written by Richard Gledhill, Senior Software Skill Leader