I’m using a Core (not a Photon) with the new Sparkfun Photon Battery Shield. It says this should be 100% compatible, and just have some differently labeled pins. I’m using a 2000mAh battery from Sparkfun that they list as compatible and recommended with the shield.
The shield allows me to charge the battery and power the core just fine, but the fuel gauge is giving me the same data, regardless of the state of the battery. Whether I use the stock example file or a slightly modified version that is publishing some events, it works as expected except that the Voltage is always reported as 5.118750 and the State of Charge is always reported as 255.996094. This is especially confusing as according to the docs, getSOC() is supposed to give a 0-100 value.
I haven’t tried this with my recently-arrived Photon yet to see if it is Core specific (will do that in a few) but in case this was a common issue I wanted to see if anyone else had encountered issues.
@patrickcentral, for a few samples, the voltage and soc look good then it suddenly switches to the exact same values you posted and stays there. So there is an issue here.
@peekay123 Yeah, I’ve been seeing basically the same - the only accurate reading I get is in the initial Setup run after the battery has been completely disconnected for 30 seconds to a minute. From that point forward, every check, whether in Setup or Loop, returns the same values, even if the core goes into deep sleep and comes back online (and thus executes Setup again.)
So, seems to be that first read after complete system shutdown or battery removal is good, and every one after that gives fixed values. So weird.
@bko I am using the SparkFun library, which abstracts out all the I2C interactions, but I can try and dive into that.
Similarly, I don’t know if the sleep mode would engage itself automatically, I’m definitely not doing so. I’ll also take a look at waking it up, or alternatively, seeing if it needs to take a rest to get a good reading, and I am making it an insomniac inadvertently.
Interesting trend I observed in more recent data logging:
In a test sketch, I have a Photon that is never going to sleep (because there’s a bug with it connecting to wifi after, grr) and every 5 minutes (millis + 300000) it publishes an event that IFTTT dumps into a google spreadsheet.
Going by the spreadsheet, the battery reported the 255.9960375 soc until it flatlined and died. I plugged it into a power source, and the first couple readings were actually different, believable figures, as it began charging! And with each reading the voltage rose, until it hit the 5.1187, at which point the SOC went haywire again. So, if the voltage is ramping up, it is fine, but at typical it borks it?
I ran it for several days and found that if I unplug the battery for about 30 seconds, and plug it back in, the very first read is accurate, and then it immediately pegs back to the 256 value. Resetting the core via System.reset() doesn’t suffice, I have to actually yank the battery.
I also tried using the sleep and wake methods for the MAX17043 IC, seemed to have no impact.
Kind of at a loss here - I can figure out my drain baseline through exhaustive testing, but it will take drastically longer if I can’t use the fuel gauge, and it will also prevent me from using the alert functionality.
I have used the MAX17043 quite successfully with other systems. Sparkfun has a “fuel gauge” based on it. I think the problem you are having are caused by issues with the Photon’s I2C firmware, and according to other posts, a fix for which is currently being tested.
One thing I don’t like about this Battery Shield is it is delivering battery voltage to the VIN pin on the photon when not connected to USB or optional power jack. Ideally it should also have a boost power section to deliver 5V to VIN instead, with a LDO set around 3.2V or so to shutdown before damaging the battery or causing brownout of the Photon.
Could someone look into this again? I’m using the sparkfun battery shield with the updated firmware (0.4.4 updated automatically through flashing on particle build) and I’m still seeing the same number here for SOC - 255.99609375.
@gelicia I have found marginal improvement with 0.4.4 in that if I remove the battery from the connector, and plug it back in, it will read correctly until I connect it to USB again. Obviously this is not a long term solution as I need this to work through charges in a sealed container, but it’s getting…better? Ish?
I only ever get the 255 number, even after getting that variable right after plugging in the battery. Could someone who was working on the I2C stuff look into this? @peekay123 ?
I am still having the issue, is there a way to tell from what version of the firmware a photon is running if you don’t trust ? Since I had no change after updating, I’m wondering if maybe my firmware wasn’t updated.
I also have two of these boards now and they both do the same thing.
For what it’s worth I am occasionally seeing this issue with 0.4.5 although it works much of the time. When it happens, hitting the reset button does not fix it, and after the photon has rebooted the other I2C devices are not able to communicate properly. Only after disconnecting power from the entire system for a while (~30 sec) and powering up again does I2C start working normally again. It almost seems as if the MAX17043 is locking up the lines for some reason (though I have not measured) and the power off is needed since the chip has an RC filter on its power input.
