The post MOSFET Power Loss Calculator appeared first on DMC, Inc..

Another way Espressif is improving their Bluetooth capabilities is by porting a new BLE-only stack called NimBLE into their ESP-IDF. ESP-IDF is Espressif’s software development kit (SDK) for the ESP32. Previously, the only option for Bluetooth on the ESP was BlueDroid, which implemented classic Bluetooth and Bluetooth LE. BlueDroid is large in terms of both code size and runtime memory—even if the application only uses Bluetooth LE. I recently implemented a GATT server using NimBLE on the ESP32 and in this blog, I’ll share some of the things I learned.

NimBLE Functionalities 

NimBLE is the BLE stack used for Mynewt OS, a cross-platform OS targeted at IoT devices. Mynewt contains a variety of lower-level functions and structures that are used across their higher-level communication protocol stacks (NimBLE included). Espressif therefore had to port over some of these lower-level functions and structures along with the NimBLE stack, such as the ble_hs_mbuf_to_flat() function.

Data in NimBLE is passed around via memory buffers named mbufs. Mbufs are a linked list containing data needed for any type of packet in Mynewt OS. Data coming to my application from the NimBLE stack would be in an mbuf, and the data I want to send to the NimBLE stack needed to be in an mbuf. There are a few functions ported into ESP-IDF to encode or decode mbufs to a Uint8Array, but the ones I primarily used were:

ble_hs_mbuf_to_flat()

ble_hs_mbuf_from_flat()

I used these when I needed to create an mbuf to be passed into NimBLE, or when I needed to access the raw data from an mbuf passed to my application from NimBLE.

Customization

With NimBLE, creating custom services and characteristics is surprisingly easy. For background, all BLE services and characteristics have universally unique identifiers (UUIDs). Some generic UUIDs are reserved by the Bluetooth SIG and should only be used by specific metrics. For example, the device name should always be at UUID 00002A00-0000-1000-8000-00805F9B34FB. Some applications require data to be sent that does not fall into any of these generic UUIDs, and therefore require a custom service or characteristic. Doing so is as easy as passing a ble_gatt_svc_def structure to the NimBLE stack. Part of the ble_gatt_svc_def structure requires a user callback. This user callback will be called to handle BLE events like writes or reads of any characteristic. I found this easy to set up and clean if you need to expand and customize BLE services or characteristics.

You can check out some examples of the NimBLE port inside ESP-IDF. There are examples showing GATT servers/clients, and one for creating a BLE mesh. I hope this can help in creating your next BLE project with the ESP32!

Read more about DMC’s embedded development and programming expertise and contact us to get started on your next project. 
 

The post Creating a GATT Server With ESP-IDF’s Latest Bluetooth LE Stack: NimBLE appeared first on DMC, Inc..

A Chip That Packs a Punch

The nRF9160 is a system-in-Package (SiP) that includes an LTE modem with an Arm Cortex-M33 processor for user applications. The modem can support either LTE-M or NB-IoT, but it can also be updated dependent on the application. The processor has 1MB of flash, 256 KB of RAM, and 32 GPIO. The SiP also has a built-in GPS receiver. I think one of the most impressive things about this chip is that its only 16mm X 10mm X 1mm. It’s tiny, but it really packs a punch! I couldn’t wait to get my hands on this development kit.

The nRF9160 Development Kit

Development Environment

Nordic’s documentation for setting up the development environment made it easy to get to the point where I could flash sample programs. The desktop app, called nRF Connect for Desktop, is their suite where they house their apps for nRF devices. The app called Getting Started Assistant walked me through setting up their toolchain, SDK, and development environment. 

nRF Connect for Desktop application

The IDE of choice for the nRF modules is SEGGER Embedded Studio (SES). Nordic has their own edition of SES that is used to open their nRF Connect SDK Projects. Installing this edition of SES is covered in the Getting Started Assistant application. You can open one of their SDK projects through File -> Open nRF Connect SDK Project… This will autogenerate some files necessary to open your project through SES, as well as create some configuration files. 

Their samples are combinations of solutions that consist of smaller projects that compile to C libraries. You can configure what projects are included in your solution by selecting Project -> Configure nRF Connect SDK Project. This menu is also used to enable the options of Zephyr, the RTOS used with their SDK. This menu then updates a configuration file for Zephyr and other projects in your build directory. The initial values of these configuration files are set through the prj.conf file in your project folder. 

nRF Connect SDK configuration menu

Create an Application

To begin creating your own application, you’ll probably want to start with one of the sample projects. You can use the project named libapp.a to store your application files. You can open your applications CMakeList by right-clicking your project and choosing Open CMakeLists.txt in Editor. This lets you choose all include directories and source files needed by your application. When you are ready to test, you can go to Build -> Build and Run or Build -> Build and Debug. 

I hope this helps you have as much fun creating user applications with this chip as I did! One thing to note is that, since this chip is still fairly new, there are some kinks to be worked out in the SDK. Luckily, Nordic has been very responsive to issues in their forums and are continuously releasing bug fixes and features to their SDK. Stay tuned for the some of the amazing applications that will come out of this chip!

Learn more about DMC's embedded development expertise.

The post Unveiling the Power of the Nordic nRF9160 SiP appeared first on DMC, Inc..

These new networks are the future of IoT. However, as this writing, many of these networks still have a lot of kinks to work out. Cellular module vendors are rapidly developing and lunching modules for these networks. These modules are all new and so is the network, so challenges launching a product on one of these networks are to be expected.

What to Do

1. Know your Module Vendor
When selecting a cellular module vendor make sure they have a good support network. With new network deployments, there will be a LOT of updates happening in the background. The cell providers will be making adjustments and so will the module vendors. It’s important to understand the level of support you will get from the module vendor if your device happens to uncover a bug or incompatibility between the module and the network, or worse, between the module and a specific cell tower.

  
ublox SARA-R4 series, SIMCom SIM7000X, and Nordic nRF9160

2. Understand the Module Power Requirements
Most of these cellular module vendors provide a lot of marketing material about the low power requirements of their modules. These low power modules promise battery-powered cellular connectivity with years of battery life. It’s true, these modules have very low average currents while operating. The important thing to understand is that they also have relatively high peak current demands, which means you need to select your battery and design your power circuitry carefully. You won’t see any cellular IoT devices running on coin cells anytime soon.

Lithium Thionyl Chloride is popular cell chemistry for super long-life Wi-Fi or Bluetooth IoT devices, but most of the batteries made with this chemistry fail to provide the high peak current required by the cellular modules. Spiral wound Lithium Thionyl Chloride batteries use the same chemistry but provide higher peak current (by increasing the electrode surface area), however these batteries may still not meet the peak current demands.

Spiral wound Lithium Thionyl Chloride batteries

Instead, you may need to consider hybrid batteries like these from Xeno Energy which consist of a Lithium Thionyl Chloride cell and a parallel supercapacitor. The supercapacitor can provide high peak currents while exhibiting very low leakage.  Although the cost is higher for this battery topology, it provides the performance needed for long life cellular IoT devices. 

Hybrid battery

3. Test Your Module in a Wide Variety of Conditions
These modules contain closed-source vendor-supplied firmware. The operation of the module may not be fully documented. Part of your testing protocol should include adding attenuators to the cellular antenna (to simulate poor cellular reception) and observing how the module functions with reduced signal strength.

Modules draw significantly more average current when operating at this reduced signal level. Not knowing this ahead of time can be problematic, especially if your product advertises a minimum battery life expectancy. The actual battery life will largely depend on your connection to the cellular network. The total energy required to transmit a message from your device to the backend server can vary significantly depending on your signal strength and the number of retries required. 

Add attenuators to the cellular antenna to test at a reduced signal strength

4. Expect and Plan Time for Network Issues
These networks are going to be great, but until they are fully stable your product launch is going to go slower than you hoped. Add extra time in your launch schedule to account for these unknowns and extend your engineering budget to account for the time required to work through these issues. 

Keep in mind that different cell towers may contain different vendor hardware. Each of these vendors may be interpreting the CAT-M1/LTE-M specification differently and you may encounter situations where the firmware in your device performs better on some towers than others. If you encounter issues like this, move your device to a different location to see if it picks up a different tower and starts working. Eventually, these issues will be worked out by the carriers and module providers, but you should initially be prepared to work through these situations during your testing and product rollout.           

The firmware in your device may perform better on some cell towers than others due to hardware differences

Learn more about DMC’s IoT solutions. 

The post 4 Tips for Launching a Product on Emerging Cellular Networks appeared first on DMC, Inc..

Espressif developed the Espressif Internet Development Framework (ESP-IDF) as their SDK for developing with the ESP32. There is a very good guide to getting their toolchain and SDK setup on Espressif’s website. The ESP-IDF has components for almost anything you’d like to do with the ESP32. There are drivers for GPIO, Wi-Fi, IoT communication standards, and so much more. Espressif recently began modifying their SDK for the ESP8266 to be similar to the ESP-IDF.

The ESP-IDF uses a menuconfig to enable sections of the ESP-IDF API, configure peripherals, etc. This is nice for finding all the components that are available through ESP-IDF and their options. Some of these options can also be changed on the fly through API calls, but I’d argue that I’d rather have these configured before runtime.

The ESP32 and ESP8266 are both great modules to work with, but each of them has their quirks. Below, I’ve compiled a list of tips for getting started with the Espressif modules:

1. The sdkconfig file saves all the changes made in the menuconfig
   • The menuconfig saves all configurations in a file called sdkconfig. Sdkconfig shows all options available to be set through menuconfig. If you are searching for a specific option, it can be quicker to ctrl = f through sdkconfig and backtrack to find the location through menuconfig.
   • Menuconfig does read and write from sdkconfig, so changes you make in sdkconfig will be reflected in menuconfig. If you have a lot of trouble finding a parameter through menuconfig, this can be a backup option (though it is not recommended by Espressif so be warned!)
2. Run make with parallel jobs
   • Building a project using ESP-IDF can take a while because they do not automatically run parallel jobs. This causes long compile times when rebuilding from scratch. Since every change in menuconfig requires a complete rebuild, this can start to eat a significant amount of development time.
   • To build with parallel jobs, you need to add the -j option to your make commands. A command of make -j4 will run make with 4 parallel jobs. Espressif recommends running with option -j(number of CPUs +1)
3. Not all GPIO pins have full functionality
   • The ESP32 has 4 pins that are labeled as input only. These pins are GPIO 34, 35, 36, and 39.
   • The ESP32 also has 18 ADC pins, however, 10 of these cannot be used while Wi-Fi is being used! The pins that cannot be used as ADC with Wi-Fi are GPIO 0, 2, 4, 12, 13, 14, 15, 25, 26, 27.
   • Since the ESP32 and ESP8266 have external flash, the modules have a SPI interface. On some development boards, these pins are exposed, so it is recommended to not use these pins in your projects. On both boards, these pins are GPIO 6-11.
4. Default FreeRTOS tick is 10ms
   • The default tick rate for FreeRTOS in ESP-IDF is 100. This can be updated up to 1000 with no issues, but anymore than that I’ve heard is unreliable. If you need timing more precise than 1ms, you may need to implement RTC timers with interrupts.
5. OTA updates for ESP32
   • ESP-IDF gives the user control over how the external flash is utilized through a partition table. Setting up the flash partitions correctly is essential for OTA updates. OTA updates require at least 3 entries, otadata, ota_0, and ota_1.

     

   • On first boot, the bootloader jumps to ota_0 partition (if the factory partition is not specified) and begin running the firmware. When the firmware activates a firmware update, it then updates the ota_1 partition. The device then runs the firmware in ota_1 and updates otadata to mark ota_1 as the active partition, so that on bootup, ota_1 is run.
   • One of the cool features included in this method of updating firmware is that it allows for firmware verification on every update. This way, if you push code to your device that doesn’t pass your user-defined tests, the device can roll back to the previous ota partition and continue running. This is a nice feature to be rolled into the ESP-IDF as it can save.
6. Add more RAM
   • Both the ESP32 and ESP8266 support adding additional RAM. Espressif has even developed an SRAM device for the ESP32, called the ESP-PSRAM32. The external RAM is connected in parallel with the external flash chip, allowing the new RAM to be accessed the same as internal RAM.
   • Espressif also has the ESP32-WROVER module, which contains an external 4MB SPI Flash and 8MB external PSRAM, in case you don’t want to add these yourself.
7. Security
   • Both modules support signed firmware updates. This can help guarantee that any code updates are only applied by you (or anyone who gets a hold of your private key). Additionally, the ESP32 supports secure boot and flash encryption. Secure boot is another method of ensuring only your code can run on your device. Flash encryption protects your firmware from being accessible to anyone with physical access to your device.
8. Low-Power Mode
   • Both the ESP8266 and ESP32 can enter either light sleep or deep sleep.
   • In light sleep, clock pulses are powered off and RAM is retained. When exiting light sleep, and the program continues from wherever light sleep mode was entered from. There is also the ability to enable automatic light sleep, which can retain Wi-Fi connection by cycling between active mode and light sleep mode.
   • In deep sleep, the CPU and memory are powered off. The RTC module is still powered in this mode, which is responsible for periodic wakeups and can store a small amount of memory. The ESP32 also has an ultra-low power processor that can be enabled in deep sleep!

Contact Us Today to Speak With Our Embedded Development Solutions Experts and We Can Get Started on Your Next Project!

The post Getting Started with the ESP32 & ESP8266: 8 Tips and Tricks appeared first on DMC, Inc..

Projects using MicroPython and JerryScript attempt to provide a means to write Python and JavaScript code and provide frameworks for “compiling” and running scripts on a variety of bare-metal targets. However, these types of frameworks have some inherent drawbacks. JavaScript and Python are both interpreted languages with garbage collection and weak typing. Running these languages requires relying on a run time or more complex cross compiler.

A New Language for Embedded Systems

More recently, Rust has emerged as an appealing language for applications that require memory safety and efficiency. Both of these features are often critical for embedded devices. Manual memory management often creates bugs which are hard to isolate and are not always easily remedied due to the resource constraints of embedded devices.

Additionally, C/C++, even given all of its faults, remains a highly efficient language due to the control it provides developers and because it can use many target-specific optimizations at compile time. C/C++ sets a high benchmark for speed that is difficult for interpreted languages to match.

Rust, fortunately, solves both problems in ways that are particularly well suited to microcontrollers. Rust does not require any run-time engine for garbage collection or memory management. Rust instead chooses to enforce memory safety at compile time. Furthermore, because Rust compiles to LLVM, target optimizations rivaling those achievable with C/C++ are possible. Recently, the Rust core team has made support for new target architectures a priority, and there are already many open source projects aimed at expanding support for embedded devices in Rust.

Nucleo PCB Running on Rust

Getting Started with Rust

The Embedded Rust Book provides many details regarding getting started with Rust on embedded devices. For this blog, I’ll highlight a few key components that make up the Rust embedded landscape. Specifically, I’ll be discussing support for ARM Cortex M based microcontrollers.

The Rust ecosystem is built on an extensive library of packages called “Crates.” A few specific crates, “cortex-m” and “cortex-m-rt”, make up the core support for ARM targets. These packages provide the bare minimum of code to get a basic program up and running. It allows access and control of the core ARM registers.

Below is an example of setting up the systick peripheral taken from the Rust Embedded Book.

use cortex_m::peripheral::{syst, Peripherals};
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let mut systick = peripherals.SYST;
    systick.set_clock_source(syst::SystClkSource::Core);
    systick.set_reload(1_000);
    systick.clear_current();
    systick.enable_counter();
    while !systick.has_wrapped() {
        // Loop
    }

    loop {}
}

use cortex_m::peripheral::{syst, Peripherals};
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let mut systick = peripherals.SYST;
    systick.set_clock_source(syst::SystClkSource::Core);
    systick.set_reload(1_000);
    systick.clear_current();
    systick.enable_counter();
    while !systick.has_wrapped() {
        // Loop
    }

    loop {}
}

To implement something more interesting than a simple timer, we’ll need a Peripheral Access crate. These crates are typically specific to a vendor and family of microcontrollers. For example, the STM32F4 crate provides an API for accessing various peripherals such as GPIO, UART, and I2C for the STM32F4 family of devices.

Pulling in a Peripheral Access crate, we can build a program for toggling an LED:

fn main() -> ! {
    let mut peripherals = stm32f429::Peripherals::take().unwrap();

    //Enable gpio b clock
    let rcc = &peripherals.RCC;
    rcc.ahb1enr.write(|w| w.gpioben().bit(true));

    //set pin 14 to output
    let gpio = &peripherals.GPIOB;
    gpio.moder.write(|w| w.moder14().bits(1));

    //Turn on led
    gpio.odr.write(|w| w.odr14().set_bit());

    loop {

        delay(10000);
        if  gpio.odr.read().odr14().bit()
        {
            gpio.odr.write(|w| w.odr14().clear_bit());
        }
        else {
            gpio.odr.write(|w| w.odr14().set_bit());
        }
        
    }
}

fn delay(count: u32) {
     for _ in 0..count { cortex_m::asm::nop() }
}

fn main() -> ! {
    let mut peripherals = stm32f429::Peripherals::take().unwrap();

    //Enable gpio b clock
    let rcc = &peripherals.RCC;
    rcc.ahb1enr.write(|w| w.gpioben().bit(true));

    //set pin 14 to output
    let gpio = &peripherals.GPIOB;
    gpio.moder.write(|w| w.moder14().bits(1));

    //Turn on led
    gpio.odr.write(|w| w.odr14().set_bit());

    loop {

        delay(10000);
        if  gpio.odr.read().odr14().bit()
        {
            gpio.odr.write(|w| w.odr14().clear_bit());
        }
        else {
            gpio.odr.write(|w| w.odr14().set_bit());
        }
        
    }
}

fn delay(count: u32) {
     for _ in 0..count { cortex_m::asm::nop() }
}

Although Rust is an exciting new option for embedded development, it will take some time for it to supplant C/C++ as the standard. A lack of official support from major silicon vendors like ST, NXP, and Silicon Labs means that adding support for new microcontrollers can be a tedious process. Additionally, C/C++ frameworks like ARM’s mbed offer large, general purpose libraries and drivers that can be used across a variety of ARM targets with little to no modification.

Learn more about DMC’s Embedded Product Development Services and Embedded Systems Platforms expertise.

The post Oxidizing Bare Metal: Rust Programming for ARM Microcontrollers appeared first on DMC, Inc..

Schematic Library

From the Schematic Editor, select Design -> Make Schematic Library.

Altium will convert each component on your schematic into a library component and will use the Library Reference parameter to name each component. However, if you use part parameters to store information like part numbers, vendor links, etc. (which you should be!), Altium will flag components with the same Library Reference but different parameters. An example of this is shown below. Two of the capacitors in my schematic use the same symbol but have different part number fields ("different internal structure" in Altium-speak).

There's no need to have several different capacitor (or inductor, resistor, etc) symbols in your symbol library – you just need to make sure you edit/verify the component parameters when you add the component to your schematic. But you do that anyway, right?

If you select "Process only the first instance and ignore the rest" and then click "Remember the answer and don't ask again", it will only create one schematic symbol per Library Reference.

When finished, the new symbol library will be added to your project and opened in Altium. By default, the library filename is set to whatever your project file is named.

Footprint Library

To generate a footprint library, go to your PCB Editor and select Design -> Make PCB Library. As before, Altium will create a new library component for each footprint in your design and then open the library for your perusal when complete.

Library Trimming

This functionality is useful in a few other cases as well. The main case is useful for handing off the finalized design to a client or manufacturer. In large embedded projects, it's common to make changes to the component selection in order to drive cost down, improve functionality, decrease power consumption, etc. As a result, there will be extra library components hanging around. Using the procedures described above, you can create libraries that contain only the parts in your design, rather than manually searching for and deleting the extras.

Happy PCB designing!

Learn more about DMC's embedded development and programming services.

The post Recovering Missing Library Components in Altium Designer appeared first on DMC, Inc..

Active/Sleep Programming

One of the first steps DMC took to help improve battery life was to use an active/sleep architecture for running the program. In this design, the microcontroller and any other high-current devices are shut down/put to sleep when they are not needed. This inherently created a variable current draw for the device, but ended up being much more efficient than having the hardware idly chewing up current without accomplishing anything (idle operations).

This was accomplished with a microcontroller by using hardware interrupts to bring the microcontroller out of a sleep state to process new data or actions. Specifically, DMC used a TI MSP430 that sat in an ultra-low power state that was interrupted by a couple of conditions: a timer set to update the user display, a button action, or new data from an external chip. Once interrupted, the microcontroller did all the necessary calculations and then went back to sleep. The microcontroller was also limited in how often it could be awoken, even when being constantly interacted with, to guarantee a certain duty cycle of sleep vs. active. Using this in place of code that actively waited for those conditions reduced the microcontroller’s average current draw by orders of magnitude. 

DMC further increased battery life by optimizing the active/sleep timing and behavior for the customer’s exact application, increasing the battery life of an inactive device from 160 to 240 hours. This was done by running all communications in parallel with processing using interrupts, and by reducing the display update frequency while keeping the user experience intact. Both of these allowed the microcontroller to get to sleep quicker and stay asleep longer.

Clockspeed Adjustments

The next step DMC took was to optimize the clock speed at which the microcontroller was operating. Almost all microcontrollers have the ability to change their clock speed, and some even dynamically while running code. If running off of an external power source, it is typical to just run the device at the highest clock speed, and with a sleep/active architecture, some may argue that the active clock speed is not important since a faster clock speed allows you to run your calculations quicker and get back to a sleep state.

However, remembering the conditions from the first post, a higher current draw has a bigger impact than a low current draw, even if they average to be the same. Therefore, DMC optimized the clock so that it only ran as fast as necessary to complete our code in the allotted amount of time. In this application, DMC used an oscilloscope to time the processing of certain functions under specific conditions, allowing the clock speed to be changed for each case while still maintaining responsiveness and accuracy.

In the image above, you can see the change in current draw when the clock speed in our application was reduced. In both cases, the amount of computation is the same, as is the average current draw over time, but the higher clock rate has a much greater peak current draw. The results of decreasing this peak were an increase in idle battery life from 260 to 300 hours and dynamic life from 150 to 180 hours.

Capacitor smoothing

In addition to reducing the clock speed when actively processing data, DMC also added capacitance to the battery supply to further reduce the peak current draws seen by the battery. By placing a fairly large capacitor in parallel with the battery, the capacitor can act as a power source when high currents are required. The result is that the battery does not have to supply all of this current, and the capacitor can be recharged during periods of low current draw. In the end, the battery sees a much smoother current profile and gets closer to our ideal situation of constant low current draw.

In the image below, the addition of a 100 mfd capacitor dramatically reduced the peak current draw seen by the battery. This resulted in an increase in dynamic battery life from 180 to 210 hours.

Conclusion

By leveraging DMC’s knowledge in embedded software and hardware development, DMC was able to improve the customer’s battery life by almost 90% when inactive and 40% when active. This, in the end, will provide a better selling point for the device and reduce battery costs and downtime for the end user.

The post Improving Battery Life in Low Power Embedded Applications Part 2: Case Study appeared first on DMC, Inc..

The Simple Case
When discussing battery life and power consumption, average current draw is king. If certain electronics in a device draw a large amount of current, battery life can only be improved to a certain extent. There is no way to magically get more energy. The best case scenario is that a device’s battery life will follow this formula (Battery Life = Battery Capacity / Average Current Draw). This looks something like Battery Life = 300mAh / 1.2 mA  = 250 hours. However, this assumes that the current draw is around the same level that the battery was rated for and that the current draw is constant. In almost all situations, this will not be the case.

In an ideal world this formula would always hold true, however the focus of this article will be all the cases in which this isn’t true and how to get as close as we can to this ideal state. 

Battery Ratings and Battery Life Calculations
Any battery can be thought of as a voltage source in line with a resistor. This resistor is referred to as the internal resistance of the battery. At the beginning of its life, a battery has a small internal resistance and can supply large amounts of current with little drop in voltage. However, as the battery is depleted, this internal resistance increases to the point where drawing current from the battery reduces its voltage below a devices operating voltage. This means the battery is unable to power the device and is considered “dead”. The internal resistance of a battery tends to stay relatively constant for the beginning of its life and then increases rapidly. Therefore, measuring the behavior of a battery’s internal resistance over time is fundamental to the study a battery’s life or “relative capacity”.

When looking at a typical datasheet for a battery, there will some key points of information.  The first will simply be the voltage and rated capacity of the battery. This is typically how people will reference the battery (e.g. 3 .0V 240mAh). It is important to note that this capacity should also have a resistance and end of life voltage listed with it to specify the conditions it was tested under (e.g. 240 mAh to 2.0 volts, Rated at 15K ohms at 21°C). A typical drain current may also be used in place of the resistance (0.19mA). Additionally, there may be one or more charts detailing the battery test showing a plot of battery voltage versus time under specific draw down conditions.

If there was a device with the same current draw characteristics as one of these tests, calculating its battery life would be as simple as looking at which point on the graph the voltage drops below the devices minimum operating voltage.

Example: 

Using the battery sheet referenced earlier if we had a CR2032 battery powering a device with a constant resistance of 15K ohms and a minimum operating voltage of 2.4 V, it would have a battery life of 1200 hours.

In an ideal world one would know the exact current profile of a device and there would be a draw down graph for that profile and the devices battery. However, both are unlikely for anything beyond a very simple device. Therefore, it is important to be able to estimate battery life based on a standard graph or capacity rating, as well as know how different conditions affect battery life.

Effects on the Relative Capacity of a Battery
We now know that fundamental to the calculation of a device’s battery life is the change in the battery’s internal resistance over time. So in order for us to estimate the device’s battery life or the relative capacity of our battery, we need to know how different current draws affect our batteries internal resistance.

We will start with our best case scenario and go from there. In the best case we are drawing a very small constant current similar to the conditions the battery is rated under.  Under these conditions we will get the entire capacity rated by the battery. So now let’s change some things.

Operating Voltage
This is the simplest case. If a device operates at a different minimum voltage than the standard rating we simply shift our end point along the rating curve (Lower voltage = longer life, higher voltage = shorter life). It’s also important to remember the quick decay in the battery voltage curve.  o a change between 2V end of life and 2.1V end of life on a 3V battery will have very little effect on battery life since the resistance at this point is drastically increasing. However, if a device has an end of life voltage of 2.9 V on a 3V battery its battery life will be much shorter since it is not taking advantage of a large portion of the battery curve.

Higher Current
In this case the device is still drawing a constant current, but at a different level from the rated conditions. One might think that there is a purely linear relationship between current draw and battery life (e.g. Life = capacity/current), but this is NOT the case. The higher the current draw from the battery the quicker the internal resistance increases. So a 300mAh battery supplying 1 mA may last 300 hours, but when supplying 5mA will only last 50 hours which is less than expected (300/5 = 60 hours).

Variable Current
The last case would be if a device did not draw a constant current, but rather changed based on its active state. For example it may draw 9 mA for 1 second and then 1mA for 9 seconds. In this case, the average current draw will end up being 2mA over any extended period of time. However, this device will have a shorter battery life than a device drawing a constant 2mA. This is because the short period of time during which there is a high current (9mA) has a lasting impact on the resistance of the battery.

In any complex design it is likely for all of these conditions to apply. It is important to note that each has a compound effect on the final battery life and needs to be considered individually. So if a higher voltage decreases your batteries relative capacity by 5%, and a different current draw decreases it by 10%, and a variable current decreases it by 20%, our resulting device will only have a battery capacity equal to (.95x.9x.8 = .68) 68% of the rated capacity.

Summary
In summary, batteries are fairly complex things and behave differently in all sorts of conditions. Therefore, calculating battery life is not a matter of simply dividing the battery capacity by a devices average current draw. In this article we talked generally about how batteries are rated and the effects of different conditions on the battery. If you’re interested, there are tons of other great resources and studies on this topic that can be found through a simple Google search. Specifically DMC used the two studies below on the CR2032 coin cell detailing behavior under high pulse draw conditions.

Coin cells and peak current draw

High pulse drain impact on CR2032 coin cell battery capacity

In part 2 we will take a look at how this all applies to a specific device.

Learn more about DMC’s embedded development and embedded programming services.

The post Improving Battery Life in Low Power Embedded Applications, Part 1: Basics appeared first on DMC, Inc..