In my last post, we looked at the iPhone’s lithium-ion battery technology and chemistry to understand how to maximize lifetime. This time, we’ll look at the battery charging interface hardware. The iPhone’s input power regulation and battery charging is controlled by a Linear-Technology LTC 4066 USB Power Controller. This chip (highlighted in the red box below) performs the power routing from the USB port, to and from the battery, and to the device (source: tzywen).
This chip is somewhat programmable. Some input pins are provided to specify charging current, detect a wall adapter, and toggle high/low charging current. These pins have very weak pull-down resistors so the chip operates in “low current mode” unless some pull-up voltages are applied to these pins. It appears the USB data lines (D+ and D-) have enough idle voltage to pull-up HPWR (high power select) and WALL (wall adapter present). This engages “high current mode”, which I measured 830mA on my phone. If these pins are left unconnected, the LTC4066 defaults to “low current mode”, which I’ve been measuring at about 85mA with my iPhone. The LTC4066 datasheet specifies low current mode is 20% of high current mode, but my iPhone’s ratio is about 85mA t0 830mA (about 10%).
There is still a possibility of software-controlled charging, depending on how the LTC4066 is connected. The iPhone receives SOC information (“gas gauge”) from pin 19 and 24 (POL and Istat). These are analog signals and require an analog to digital converter (ADC). Binary signals are output by the ACPR (wall adapter present) and CHRG (charge status) pins. The iPhone probably reads all of these pins, along with a fifth measurement of directly reading the battery’s voltage with an ADC. I would love to find these registers and see the LTC4066 status real-time!
Charge current thresholds are set by the CLPROG (pin 22) and PROG (pin 23). These are supposed to be permanently tied to ground with a resistor, whose value “programs” the chip. For the CLPROG pin, smaller the resistor values result in larger input-to-output current limits. The minimum resistor is 2.1k, corresponding to 0.476A. It is possible the iPhone either measures voltage at these pins, or even actively alters the behavior by injecting voltage into one of these pins.
When the 5 Ohms resistor is inserted in the USB power path, input current and voltage drops when the USB line sags. This forces the CHRG pin to trigger because the charge current has dropped below a set threshold. The iPhone detects the CHRG pin status, drops the LTC4066 into low current mode, and displays a message:
Can custom charging be done with software? If the input and output registers were known, software could measure the battery voltage, current, and wall adapter status. Three cheers for open-source kernels and shame on Apple. When the desired battery condition is reached (i.e. 50% SOC), software could change from high current mode to low current mode. The software could include hysteresis, so that if the battery drops below 40% SOC, it switches back to high current mode again. Depending on which pins are connected in hardware, software could use a number of strategies, using any of the SUSP, HPWR, or CLDIS pins or the PROG/CLPROG pins if they are connected.
How much heat would be generated by toggling the LTC4066 into low-current mode? I measured 5.21V on my USB (+) power wire. The battery (at 50% SOC) is about 3.7V. This means the LTC4066 has to drop 1.5 Volts. Drawing 85mA (low current mode), this means the LTC4066 is burning 0.125 watts. This amount of heat can easily be dissipated by the part.
Until we have access to the LTC4066-related kernel registers, I am keeping my existing arrangement. Using a short USB extension cable, I snipped the red wire (USB power) and inserted 5 Ohms of resistance. This bumps the charge current down to “low mode” in the LTC4066, while keeping the data lines connected functioning. I’d love to directly control the LTC4066 low/high mode with software, and stop playing silly games with the USB cable hardware. Until either someone decompiles the kernel and creates a kernal variable list, or Apple decides to release some internal kernal information (pigs can fly), software battery charging control isn’t an option.