On our old revision we were able to get down to ~40uA of sleep current. On this new revision we are only able to get to ~83uA.
What have we done?
When quickly putting together some test firmware to ensure all our peripherals were working as expected we found the current consumption to be quite high when calling api.system.sleep.all().
We figured this is likely the state of some of the GPIO when sleeping. After configuring all the the GPIO as INPUT_PULL UP / INPUT_PULLDOWN / TRISTATE etc we were able to finally get it to ~83uA.
My suspicions
We have two devices that we communicate with over SPI and three over I2C. I found even after calling SPI.end() or Wire.end() I was not getting low sleep current. To achieve ~83uA I had to pull all the I2C and SPI GPIOs high.
I feel like this shouldn’t be the default and maybe I am missing something?
I have also noticed periodic spikes in the power profile when using the NRF power analyzer despite calling api.ble.stop(), api.ble.adversite.stop() and api.ble.uart.stop(). Is there maybe something else still on which could be contributing to the additional ~40uA.
We were really hoping this update would be quite easy and I have gone through the hardware bit by bit trying to find a fault in the design but it feels like it is something to do with RUI3. Am I missing something here? Some help would be very much appreciated as we are trying to finalise a large order of these units and want to ensure we can get this power consumption down.
With Wire.begin()/Wire.end() and SPI.begin()/SPI.end(), I am still getting down to the same, with no I2C or SPI devices attached. I am not de-initializing the I2C SPI pins here.
Here is the code I used to test. It is a simple, low power example code for RUI3 devices. RUI3-LowPower-Example.zip (5.1 KB)
This version of the code toggles SPI and I2C .begin() and .end() between each LoRaWAN transmission.
Send interval can be set with ATC+SENDINT=xxx with xxx in seconds between transmissions.
@beegee we have updated to V4.0.6 and have actually seen an increase in current consumption. Now sitting around 119uA.
If I remove my code which pulls the I2C pins and SPI high it jumps up to 180uA.
I have looked at your code and don’t see anything that jumps out that isn’t being done in my code.
Before calling api.system.sleep.all() I am setting all the GPIOs to the state that “should” be lowest power. Does calling the sleep function change the state of any of the GPIOs? Are there any I shouldn’t be using?
api.system.sleep.all() is part of the RUI3 that is not open source and I have to check with the team if there are any GPIO de-initializations done.
May I ask you what I2C and SPI devices you are using? Are you controlling the power supply of these devices?
If this is confidential, we can switch this issue to our Help Desk. Just send me an inquiry to [email protected] or [email protected] and we can discuss it there in private.
EDIT
Corrected email address.
For GPIO’s you should de-initialize only exposed GPIO’s. Some GPIO’s are used internally to control the SX1262 LoRa transceiver and can cause problems if floating. (e.g. floating RESET to the SX1262)
Hello @beegee ! Adding onto this, I’ve noticed that api.sleep.all does not appear to be sleeping the device correctly
Using the stock example LoRaWan_OTAA with the device credentials changed so I can connect to my nearby network, I am seeing that the device is actually on for long periods of time after a successful send. It does go to sleep eventually, but only for a few seconds before waking up again. While asleep (and powering via 3V3 header on the core module) I’m seeing ~168uA minimum
The serial output confirms this strange behavior, with SLEEP message being printed out long after the send action, rather than immediately after as is expected.
Any recommendations here would be appreciated, thanks. Perhaps I should shift to the rtos implementation instead of this delay() replacement, if you think that would be more robust?
Thank you very much for that information, very good to know. I’ll have a play around with that sketch instead and let you know if there are any issues.
