SystemSleepNetworkFlag::INACTIVE_STANDBY has no effect (DeviceOS 5.3.1)


I am writing firmware for sleepy devices, if devices have to transmit data more often than 15 minuttes, I use the following code in my sleep function, SystemSleepNetworkFlag::INACTIVE_STANDBY);

Duration is being set prior to this. The above function is simply wrapped in an if-statement that checks transmission interval.

I see in my code that the if-statement is executed when transmit intervals go below 15 minutes (900 seconds), however, power-testing this function shows that it uses exactly same amount of power as without the if-statement executing. Around 112 microamperes.

So my question is simply whether that the GSM module is in standby at all times or it simply does not trigger using the flags specified? I am using DeviceOS 5.3.1 for info.

All the best,

Could you include more of the code? The power usage should definitely be relatively higher when NETWORK_INTERFACE_CELLULAR is on, but the other case should be much lower, and both should be lower than 112 mA, so there may be something else wrong.


  • Which device?
  • What version of Device OS?
  • What is the sequence of steps to get to that point?

For example, some sequences like measuring sleep current in sleep immediately after a cold boot in SEMI_AUTOMATIC or MANUAL mode without connecting to cellular first can cause high values because the modem was never turned on, so it can’t be put into sleep mode properly, which leads to higher readings.

Hello Rick,

Quick clarification it is 120 microampere (µA), it should be higher of course. Sleep code is in the end of this reply, but first:

  • Which device?

  • What version of Device OS?
    5.3.1 (newest)


  • What is the sequence of steps to get to that point?
    Measure X number of times, using following function to sleep between measurements:

   // Initialize Power Configuration
   SystemSleepConfiguration measurementSleepConfig;
   // Power Configuration using ULTRA_LOW_POWER, HALL_PIN for restart and compensated sleep duration - SystemSleepMode::ULTRA_LOW_POWER
   measurementSleepConfig.mode(SystemSleepMode::ULTRA_LOW_POWER).duration(Dryp::instance().getCompensatedSleepTime(measurementDelay, measurementSleepTime)); // I compensate for the time to measure, so each measurement is started at same interval

   if (hallEnabled)
      measurementSleepConfig.gpio(IOConstants::HALL_PIN, CHANGE);

   // Handle network standby for cellular interface based on constants or time limit
   if (networkStandby || (measurementSleepTime.count() * Class::instance().getNumberOfMeasurements()) < CloudConstants::NETWORK_STANDBY_LIMIT)
   {"Setting network to standby");, SystemSleepNetworkFlag::INACTIVE_STANDBY);

   // Execute SystemSleepConfiguration and enter sleep
   SystemSleepResult result = System.sleep(measurementSleepConfig);

   // If device was woken up due to hall effect being triggered
   if (result.wakeupReason() == SystemSleepWakeupReason::BY_GPIO)
      // Hall sensor was triggered during sleep, so let's restart!

After X number of measurements, it connects, transmits, disconnects and enters same cycle again

I see, it does indeed say 120 µA in the original post. So that does mean that cellular is getting turned off even in the case where the log message is generated and it should be going into standby mode.

  • Do you manage cellular on state manually or let System.sleep() do it?
  • Was cellular on before attempting to sleep? You may want to log the value of Cellular.isOn().
// Disconnect from Particle Cloud and cellular network
void Class::disconnect()
   // Disconnect from cloud

   // Wait for Particle disconnect
   waitFor(Particle.disconnected, DeviceConfigurationConstants::DISCONNECT_TIMEOUT);

   // Turn cellular module off;
   waitFor(Cellular.isOff, DeviceConfigurationConstants::DISCONNECT_TIMEOUT);

I think you might be on to something - what is best practise for disconnecting etc. in the newest version, especially if you have sort of a conditional network standby

You can generally let Device OS handle disconnecting for you in all recent versions. It is indeed calling that is preventing cellular standby from working for you.

However, another option is to determine whether you want to use NETWORK_INTERFACE_CELLULAR earlier and only call when you will not be using cellular standby.

The exception is if you are using cellular off mode, and you want to wake with cellular off so you can do data acquisition then go back to sleep without connecting to cellular. In this case, you need to disconnect from cellular before sleep, because the state is restored on wake.

1 Like

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