For the record, this API is still not documented in SDK.
I’m also wondering how to make the system ultra-low-power. There’s “Deep sleep mode: < 5 µA” claimed in product sheet of Core module and above in this thread you say SDK handles the sleep modes automatically based on the scheduler.
Hi, the 10-20 uA is normal consumption with current SDK and sheduler.
If you would like to get lower, you need to lower the period the scheduler is called.
For even lower consumption you would need to configure and (deep)sleep MCU yourself and create some wake-up event from timer, RTC or GPIO.
We also have (bit outdated now) schedulerbranch i our SDK which dynamically put the Core Module to up to 2 second sleep cycles if no task was sheduled. It works, however it had some issues with button detection. But IIRC I get to the 7uA.
That’s great, using “scheduler” branch really makes a difference!
Do you have any plans to eventually merge these changes to the master or make the default scheduler more configurable? Obviously using unmaintaned branch of SDK in new project will make troubles sooner or later.
Hi, thanks for resurrecting and confirming that scheduler branch still works
We spend at least a day with my colleague finding the bug but without sucess. So merging is easy, but fixing that bug could take a few days. Unfortunatelly we have lot of other work so we cannot guarantee that.
However it would be great if you test that branch and write us if you find anything which might help us in the future with fixing. I remember that the issue was that sometimes the task was not fired in the right time, but after that maximal 2 second period which the RTC timer has.
During that timeframe we are using FreeRTOS on all other custom devices we’ve made and we confirmed that it could be used in low-pwer environment. So our dream is that IoT kit and SDK could use FreeRTOS under the hood, but for user-level code this will still run in a single task, because otherwise it makes things more complicated with mutexes etc.