Active mode, cloud connected, not actively communicating:
~13 to 16 mA
System.sleep(BTN, FALLING, 60, SLEEP_NETWORK_STANDBY)
~10.5 mA most of the time, spikes of at least 56mA every 20 sec or so.
System.sleep(BTN, FALLING, 60)
~10 mA
System.sleep(SLEEP_MODE_DEEP);
~9.7 mA
I also tried to add Cellular.off() before the sleep command and the current slightly decreased to ~10mA for mode 2. which makes sense since it becomes equivalent to mode 3.
Now what doesn’t make sense is why power usage is that high in sleep modes, especially compared to xenon? Apart from mode 2. when cellular module is still on, the 2 others should be similar to what is found for Xenon c.f. this thread.
By the way, I replaced the Boron with a Xenon and run the same code. The power usage figures are the same ones found in aforementioned thread.
Can someone else conduct a similar test to rule out any mistake in my setup and/or code?
The code I’m using is shared here.
It can be compiled for either Boron or Xenon and the display is not required for the tests.
I’m powering the tested device with the battery only. The measuring device has its own battery and USB is disconnected when running the test. In active mode the OLED display adds 1 or 2 mA and in sleep mode I don’t see a difference when it’s connected vs. disconnected. I send the ‘display off’ command to the OLED before going to sleep mode, which puts it in sleep mode too.
And like I mentioned, replacing the Boron with the Xenon, keeping everything else the same gives me sleep mode current usage in the 0.1 mA range.
It’s possible to get down to around 694 µA to 750 µA on the Boron in SLEEP_MODE_DEEP. powered by the LiPo connector (3.6V). You need to Cellular.on() before doing Cellular.off(). This is the case on the Electron/E Series as well. Since the modem is put into sleep mode using AT commands, if the modem is off, it won’t go into lowest power mode.
Amps obviously decrease when the supply voltage is increased to something more typical of a Li-Po, but the mW tracks pretty close on a slow voltage sweep over the Li-Po operating range. I guess 3.60V is just as good as any for comparing current results.
Good job folks. …Sub-mA Sleep isn’t bad for the first Sleep implementation on the Boron LTE.
I look forward to seeing how this progresses in the near future
I repeated the measurements with your code @rickkas7 and @Rftop and I got the same figures as yours.
What I have trouble with is how to use System.sleep(uint16_t wakeUpPin, uint16_t edgeTriggerMode); and System.sleep(SLEEP_MODE_DEEP); these don’t get me anywhere lower than 9mA…
but taking cues from your sample code, I then tried this:
// cellular module off, system off mode
Cellular.off();
delay(4000);
System.sleep(SLEEP_MODE_DEEP, 0);
==> power usage down to 0.7 mA
It looks like Cellular.off() is required before System.sleep() and it also needs few seconds (> 3 sec) to effectively turn off the cellular module. This is different than how it works on the Electron and I hope next firmware updates will address this difference.
On mesh devices you need to pull D8 high to wake the device. There is no timed wake from deep sleep with Gen3 but Stop Mode sleep will only draw very little extra current over deep sleep.
Have any of you been able to use the System.Sleep for a longer duration than 5 minutes? I use this in my code to initiate a stop mode sleep for 5 minutes.
I am currently using Automatic mode, waking up every 5 minutes, taking readings, publish an event and then fall back asleep. There is very little power consumption while it is sleeping which is fantastic however if i program this to be longer than 5 minutes, let’s say 30 minutes using this:
It never seems to wake up again. I am theorizing it doesn’t wake up like it should after some duration OR maybe it’s waking up but not re-connecting properly before falling back asleep.
Next steps:
Determine exact breaking point (works at 5 minutes, doesn’t work at 30 minutes) Where does it break.
Investigate behavior using manual mode. Confirm it is connected before publishing and then falling back asleep.
On the plus side, the Boron can take a lot of sleep, wake up, take readings, publish, sleep… cycles with consuming very little battery. I’ve at 80 cycles since yesterday. Started at 96% and is only at 95% LiPo 6600 mAH battery. Pretty sure If i can get it to sleep properly for 30 minutes it’ll easily last the 3 months that I need it to.
Have you seen this behavior before? is there a good workaround? Do I need to use Manual mode and control the Cellular separately?
How do you determine this? If you are publishing to the cloud, you most likely need to wait for Particle.connected() before proceeding after sleep. You may want to blink the D7 LED when you wake to see if it is waking or not as well.
Peekay123: Nothing more than it just never publishes anything to the cloud with the only line of code that changes was the 300 --> 1800. I originally had 300, confirmed it worked, changed it to 1800, it never posted anything, changed it back to 300 it published things, changed it to 1800 and it didn’t publish anything. I need to set it to 30 minutes and use a stop watch to look at it 30 minutes later to see if it ever does the breathing cyan. Since that was the only line of code that changed I figured I wouldn’t have to use manual mode but I’ll give that a try tonight.
Rftop… fantastic. I was hoping it was something stupid I was doing or just having to use Manual mode. My application requires longer sleep duration and I didn’t want to hassle with using the EN pin. Would you mind posting your exact code for doing this in manual mode. Maybe i missed something obvious. I’ll give manual mode a try tonight.
Sleeping 30 minutes is probably close to the worst possible time duration given that the keep-alive is 23 minutes. That tells me that at 30 minutes the device most likely has to re-establish a connection from scratch. You may end up using less battery and less data if you wake up every 20 minutes… Of course, would need to be tested…
So I must of goofed two days ago somehow. When I tested it last night, I was able to sleep and wake up every 10 minutes, 20 minutes and 30 minutes without any problem while still in the default automatic mode. It's been publishing every 30 minutes ever since. Not really sure what I did wrong two days ago that it wasn't publishing. Sorry for the confusion everyone. I'll be better on testing more before asking this community to keep the content relevant. In any case, I still will add the Particle.Connected() as a precautionary measure and best practice but doesn't look like it's required.
Great suggestion. I will update it to be 20 minutes and see how it does. With the new LTE being significantly less power, I think even waking up every 20 minutes, the 6600mAH battery will last the duration I need to.
For my application, I'd like the Boron to last 10 weeks total on a 6600mAH lipo battery and publish as often as possible without having to do a solar charger or take it down to recharge at all. If needed, I could do a even larger battery pack. Next improvement I need to make is cut the power to the sensors when sleeping using GPIO pins. The 3 sensors I have draw about 1 mA as measure using my Fluke meter.
Interesting you should say that. I'm also finding that my Boron 2/3G's are not publishing reliably to the cloud after 10-min sleeps. I've also been using AUTOMATIC mode until now and these sleep lines:
Cellular.off();
delay(4000);
System.sleep(A4, RISING, 300);
Even more intriguing is that there are quite a few cloud connect events where the battery voltage is sent, but the Webhook JSON is NOT sent. See below:
