Boron SystemSleepMode::STOP continually woken up BY_NETWORK

Firmware
1

Hi,
I’ve just started working with a Boron LTE (I was previously working with an electron) and I’m using the new SystemSleepConfiguration on OS 2.0.0-rc1 and I can’t get my device to sleep for the given duration. I keep getting a wakeupReason() from SystemSleepResult of BY_NETWORK and I can see with the status led that it indeed turns back on after a second or two of sleeping (not the 30 or so seconds that I’m trying to get the device to sleep).

Here’s what I’m doing:

SystemSleepConfiguration sleep_config;
    sleep_config
    // STOP + NETWORK_INTERFACE_CELLULAR equivalent to SLEEP_NETWORK_STANDBY
    .mode(SystemSleepMode::STOP)
    .network(NETWORK_INTERFACE_CELLULAR)
    .duration(sleep_for * 1000)     // in milliseconds
    // not used but must be specified
    .gpio(WKP, RISING);
    SystemSleepResult result = System.sleep(sleep_config);

I’m also using LOG_LEVEL_ALL with:

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);

I’m pretty sure I’m doing something wrong, but I’m having a hard time figuring it out as I’m debugging via serial so I think I might be missing the logs?
Is there any way to stop this from happening or check if all the network mesages have been processed before sleeping?

EDIT:
I just tried adding .flag(SystemSleepFlag::WAIT_CLOUD) to the sleep config but this hasn’t helped.

2

I would try

.duration(30s);

just to see if that makes a difference.

3

So I left it running overnight and it turns out that it does sometimes succeed in sleeping for the given duration (this is also confirmed with a wakeupReason() of BY_RTC) so the sleep_for time is fine, but it is often being interrupted by the network which is a problem.

4

DeviceOS 2.x introduces an option to wake up on new data arriving on network interface, so your sleep configuration (.network(NETWORK_INTERFACE_CELLULAR)) actually instructs to do just that, hence the BY_NETWORK wake-up reason.

The SLEEP_NETWORK_STANDBY is synonymous to .network(NETWORK_INTERFACE_CELLULAR, SystemSleepNetworkFlag::INACTIVE_STANDBY), which will leave the network interface powered and connected but in paused state so that the modem can potentially cache any arriving data while we sleep, but will not configure it as a wake-up source.

1 Like
5

Awesome thank you!

6

So I gave that a try but now it disconnects and reconnects to the Particle Cloud every time it sleeps, which also isn't great - especially if it struggles/fails to do so.

7

Hi @kal, from what you described, your device was behaving as expected. Specifying the network as a wakeup source doesn’t actually save more power. It’s about 4mA you can save when the device is asleep with the cellular modem on, in comparison to normal operating mode.

So for short sleep period, I would suggest you to specify the network wakeup source, which will leave the device connected with the cloud to speed up cloud data processing. In this case, it’s fine that the device is woken up by network interface, as you should not expect the device to save significant power. And for long sleep period, I would suggest you to use the ultra-low power mode and not specify the network interface as a wakeup source. In this case, the device will save significant power to extend the battery life, but at the cost of spending a bit long time to restore cloud connection. It’s a trade-off. It depends on whether you’d like an efficient and responsive cloud interaction or to extend the battery life.

Cheers!

8

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.