Human-body Temperature to E-ink Display (Part 2)

This is the continuation of an older project that went through the basic design of a temperature sensor program that displays the current air-temperature onto an e-ink display. If you haven't already, I would advise you to go back and check it out.

Part 2 focuses on power calculations and savings. As mentioned in Part 1, if this project is going to transition into a wearable, I need to make sure that I am efficient in my battery management. I want to run the entire device from a 3V, 320mAH coin-cell battery for an extended period of time. In order to achieve reasonable battery life, I have to implement some built-in power saving techniques.

Power Measurements

In order to measure the power consumption of each component, I decided to use a current sense amplifier (CSA) with high gain. I found that the MAX9922 Evaluation Kit would work be perfect for this application. I replaced the sense-resistor from 0.1 ohms to 1 ohm. If you are not familiar with current sense amplifiers, the basic concept is that a voltage drop across this sense resistor will be multiplied by the gain (250 in this case) and then the amplified output can be measured. By increasing the sense resistor, I am essentially shrinking the overall range of this amplifier, while increasing the output's precision. The maximum current I can measure is only 11 mA, instead of 110 mA with the 0.1 ohm resistor. The precision increases dramatically though, because now a change of 40 micro amps will result in a voltage gain of 10mV as opposed to 1 mV. Since I know the micro will only pull about 8 mA at its maximum, I want to be as precise as possible.

Since we are measuring the voltage change, we can hook the CSA's output to an oscilloscope and view the current draw patterns, not just instantaneous values like on a DMM. This will allow us to detect patterns for the current consumption, and really visualize these power saving techniques.

It is worth mentioning that I left my measurements in mA. Since I know the current and the voltage running on each component, I can easily calculate power through P = I * V. The following sections go through each component and show the current consumption trends before and after the code optimization. Final (quantitative) results can be found at the bottom of this article.

Screen Enable

The first of these techniques is disabling the electronic ink's on-board chip when it is not in use. The chip itself is extremely useful in transitioning the screen, but it also comes with some extra features that I do not wish to use. One of these features is an LDO that outputs to the "3V3" pin. I have no use for a regulated 3.3V output, so I want to make sure that is inactive for as long as possible.

There is also an on-board SRAM module, which I choose not to use. This SRAM loses all of its memory as soon as the chip's enable pin goes low, and it consumes quite a bit of current when in active mode. I found that the MAX32660 has plenty of memory to hold multiple complete screens, so there is no need for the extra memory on the screen module.

With no code modifications, the current consumption follows this pattern:

There is a large spike as the screen transitions, but relatively low consumption during stationary periods. In order to disable the chip and set the screen into sleep mode, set the enable pin ("EN") low when the screen is not in use.

You have to be a little careful here, because the screen is actually still transitioning after the "updateScreen();" command is sent. I built in a delay for this function before I disabled the enable, to make sure that the screen finished its transition before cutting off power. With the enable set low in between screen transitions, the new current consumption trend looks like:

By disabling the enable in between transitions, the stationary current consumption goes down noticeably. Since the SRAM is not being used, and the screen is not being updated during the down-period, there are no consequences other than current savings. You can easily see the point when the enable is set back to active, and the screen begins its transition.

Temperature Sensor One-Shot

The MAX30205 human-body temperature sensor has a built-in low power mode. Instead of making continuous temperature measurements, I can send a one-shot signal. This signal will tell the sensor to record one temperature reading, store it in the temperature registers, and then go back to low-power mode. I can send this signal right before I need to transition the screen, and keep the sensor in low-power mode for as long as possible.

Without utilizing the one-shot functionality, my current consumption looks like:

The sensor is always active, and continuously measures the temperature, regardless of whether the microcontroller reads it or not. Just by making the quick change to using this one-shot method, my new consumption pattern changes to:

As you can clearly see, the average current consumption goes down drastically. Each small spike represents a temperature reading. There is a long period in which we do not want to read temperature, so there is no reason to continually make new measurements.

Microcontroller Deep Sleep

The last, and most beneficial, technique is the deep-sleep capabilities of the MAX32660 microcontroller. During deep-sleep, the MAX32660 turns off all non-essential components. There is a great video discussing the MAX32660 features (19:10 - 21:50). The only components left active are the specified memory cells, the real time clock and wake up timer, as well as the power sequencing logic. All of the other components are powered off, and the micro is essentially dormant.

In this project, I only need the real time clock and wake up timer, as well as the memory to stay active. That way, I can wake up the system after a pre-determined time, and all of my screen data will be held in memory.

Without the deep-sleep enabled, I observed this current consumption characteristic:

The controller is always on, and although it is ready to read from the sensor and update the screen, it is only updating every 10 seconds. By enabling the deep-sleep capabilities, and shutting down all unnecessary components, the new characteristic looks like this:

The savings are clearly shown in the controller's duty cycle. When there are no measurements being made, and the screen is not being updated, the microncontroller should be in the lowest power-state possible. The sleep period can be configured easily to be as long or as short the user needs, and can also also be enabled with a GPIO signal as opposed to the RTC.

Final Results

When measuring the current consumption of each component, I decided to take the average current consumption for each cycle. Using that information, I can deduct how long a battery should last based on the time in between screen updates. The longer the wait time, the more power savings. The consumption results are shown below:

I then took these results and related the values to a 3V, 320 mAH coin-cell battery. The table is technically still not complete, because I need to implement the power management system to power each component, but the results give a deeper insight to how much savings we can achieve.

Possible Applications & Future Work

While the system is not completely finished, the low-power features can be applied to virtually any other projects. Any application that does not need constant calculations or temperature readings can save power by placing the microcontroller into deep-sleep mode.

When designing the project, I had a neonatal temperature sensor in mind. Monitoring a baby's temperature is important, however, it does not necessarily need to be continuous. Most of the modern watches and other wearables that measure body temperature today measure every few seconds, and continuously log data. This can be useful to the user who may see a large fluctuation in temperature in a short period of time, such as going outside on a cold day without a jacket, or working out. In the case of a baby's temperature, however, their environment will not change drastically. A child's parent or guardian will most likely take proper measures to ensure the infant is in appropriate clothing. In this application, temperature could most likely be measured every 5 minutes, which will catch any increase in temperature from sickness or prolonged exposure to heat or cold, while still maintaining a reasonable battery life.

The logical next step in this project would be to remove the e-ink display, and replace it with some form of wireless communication (most likely bluetooth) so that a parent or guardian can be alerted if there is a large temperature fluctuation. This modification would also make the device smaller, which is always desirable when it comes to wearables.

Other possible applications could be for a weather sensor that takes periodic measurements. It could be used for any delayed start applications if there is long setup time, or the system is difficult to access once it is setup. With no loss of functionality for periodic applications, it makes a great deal of sense to place the controller into deep-sleep mode.

These are just a few ideas for applications, and there are obviously many more use-cases that I have not mentioned. I hope you enjoyed the articles, and you got some new creative uses for these awesome features. Happy hacking!