Measure, Publish, Sleep Loop

My goal is pretty simple. I need to loop through MEASURE, PUBLISH, SLEEP at a rate of between 20min-1hr with the lowest possible power consumption. My project uses the BORON with 1.5.0 and the Particle Workbench Development environment.

also using SYSTEM_MODE(AUTOMATIC);

I have been able to achieve a MEASURE, PUBLISH, DELAY loop, but when I switch out the DELAY with SLEEP all kinds of strange things happen.

I have tried several different configurations of SLEEP as a replacement for delay(20min) in my loop.

This one results in the publishes never reaching the cloud even though I have a delay(5s) between PUBLISH and SLEEP. It does breath cyan for a few seconds every 20min but nothing publishes. Also the current measurement is still a whopping 10mA.

   SystemSleepConfiguration config;
   config.mode(SystemSleepMode::STOP)
      .duration(20min);
   SystemSleepResult result = System.sleep(config);

The next one caused 10 flash SOS.

   SystemSleepConfiguration config;
   config.mode(SystemSleepMode::STOP)
        .flag(SystemSleepFlag::WAIT_CLOUD)
        .duration(20min);
   SystemSleepResult result = System.sleep(config);

This one results in the Publish being run 2-3 times in less than a second every 20 min.

    SystemSleepConfiguration config;
    config.mode(SystemSleepMode::STOP)
        .network(NETWORK_INTERFACE_CELLULAR)
        .flag(SystemSleepFlag::WAIT_CLOUD)
        .duration(20min);
    SystemSleepResult result = System.sleep(config);

I am pretty new to Particle, but thought this would be pretty simple. I really appreciate any help or advise.

@ranchch Firstly welcome to the Particle Community.

I was just looking at unanswered posts and saw your’s.

Actually, keeping comms going through a cycle of sleep and wake isn’t that simple. Putting delay in the application loop() is not the solution. Your application needs to use a Finite State Machine model (search for FSM) where the application will stay in a certain state until there is an event (cloud connection, event published and acknowledged). On top of this, with the Boron and cellular comms, the reconnection after a period of sleep is not guaranteed and may take 20 seconds one time and never happen within a minute the next time. Your application needs to be able to cope with this. Another approach is to isolate the sending and queuing of events - using something like the PublishQueueAsyncRK library. Lastly, I have found Sleep function to sometimes be fiddly to use in that things can block it starting (particularly pin settings and peripherals) and thus the power drain is still there.

Suggest you have a dig around on the topics above - there are lots of posts that have solutions you can use.

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