Hi, I want to deploy multiple xenon devices to a field with soil moisture sensors. And I was wondering if the boron could handle the soil reading timing, and not the xenon endpoints. So, the idea is that the boron sends a wake up msg to all endpoints, and in return, each endpoint sends back a reading and goes back to sleep. Is this possible? I was thinking this approach because I need all readings more or less at the same time. The endpoints will be running on batteries, so I need this to be as efficient as possible to save battery life. Is this the best solution? Or should each endpoint handle its reading time and go back to sleep? In that case, how do I handle that all devices wake up at the same time? This is my first project with particle devices.
I haven’t seen the mesh api, so I don’t know if it’s possible to do exactly what you’re asking.
But within a single sleep period, there shouldn’t been too much drift, so you can just have each xenon sleep normally, then when it wakes up it will re-sync before deciding how long to sleep for. Either it can use the real-time clock to decide how long it needs to sleep every time it wakes up or the Boron can tell it how many seconds to sleep for each time it wakes up and provides its reading.
I don’t have the nRf specs handy, but RX tends to be expensive compared to TX due to the time it tends to be on. TX uses more mA (at high power settings) but it’s only on for the packet duration, while RX often has to be on for far longer to account for synchronization. The result is that it’s typ cheaper to wake up, do your thing, TX the result, perhaps wait for an immediate ACK, and go back to sleep. If you need tight sync you may have to wake up periodically to evaluate clock drift and maintain sync.
Although my reply is many months later, the sleep function on Mesh appears to have just been released with 0.9.0.
To answer the question, of which I have a similar scenario, you can put your devices in deep sleep. You can wake them via a pin call or wake based on time it seems. The best energy conservation requires a call to wake up the device which loses all memory and accurate time until reset by the cloud. Using time to wake up will apparently use more energy and retain state.
System.sleep() can be used to dramatically improve the battery life of a Particle-powered project. There are several variations of System.sleep() based on which arguments are passed. Gen 3 devices (Argon, Boron, Xenon) only support sleep modes in 0.9.0 and later. Sleep does not function properly in 0.8.0-rc versions of Device OS for mesh devices.
System.sleep(SLEEP_MODE_DEEP) can be used to put the entire device into a deep sleep mode, sometimes referred to as "standby sleep mode."
The Gen 3 devices (Argon, Boron, Xenon) can only wake from SLEEP_MODE_DEEP by rising D8. It's not possible to exit SLEEP_MODE_DEEP based on time because the clock does not run in standby sleep mode on the nRF52. Also, the real-time-clock (Time class) will not be set when waking up from SLEEP_MODE_DEEP. It will get set on after the first cloud connection, but initially it will not be set.
System.sleep(uint16_t wakeUpPin, uint16_t edgeTriggerMode, long seconds) can be used to put the entire device into a stop mode with wakeup on interrupt or wakeup after specified seconds. In this particular mode, the device shuts network subsystem and puts the microcontroller in a stop mode with configurable wakeup pin and edge triggered interrupt or wakeup after the specified seconds.