Electron Battery Charge Issue

Greetings all, new to the platform so, open to all suggestions here.

I am having an issue with batter charging on my electron. Here is what I know so far:

I believe these are normal behaviors provided to help troubleshooting:

  1. It can run on battery power
  2. When I am powering using USB or 5V, disconnecting the battery causes the red led to flash quickly
  3. When I connect USB, the red light comes on (initially) if the battery is not fully charged
  4. When I connect via 5V the red light comes on and the Electron draws about 400mA (initally)
  5. I can see the state of charge using the battery library

However, I can’t seem to get the battery to take a full charge. With either Vin or USB, the red light goes out before the battery takes a full charge (10 seconds on USB, 1-2 mins on Vin).

What else should I check?

Thanks,

Chip

What are your SoC an VCell readings for the battery?
If you get about 85% SoC you can consider it fully charged due to safety margins.

1 Like

ScruffR,

Thanks for responding. It is at 81% charge.

Talking of safely, I plan to use this in an outdoor location. Does the charger know not to charge when it is too hot or too cold?

Thanks,

Chip

Hey, Chip!

I remember you working on a cellular project when Adafruit first released their Fona cellular boards.

Yes the PMIC on the Electron does handle charging so it suspends charging when temps are above or below programmed setpoints which are done by the resistors on the temp pins.

Here is the actual PMIC chip used on the Electron if you want more data on it.

http://www.ti.com/product/BQ24195

Cool, Thank you RWB. Yes, I have moved off FONA and am loving the Particle Electron. I have also been refining my solar power board - full project details here - https://www.hackster.io/chipmc/solar-power-module-v2-ef387a

I do plan to use solar for the Electron. But, I have a lot of work to do on power optimization as I am new to the platform and have not implemented sleep and interrupts. I also plan to start working on a carrier board for the Electron for extra memory, power distribution and peripheral connections.

Chip

1 Like

Yea the Electron has pretty good solar charging abilities built in along with the fuel gauge so you could probably eliminate some of the stuff on your current solar charging board.

I’m sending data to Ubidots and can send data every 2 mins and get about 2 days run time with no solar input off a fully charged 2000mAh battery while going to sleep between every publish.

I also put the Electron into a deep sleep when the battery SOC hits 20% to keep the Electron from ever seeing an empty battery and shutting down or possibly loosing all its memory which sometimes happens if you allow the battery to drain to empty. Normal operation resumes when the battery voltage is charged up above 20% via the solar panel. The Electron checks every hour if the SOC is above 20% or not. You can get weeks of time in this.

Here is my code which would probably help you save some time figuring this all out, I’ve been testing and revising it for at least 6 months now.

SYSTEM_MODE(SEMI_AUTOMATIC);
//SYSTEM_THREAD(ENABLED);
// This #include statement was automatically added by the Particle IDE.
#include "Ubidots/Ubidots.h"

#define TOKEN "YourUbidotsToken"  // Put here your Ubidots TOKEN
#define DATA_SOURCE_NAME "ElectronSleepNew"

SerialLogHandler logHandler(LOG_LEVEL_ALL);  //This serial prints system process via USB incase you need to debug any problems you may be having with the system.

Ubidots ubidots(TOKEN); // A data source with particle name will be created in your Ubidots account.
//

int button = D0;         // Connect a Button to Pin D0 to Wake the Electron when in System Sleep mode. 
int ledPin = D7;         // LED connected to D1
int sleepInterval = 60;  // This is used below for sleep times and is equal to 60 seconds of time. 

ApplicationWatchdog wd(660000, System.reset); //This Watchdog code will reset the processor if the dog is not kicked every 11 mins which gives time for 2 modem reset's. 

void setup() {
 //Serial.begin(115200);
 pinMode(button, INPUT_PULLDOWN);  // Sets pin as input
 pinMode(ledPin, OUTPUT);          // Sets pin as output

 ubidots.setDatasourceName(DATA_SOURCE_NAME); //This name will automatically show up in Ubidots the first time you post data. 
 
 PMIC pmic; //Initalize the PMIC class so you can call the Power Management functions below. 
 pmic.setChargeCurrent(0,0,1,0,0,0); //Set charging current to 1024mA (512 + 512 offset)
 pmic.setInputVoltageLimit(4840);   //Set the lowest input voltage to 4.84 volts. This keeps my 5v solar panel from operating below 4.84 volts.  
}

void loop() {
    
FuelGauge fuel; // Initalize the Fuel Gauge so we can call the fuel gauge functions below. 
 
    
if(fuel.getSoC() > 20) // If the battery SOC is above 20% then we will turn on the modem and then send the sensor data. 
  {
   
   float value1 = fuel.getVCell();
   float value2 = fuel.getSoC();
   
  ubidots.add("Volts", value1);  // Change for your variable name
  ubidots.add("SOC", value2);    

  Cellular.connect();  // This command turns on the Cellular Modem and tells it to connect to the cellular network. 
  
   if (!waitFor(Cellular.ready, 600000)) { //If the cellular modem does not successfuly connect to the cellular network in 10 mins then go back to sleep via the sleep command below. After 5 mins of not successfuly connecting the modem will reset.  
    
    System.sleep(D0, RISING,sleepInterval * 2, SLEEP_NETWORK_STANDBY); //Put the Electron into Sleep Mode for 2 Mins + leave the Modem in Sleep Standby mode so when you wake up the modem is ready to send data vs a full reconnection process.  
    
}  
  
     ubidots.sendAll(); // Send fuel gauge data to your Ubidots account. 

     digitalWrite(ledPin, HIGH);   // Sets the LED on
     delay(250);                   // waits for a second
     digitalWrite(ledPin, LOW);    // Sets the LED off
     delay(250);                   // waits for a second
     digitalWrite(ledPin, HIGH);   // Sets the LED on
     delay(250);                   // waits for a second
     digitalWrite(ledPin, LOW);    // Sets the LED off
  
     System.sleep(D0, RISING,sleepInterval * 2, SLEEP_NETWORK_STANDBY); //Put the Electron into Sleep Mode for 2 Mins + leave the Modem in Sleep Standby mode so when you wake up the modem is ready to send data vs a full reconnection process.  
    
  }
  else //If the battery SOC is below 20% then we will flash the LED 4 times so we know. Then put the device into deep sleep for 1 hour and check SOC again. 
  {
      
  //The 6 lines of code below are needed to turn off the Modem before sleeping if your using SYSTEM_THREAD(ENABLED); with the current 0.6.0 firmware. It's a AT Command problem currently. 
  //Cellular.on();
  //delay(10000);
  //Cellular.command("AT+CPWROFF\r\n");
  //delay(2000);
  //FuelGauge().sleep();
  //delay(2000);
  
  
  digitalWrite(ledPin, HIGH);   // Sets the LED on
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, LOW);    // Sets the LED off
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, HIGH);   // Sets the LED on
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, LOW);    // Sets the LED off
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, HIGH);   // Sets the LED on
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, LOW);    // Sets the LED off
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, HIGH);   // Sets the LED on
  delay(150);                   // Waits for a second
  digitalWrite(ledPin, LOW);    // Sets the LED off
  
  System.sleep(SLEEP_MODE_DEEP, 3600);  //Put the Electron into Deep Sleep for 1 Hour. 
  
  }
}    

RWB,

Awesome, thank you. This should shorten my learning time considerable.

BTW, I am integrating with Ubidots using Webhooks - did you consider this option and what are the advantages of using the Ubidots library?

Thanks,

Chip

The advantage to sending data directly to Ubidots is that it requires less data so your overall data consumption is lower which should cost you less.

Also, the reconnection times when waking up from sleep using Network Standby are usually a lot quicker than when connecting to the Particle Cloud first which saves on battery.

From my testing Pushing Data directly to Ubidots has been very reliable over long spans of time. I had seen more issues when pushing data through Particle Publish in the past.

Let me know what you end up doing :slight_smile:

@RWB, the only caveat is that webhooks are secure whereas connecting to directly Ubidots (via TCP) is NOT secure. :wink:

True. For my applications, the data is not sensitive info so I don’t really worry about it.

Using the TCP method with Ubidots you do get per device token security so you can turn incoming data to Ubidots off if you ever have an issue with 1 unit.

1 Like