P2 charge indicator

Hi all,

I have an application running on the photon 2. Part of this application is some health monitoring on the system and reading the status of the CHG input.

I am using the snippet from the datasheet for this.

bool charging = digitalRead(CHG);

On the Photon 2, the CHG digital input is HIGH (1) when charging and LOW (0) when not charging.

However this CHG input doesn't appear to reflect what the CHG LED on the board is showing.
I have written some test code to verify this.

void setup() {
    pinMode(CHG, INPUT_PULLUP);
    pinMode (D7, OUTPUT); digitalWrite (D7, LOW);

void loop() {
    while (1) {
        digitalWrite (D7, digitalRead(CHG));    

I am connecting and disconnecting USB power to start/stop charging and this is verified by the CHG LED turning on/off. However D7 remains off.

What am I missing?
I have not been able to find a schematic for the photon 2 board, or any information regarding the battery charger on the device.
Any ideas?

Thanks, Ben.

You need to use INPUT not INPUT_PULLUP. The input on CHG/S5 is already connected to a voltage divider so the extra pull will overwhelm the actual input.

Same problem for me ! CHG is always Low even if the battery is charging.

Using INPUT vs INPUT_PULLUP don't change anything.

I'm pretty sure the docs on the state of CHG are backwards. This is the code I used and by plugging in the battery and unplugging the battery the blue D7 LED matched the orange charge LED once I added the ! from digitalRead().

#include "Particle.h"

SerialLogHandler logHandler;

void setup() {
    pinMode(CHG, INPUT);
    pinMode (D7, OUTPUT); 
    digitalWrite (D7, LOW);

void loop() {
    digitalWrite (D7, !digitalRead(CHG));    

However when I unplugged the USB power but left the battery connected, I also get the same behavior as you do. The yellow charge LED goes off, but the blue D7 LED stays on. I'm not sure why.

1 Like

Thanks for the feedback. I'll try again after work.

The docs do say to use INPUT_PULLUPS.

It would be nice if particle released the schematics for the Photon 2. As an EE, I find it easier to code if I understand the circuit. I understand keeping P2 closed shop, but Photon 2 is just a dev board.


You get the same result but reversed because you used a negation on the reading of CHG! CHG is then always high.

In principle, you plug and unplug the USB cable and not the battery.

I'm working on migrating a project with the Photon and the Sparkfun charging module and I absolutely need to be able to get the state of charge and the remaining capacity of the battery.

I created an ticket for engineering to examine the issue.

1 Like

Any news about the issue ?

I haven't heard anything.

It is still being investigated. A workaround for the issue has not been found yet.

1 Like


Still no return from engineering ?

This is being looked with additional scrutiny this week, I should have an update for you in about a week.

1 Like

Sorry for insisting but without a solution from you, I am stuck in the progress of my project. Were you able to resolve the problem?

Hi sorry for the missing update -- this is still with the team, I've requested an update and will provide information within the day.

1 Like

Hi there, I'm sorry but I don't have good news -- there isn't a possible software fix that will resolve this. I'm hopping into a call about any possible workarounds tomorrow, but I don't believe there's any easy fix in play. I will make a post here tomorrow with my findings.

1 Like

The only workaround that might be possible for your application in the near-term is to add an external fuel gauge; this would be our suggestion here. There is a hardware issue around the charge light that we can reproduce, but we cannot prioritize this fix at the moment. We will follow the reporting of this issue and track further requests against prioritization.

Which external fuel gauge do you recommend? And what is the price? In your estimation, what is the likely time frame for a solution/resolution of this problem?

@rickkas7 -- any specific fuel gauge you mind recommend here?

@dj_guigui -- there will be no software rectification here, if there will be a fix, it will be hardware only and involve some revision of the board in the future. It is unlikely for this to occur on a timescale outside of several months if not longer.

Adding a fuel gauge chip wouldn't be exactly the same, because it would only indicate the relative charge of the battery, not whether it was actually charging at that moment. There are two different kinds:

One kind attaches in series with the battery and monitors the flow of current in and out. This would be more difficult to implement because you'd need your own LiPo connector.

The other kind is a model fuel gauge which only attaches in parallel and monitors the voltage, comparing to a model of how a LiPo battery normally performs, so it's more accurate than just monitoring the voltage. It could be implemented by connecting to Li+ and GND, and it will require a control connection, typically by I2C or SPI to the MCU.

Particle devices with a PMIC like the Boron include the MAX17043 fuel gauge, but there are other models like the MAX17048 that work similarly but may be easier to obtain.

Ok, this is really bad news. Is it possible to correct the problem by unsoldering the LED or any other manual intervention on the circuit?

If not, I have four orders in progress! Is it possible to cancel them?

The advertised features are therefore not covered and this makes the product really less attractive and the addition of an external fuel gauge represents a significant cost.