Electron Cellular.off() and Sleep Modes

Firmware
1

I have noticed a couple of other older posts which involve Electron, Cellular.off() and Sleep modes but they are a bit old. I am using firmware 0.6.0 (latest)

I am finding that if I call Cellular.off() and then go almost immediately into a Sleep mode (not Deep Sleep in this case but it probably applies as well) that the modem does not power off, it continues fast flash of green, ie, on but not connected.

To prevent this it is necessary to insert a delay of at least 6 seconds between the Cellular.off() and entering sleep mode. Then everything works OK.
Thinking about it, this is probably OK, in sleep mode the device does not operate so if it is waiting for confirmation from the modem that it has turned off then it assumes it has not?

Any of you wonderful people close to the firmware able to comment on this?
Thanks

2

I've been playing around with the Electron and Sleep Modes also.

Watching the current consumption of the Electron when putting it to sleep you can see it takes a few before it turns off and current drops way down.

I'm using the code from this post and it may explain why your seeing what you're seeing also:

3

@RWB thanks for that link, I am using thread enabled so I guess that is where I am seeing the issue. I am allowing 10 seconds after Cellular.off() before entering sleep mode and this seems to clear it by a second or two. It would be nice to have a flag to look for to say it was really off instead of having to just delay. Maybe there is an AT command which will provide that?

4

I would like to get rid of the delay also.

@Bdub with the current firmware do we still need to use this to get the Modem to turn off?

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

From your post here: SLEEP_MODE_DEEP not working with SYSTEM_MODE(SEMI_AUTOMATIC)

5

Unfortunately yes. You can track this issue here to see what version of firmware the fix gets merged into: https://github.com/spark/firmware/issues/1176

2 Likes
6

@BDub I loaded the 0.6.1-rc on my Electron and I want to verify if this code is still needed when using System Threading & System.sleep(SLEEP_MODE_DEEP, 3600); to get the modem to go to sleep or not?

The fix does not say it was merged but there are tons of other improvements so I just wanted to make sure.

I’m using this code to put the Electron to sleep if the battery SOC is below 20%.

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

The Electron into deep sleep if the SOC is below 20%:

  Cellular.on();
  delay(10000);
  Cellular.command("AT+CPWROFF\r\n");
  delay(2000);
  //FuelGauge().sleep();  //Keep Fuel Gauge ON for more accurate readings. 
  //delay(2000);

  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);
7

Hi @RWB This will most likely be released with 0.7.0.

1 Like
8

@BDub One more quick question about if I’m keeping cellular data consumption to a minimum using this code on the Electron. Calling Cellular.connect every time I wake up doesn’t cause the full handshake data penalty does it?

I’m using these modes:

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

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);
1 Like
9

If there is a PDP context already, it should skip over re-registering things on the cellular level. The full handshake or session resume only happens when you connect to the Particle Cloud though, so here in the code above you are using ubidots so I’m guessing it’s just a straight TCP/IP transfer.

There shouldn’t be any improved data usage for ubidots in 0.6.1-rc.1… just Particle Cloud connections. There were some buffer fixes for the Electron though, so depending on how large the TCP buffers are in ubidots and how errors are handled and comms retried you may see some differences.

10

That’s good to know. Thanks for the info.