Electron - Long Term Solar Charging Uptime Testing

@Bdub Have you heard about any issues with Electrons that are outside having connectivity issues due to the SIM card holder possibly flexing or contracting from the constant temp changes?

I’ve had a unit outside solar charging but eventually it stops connecting and sending data even with a full battery. When I pull it inside it just flashes Green as it tries to connect but never does.

The solution for me is to pull the sim card, bend the metal bar that holds the sim card down, down slightly and then reinsert the sim card which causes it to successfully reconnect the next time. This is the second time I have had to do this since the temps dropped into the 30F and below ranges.

I’m just curious if your hearing from others that may be having this same issue as the outdoor temperature begins to drop due to winter.

This is the first I’m hearing of this. Usually with SIM connectivity issues the unit will drop off the network and be blinking dark blue (in Listening Mode). Without touching the SIM, if you remove power and reapply it, the electron should go to blinking dark blue if the SIM has a bad connection.

@BDub I never saw the Blinking Dark Blue, but I never pulled the battery connector out of the battery JST connector jack either.

I’ll remember to verify the bad SIM card connection by pulling the battery and looking for the
dark blue LED indicator.

Stay Tuned… It’s been in the -2 - 20F temp range lately, I’m sure your loving the fact that you no longer live in the mid-west anymore :smiley:

@RWB, I guess this is going the same way as this thread, isn't it?

@RWB, @ScruffR, This seems indeed be more than the same direction. I think there is a big need for an extended temperature range Electron. I use iot sim cards from a local Belgian provider and these are all -40C --> +85C for these purposes, so there are solutions for this. The biggest concerns are the components on the electron itself.

There is another thread on this topic as well, please see SMT version of the Electron Seeing the answer of @will in this post I suppose Particle is working on a set / industrial version of the Electron. So I hope we may have good news maybe for Xmas or New Year on this topic. It would be a nice gift :wink:

1 Like

I think the Electron as it is now is perfectly fine IF the SIM card socket does not start causing issues due to wide temperature changes over the seasons.

I’m planning on building an add-on shield for the Electron to add a new battery management chip that has a better fuel gauge and support for the longer life LiFePo4 & LTO battery support. I’m really liking the LTO cells due to their much wider charging & discharge range of -20 - 60+ degrees F and extremely long lifespan ranging from 10,000 to 30,000 cycles depending on which cell your working with.

The current Li-Po and Li-ion cells have a cycle lifespan of 300-500 cycles which is not very long for an IoT device you may want to deploy and last years.

The current PMIC stops solar charging the battery when temps drop below 0C which is good for the Li-Po battery but bad for your device that you want to keep online 24/7 since you can experience weeks or even a month of weather below 0C, With LTO cells we can drop that low temp cutoff to -20 or -40 with some LTO cells.

I’m seeing how long until I see Connection issues again in this winter weather.

2 Likes

@RWB, thank you for your response. Your comments on the battery component are very interesting! And indeed the shield your are talking about would be very good. However is Particle is going to make a new version of it, they might as well integrate this as well. It might be worth to contact @will for this, since he mentioned in the post. The more complete the system is, the less you have to invest in non-project electronics.

Hey folks – as we’ve continued to investigate an Industrial variant of the Electron, extended temperature ranges and SIM reliability are two issues that have been front of mind. I’m hoping that we’ll be able to address both of those concerns with a future hardware release.

It’s still too early in process to share more specifics, but we’ve been diligently collecting feedback from threads like this one and others like it, and feel like we’re well aligned with everything y’all are asking for. Please keep the feedback coming, and we’ll share more information the moment we’re able to!

Happy holidays everyone!

5 Likes

@BDub I’m having issues with the Electron not reconnecting or reaching Cellular.ready() after the Electron has been in deep sleep mode for a few days of bad weather.

So the SOC stays below 20% for 2+ Days while the Electron wakes up every hour to check if the SOC has risen above 20% and it can do this for 20 days before depleting the battery.

Today the sun is out and the Electron is solar charged up to 38% and tries to run the publish code but it can not get past the Cellular.connect(); > Cellular.ready(); so it never starts sending data again unless I manually hit the reset button.

I unplugged the battery and then plugged it back in and I did not get the dark blue flash that indicates a bad or missing SIM card. After hitting reset a couple times the Electron connects and sends data again.

So I’m wondering if there is code I can call to reset the cellular modem without causing large data handshake penalties? My code is below if you want to take a look.

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

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


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


int button = D0; 
int ledPin = D7;              // LED connected to D1
int sleepInterval = 60;


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);
 
 PMIC pmic;
 //set charging current to 1024mA (512 + 512 offset)
 pmic.setChargeCurrent(0,0,1,0,0,0); 
 pmic.setInputVoltageLimit(4840);    
}

void loop() {
    
FuelGauge fuel;
 
    
if(fuel.getSoC() > 20)
  {
   
   float value1 = fuel.getVCell();
   float value2 = fuel.getSoC();
   
  ubidots.add("Volts", value1);  // Change for your variable name
  ubidots.add("SOC", value2);

  Cellular.connect();
  
   if (!waitFor(Cellular.ready, 60000)) {
      
    System.sleep(D0, RISING,sleepInterval * 2, SLEEP_NETWORK_STANDBY);
}
  
     ubidots.sendAll();

     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);
    
    
  }
  else
  {
      
  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);
  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);
  }
    
}    
    

If you are waking up from deep sleep:

else
  {
      
  Cellular.on();
  delay(10000);
  Cellular.command("AT+CPWROFF\r\n");
  delay(2000);
...

Then I’d say that should be equivalent to pressing reset. Pressing the RESET button does not however reset the cellular modem. Those are decoupled specifically so that thing like OTA updates don’t reset the cellular connection.

Unfortunately I’m not really following your code because the formatting is either off with discourse or it’s not all there? Would you might making a GIST out of it?

It might be worth having debugging enabled on the TX pin or USB so you can quickly connect a non-connecting unit to the computer and record the logs. I have seen cases where there are complex conditions we could look for and help to speed up the connection reset process by detecting them. You can also try issuing a reset of the cellular module via software, but only do this as a last resort under extreme no-connect cases. Reseting the modem too often could get your SIM banned on the network. Currently the system firmware only resets the modem once during the power on sequence if it fails to power on the modem 10 times, and also in an attempt to detect the SIM card after several tries.

void resetModem() {
    pinMode(RESET_UC, OUTPUT);
    digitalWrite(RESET_UC, LOW);
    delay(100);
    digitalWrite(RESET_UC, HIGH);
}

void setup() {
    resetModem();
}
1 Like

@Bdub Sweet!

I just added the Modem Reset code to run only if the Cellular.connect(); > Cellular.ready(); = True does not happen after 5 mins of trying.

I’m going to try this and see if it makes any difference or not.

1 Like

@BDub Still having reconnection issues with the Electron after it tries to connect to the cellular network after deep sleeping after seeing the battery SOC below 20% for 12 hours or more.

Adding the Modem Rest code did not solve the problem.

What code do I need to add so I can plug in a USB cable to my laptop and see the debug serial output so we can see what exactly is going on?

@RWB you need to make sure your user app is compiled with logging enabled.

SerialLogHandler logHandler(LOG_LEVEL_ALL);

Let me know if you don’t see the modem AT commands. It should look pretty similar to when you program your electron with the tinker usb debugging app:

particle flash --usb tinker-usb-debugging

How much battery SoC do you have when the electron won’t connect?
Can you reproduce with with a short deep sleep cycle and charged battery?

OK so I add this line above the Setup();

SerialLogHandler logHandler(LOG_LEVEL_ALL);

Then flash Tinker-usb-debugging to the Electron via the CLI.

Sounds simple enough.

Plenty of battery left when this happens. The Electron just sits outside in the Sun all day and charges up past 20% and tries to connect and send data updates but that never happens. This only happens once the Electron goes through many cycles of waking up every hour to check if the SOC is above or below 20%.

I can bring the Electron inside hit reset and sometimes the connection issues persist and after a few more resets it connects just fine and starts sending data again and the SOC is well above the 20%.

The debugging should help identify what exactly is going on. I'll report back soon :smiley:

No you just need to add that line to your own app globally OR try the tinker debugging app if you don’t get the logging output with AT commands.

Thanks for the Clarification!

The PMIC is setup to disable charging when the temp is below 0C right? Based on the Schematic it looks like the resistors are there for that function.

I see the RED charging LED lit when the sun is out and the solar panel is attached. Even with lower temps the sun heats up the case that the Electron is in and brings the temp up above 0C and it charges fine.

@RWB you might also want to try using single threaded mode since you have a simple loop there and are using SEMI_AUTOMATIC mode.

Also is this line sleeping the MCU for 120s if the cellular doesn’t connect in 60s?

  if (!waitFor(Cellular.ready, 60000)) {
      
    System.sleep(D0, RISING,sleepInterval * 2, SLEEP_NETWORK_STANDBY);
}

I would change the Cellular.ready line to 600000 (10 mins) to see if that helps. The connection will naturally try for 5 minutes before it times out and power cycles the modem and tries again. So perhaps you are getting into a state where you are just not waiting long enough for the modem and MCU to try their connection process. Because you are keeping the modem on during sleep stop mode, it should still be trying to work out the connection but you don’t get the benefit of the system reconnection logic perhaps. You might be able to force it with Cellular.off() then Cellular.on() before sleeping though, but you should not do this in such a fast loop to keep strain on the network low.

Just brought in the Electron from outside and the battery PCM has cut the output from the battery so its reading 0v.

Hooked the Vin to my power supply and set the current to 50mA and ramped the voltage up slowly from 0v to 5v to simulate the solar panels output voltage from dark to sun up in the morning. The PMIC’s charging LED turned RED and current flowed into the battery so it was charging.

The PMIC will not charge at more than 100mA in this state and since the voltage ramps up slowly the Electron never resets or turns on as it would if you plugged a USB cable or supplied 5v instantly. The charging current will not go above 100mA until the Electron actually starts up so the charging is limited to 100mA in this state.

This setup worked well in the summer so maybe the colder weather is preventing charging even though the RED charging LED makes it look like it’s charging from the solar panels. More testing is required to verify if charging is indeed happening via solar in this colder weather. The temps are on the border line 32-34F and the system is sitting in the sun so the PMIC chip should be warmed up enough to charge properly.

The Code puts the Electron into deep sleep when SOC drops below 20% and I should get at least 10 days of standby time with 20% battery capacity left but the battery is dead right now so something is not right. The only thing hooked up to the Electron is the battery and solar panel to the Vin pin.

I’ll have to verify power consumption in deep sleep mode using the uCurrent Gold to be sure of stand by power consumption.

If charging does not happen below 32F then that is probably my major issue.

Lot’s to verify on my end. :wink:

I’ll try implementing your recommended code changes also since they make perfect sense :wink:

Thanks for your support! :particle:

1 Like

Sometimes I wonder if the Fuel Gauge is too heavily filtered on the SoC reading and doesn’t represent the correct percentage. One way to double check without calling quickStart() is to read the battery voltage which is not filtered and compare to a look up chart.

Here are some readings I’ve taken in the past:

| BattV | SoC  |
|-------|------|
| 3.25  | 0    |
| 3.35  | 0.05 |
| 3.45  | 0.13 |
| 3.55  | 1.35 |
| 3.65  | 3.7  |
| 3.75  | 18   |
| 3.85  | 49   |
| 3.95  | 68   |
| 4.05  | 81   |
| 4.15  | 93   |

Something to note, before 0.6.1-rc.1 there was a -0.1V error on BattV readings due to a software bug. Easy to compensate for if you are not using 0.6.1-rc.1. Readings above are using a power supply, then running quickStart(), waiting 200ms then reading the SoC value.

So the thing you’d want to do is somehow publish or save the SoC and BattV readings and when you think it’s just below 20%, check the BattV reading and see if it seems to correlate to the correct value in the above chart.

If they are off, for now it might be a good idea to run quickStart() on wake with the cellular modem off, wait 200ms, then take your SoC reading. At least it would get reset every wake up, and you can extend that to every reading if you want (but it should be with the modem off so that you don’t introduce noise into the readings).

@Bdub The cold weather and lower battery voltage at these lower temps may be causing inaccurate readings also.

Inaccurate readings in cold temps could be the reason I’m seeing run time I’m expecting once the Electron hits 20% SOC and only wakes from Deep Sleep every hour to check SOC readings.

Hard to tell without a lot of testing which I will be doing more of.