WakeOn RI in SLEEP_NETWORK_STANDBY?


#6

I tested OTA flash, and that will wake up the Electron and succeed.

I don’t think there will be any unexpected wake ups, as the cloud should never send data to the Electron outside of the normal circumstances (function, variable, subscription, OTA flash, or ping). But I have it running with the sleep period set to 22 minutes and we’ll see if it wakes up unexpectedly.

Note; The maximum sleep period must be less than the keep-alive interval, as this requires a working UDP back-channel to the device.


#7

Just now saw this!

Really cool feature for saving power yet still being cellular connected!

Great work!


Electron - Low power wake up from cellular message?
#8

@rickkas7 Hi Rick, just wanted to share some numbers with you on this. We have confirmed that this works very well and that our current consumption went from 20mA to about 4mA for a 30Mhz underclocked 3G Electron based product that is always ‘on’, ie always reachable from the back end. This functionality alone helped us get 5X more out of a single battery charge. Drastic improvement. Awesome work @rickkas7, thank you for your help and support!


#9

This is great work. Excited to implement this in our code.

I’m wondering if this will work with the Boron. I’ve got the Eagle files for the Boron – it looks like RI_UC is not connected.

Is there another way to implement this?


#10

Just thinking through this – I guess if I’m not worried about using the 20mA power vs 4mA power, I could start and stop the uC calling Particle.process() to check the RX buffer on the modem every 5 seconds or so. This would depend on the ping information being in the RX buffer.

Is this possible? Or do I need to call Particle.connect() before calling Particle.process()?


#11

The details of what will be exposed on the mesh platform for sleep modes have not been finalized. The nRF52840 has a crazy large number of sleep modes, and can do things like wake on serial data, which I presume is why the RI_UC pin isn’t connected. But exactly what will be exposed and when has not been determined.


#12

I’m trying to understand why this saves battery life. Does implementing this method reduce the network reconnection time (therefore less current draw from battery) while in SLEEP_NETWORK_STANDBY? Trying to get a clear picture on why this special command does that.


#13

It adds another use case: Wake by cellular.
So during SLEEP_NETWORK_STANDBY, Cloud events can wake the Electron.
OTA Firmware Flash, function calls, Particle.Variable Requests, Subscribed Events, etc, can wake the Sleeping Electron.

Per rickkas7 test results, the most power efficient sleeping method is to use NETWORK_STANDBY if you need to publish every 12 minutes or sooner. If you’re publishing at longer intervals, use DEEP SLEEP.

However, if your power budget can afford the 4.5 mA sleeping current of NETWORK_STANDBY, you always have access (from the Cloud) to your Electron with WakeOn RI_UC as a “virtual” wake pin.


Pulling a value from the cloud
#14

@Rftop Gotcha! That paints a much better picture and makes sense now. Thanks for the clarification.


#15

Well, dang! This command doesn’t work for E-Series LTE versions.

Cellular.command("AT+URING=1\r\n");

So, I started looking into the commands for the SARA-R410M module (LTE CAT-M1). The command syntax and values have changed to:

Cellular.command("AT+URINGCFG=2\r\n");

This command however, sends back an AT read error. Here is the log info:

0000021534 [app] INFO: turning on AT+URINGCFG=2
    21.534 AT send      15 "AT+URINGCFG=2\r\n"
    21.542 AT read ERR   9 "\r\nERROR\r\n"

I also got other AT errors, with commands not associated to t AT+URINGCFG, like this one:

Socket handle 4 was open, now closing...
   124.825 AT send      12 "AT+USOCL=4\r\n"
   124.834 AT read ERR  37 "\r\n+CME ERROR: Operation not allowed\r\n"

I must be doing something wrong. Not sure what though? Help @rickkas7

By the way, tested using v1.0.1 firmware.


#16

It doesn’t work because AT+URINGCFG requires the SARA-R410M-52B.

The E Series LTE and Boron LTE have the SARA-R410M-02B, which does not have AT+URINGCFG.

However, on the Boron LTE and B series it should eventually be possible to set the nRF52840 to wake on serial, which will be necessary anyway because the RI line is not connected on the Boron.


#17

Damn, I guess there isn’t a way to get this to work on E-Series LTE then?


#18

Unfortunately not at this time.


#19

@rickkas7

Just to check to make sure I am not getting this wrong. It appears as though the 2G version of the Electron which has a SARA G350 chip does not support Wake on RI. If the below is true is it correct to assume that there is no other way to wake the micro through the cellular module?

“The AT+URING command for the notification of all the URCs and all the incoming data (PPP, Direct Link, sockets, FTP) over the RI line output is not supported by SARA-G3 modules.”


#20

That is correct.

Device Modem WakeOnRI
Electron 2G SARA-G350
Electron 2G/3G Global SARA-U201
Electron 2G/3G Americas SARA-U260
Electron 2G/3G Europe/Asia/Africa SARA-U270
E Series E310 Global 2G/3G SARA-U201
E Series E402 LTE SARA-R410M-02-B

Can I wake up an Electron using Cloud Events or functions?
#21

Can this function be used on CHANGE vs RISING?

    CHANGE to trigger the interrupt whenever the pin changes value,
    RISING to trigger when the pin goes from low to high,
    FALLING for when the pin goes from high to low.

What I have now is:

System.sleep(BTN, FALLING, SLEEP_TIME_SECS, SLEEP_NETWORK_STANDBY);

Given this, would I change it to:

System.sleep({RI_UC, BTN}, CHANGE, SLEEP_TIME_SECS, SLEEP_NETWORK_STANDBY);

/r,
Kolbi


#22

You can also provide a list of trigger edges just the same way as you provide list of pins like this

System.sleep({RI_UC, BTN}, {RISING, FALLING}, SLEEP_TIME_SECS, SLEEP_NETWORK_STANDBY);

#23

Awesome!

Thanks ScruffR!


#24

Great thread!

I’ve implemented this on an electron e-series 2G/3G, but no matter what sleep timeout I choose the device wakes up after 2 hours of sleep. The device wakes up correctly if pinged via console.

System.sleep(RI_UC, RISING, 36000, SLEEP_NETWORK_STANDBY);

I’ve also tried to pass 0 seconds (sleep forever?) with same results.

I have WKP connected to an I/O line and I previously used SLEEP_DISABLE_WKP_PIN in different sleep modes to avoid unwanted wake-ups, but it seems this option is not available together with the RI_UC option.

Thanks
Simone


#25

I tried the same procedure on a Electron 2g/3g global (SARA-U260) running deviceOS 1.0.1. The device still wakes up every 2hours. This is my code. Any idea @rickkas7 ? Thanks!

#include "Particle.h"

SerialLogHandler logHandler(LOG_LEVEL_TRACE);

const int SLEEP_PIN = D2;
void setup() {
	Serial.begin();
	pinMode(SLEEP_PIN, INPUT_PULLUP);
}

void loop() {
	if (digitalRead(SLEEP_PIN) == LOW) {
		Log.info("turning on AT+URING=1");
		// Enable wake on all URCs
		Cellular.command("AT+URING=2\r\n");
		delay(1000);
		System.sleep(RI_UC, RISING, 120, SLEEP_NETWORK_STANDBY);
		// This delay is to allow the serial monitor to reconnect only
		delay(2000);
		Log.info("woke from sleep mode");
		// Turn URING back to the default value (only notify on SMS or voice call)
		Cellular.command("AT+URING=0\r\n");
	}
}