Sparky Battery Emulator

The Need

In 2014, I was with the team writing the PMIC drivers for a mobile phone. The developers were complaining that it was very tedious to test the phone’s charging and discharging because a full charge/discharge cycle took so long. Worse, there were several times that driver code was released only to find that charging was broken during field testing.

The developers had the phones hooked up to bench power supplies, but “charging” a power supply would just cause the voltage to jump up and the phone indicate that the battery was 100% charged.

There were also corner cases to be simulated that needed firmware to adjust the charging. For example, if the battery was too cold, the phone must charge at half the normal rate, or not at all if it was very cold, or if the battery was between 2.5 V and 3.1 V it must trickle charge it up 3.1 V before fast charging. But a battery below 2.5 V is already damaged and must not be charged at all for safety reasons.

The Solution: Emulate the Battery

Sparky Sparky Mobile Phone Battery Emulator

I knew this required a two-quadrant power supply that not only sources a voltage and outputs current but can also sink current and force a voltage level when an external source (a mobile phone) tries to “charge” it.

A Two-Quandrant Buck Regulator

After reviewing many possible designs (power op-amp, op-amp with a class-AB output stage, buck regulator with a tracking current sink, etc), I found Linear Tech (now Analog) offered a complete module (LTM8052) which even had the inductor built in. This was the heart of “Sparky”, a complete battery emulator for mobile phones.

Sparky back Sparky Battery Emulator circuitry

I paired the LTM8052 two-quadrant buck regulator with a PIC MCU to give it a USB interface and intelligence. I wrote the firmware in C using Microchip’s MPLAB IDE and HAL drivers.

When sinking current, the LTM8052 forces the output to the programmed voltage and sinks current by dumping it back into its input.

On the input side you would normally add a zener diode to sink the charging current. Instead, I used a MOSFET in a voltage follower configuration to emulate a zener diode. A MOSFET is so much easier to bolt to a heatsink. Quite a bit of heat had to be dissipated during phone charging.

Battery Emulation Features

  • Charging and discharging
    • the voltage slowly rises and falls as it’s charged and discharged just like the original battery
    • uses a Voltage vs. SoC (state of charge) lookup table derived from characterized parameters of the original battery
  • Emulates battery ESR (effective series resistance)
    • output voltage dips and rises depending on charge/discharge current due to emulated series resistance
    • programmable ESR value including open cell condition
    • can adjust ESR based on SoC and temperature lookup tables (future FW feature)
  • Emulates battery thermistor
    • programmable digital potentiometer to set any sensor temperature
    • also emulates short and open thermistor
  • Interface
    • Text LCD display shows real time voltage, current, emulated state-of-charge, and emulated temperature
    • Buttons for live settings changes
    • USB interface for control and data logging

Because of these features, to the mobile, the emulator looked and acted like the original battery. To the developer, he can now simulate any battery condition and verify that the PMIC and firmware works correctly in all corner conditions and fault cases..

In Actual Use

There were two use cases for Sparky. The obvious one was on each firmware and software developers desk if they were working on anything related to charging, discharging and gauging the state of charge of mobile phones.

The second use case was in automated Regression Testing. The company had banks of phones of every model that ran automated testing. Every firmware release candidate had to first pass this rigorous automated regression testing before going to human testers.

Rack Regression Tester Rack with Sparky Battery Emulator

With Sparky added to the testing bank, phone charging became part of this automated testing. There were no more software releases with broken charging or gauging after that.