Once again I am having issues getting the Argon to sleep properly. According to the docs, I should be in the neighborhood of 80uAmps but I am seeing 960uAmps. An order of magnitude too high. Here is my code. Note I am really just wanting to wake using the RTC. The code below shows also waking via a GPIO but I included this to see if it made any difference. It does not.
SYSTEM_MODE(MANUAL)
SYSTEM_THREAD(ENABLED)
SystemSleepConfiguration config;
void setup() {
config.mode(SystemSleepMode::ULTRA_LOW_POWER)
.gpio(WKP, RISING). // this can be removed and I still get same power consumption measurements
.duration(10min);
}
void loop() {
delay(5000);
System.sleep(config);
}
Duplicated with both os 4 and the latest general release of 5.
I have also tried this on 2 different Argons (one brand new out of the box)
I’m not positive the Argon exhibits the same behavior, but the Boron will not go into the lowest power mode after a cold boot if you do not turn on the network first, and I think the Argon may exhibit the same behavior.
Basically, the problem is that in order to put the network processor into full sleep mode, it needs to be on to receive the commands to turn it off. But after a cold boot, it’s in a mostly, but not entirely, off state. In the normal use case of cold booting and turning networking on, you’d never notice this situation because when you go to sleep after that, the device will go into sleep properly.
If you really have a need to be able to go into sleep immediately after a cold boot, you may need to add a special case of checking retained memory to see if this is a cold boot or not, and power on and off the networking.
This isn’t necessary on wake from sleep, or reset after the modem has already been fully powered down, so it’s really just the one case of cold boot and go directly to sleep where you see this behavior.
I’m not positive that this is the problem you are seeing, but it’s a possibility.
Thanks for this @rickkas7. I will give this a try today. So, in theory, from a cold boot, we would only need to do this once, not every time we re-awake from sleep? I’ll see what I experience today in the lab and report back.
I’m not sure why you’re getting the higher readings. I tried your original code with Device OS 5.1.0 on an Argon and I’m getting 82.7 µA once the Argon goes to sleep.
so this is without futzing with the radios? I’ll try on a third Argon.
Also, in case it is relevant.
My Argons are unclaimed. I basically remove them from the box and then follow this procedure.
Set the local WiFi via the CLI
Put the device in DFU mode
In Particle Workbench compile both application and device os against 5.1
Flash both application and device OS. (with SYSTEM_MODE(MANUAL))
When the device boots it wants to jump onto the net despite the SYSTEM_MODE(MANUAL). It appears to be maybe downloading a new boot loader compatible with OS 5.1?
Then device reboots and runs blynk or whatever I give it properly.
But at this point I am not seeing proper sleep numbers.
Hey @rickkas7 Any other ideas? Should I issue a support ticket.
Also, is it true that particle doctor does not work correctly for Argons? I am having issues trying to get it to update to the latest release thinking that my approach of using Particle Workbench to get everything up to date might be inducing the power sleep mode issue.
Workbench should absolutely not be used to upgrade the Device OS version. From this page in the Workbench docs, scroll down a little and expand “More about changing the Device OS version” for an explanation of why and how to do it instead.
The best way to initialize large numbers of Argons is using a SWD/JTAG debugger. This will make sure all dependencies are updated properly, but there are many other ways.
The particle doctor only works on the E Series, Electron, Photon, and P1. It doesn’t work on any other devices.
Ugg. So what is the proper way to upgrade a brand new, out of the box, Argon if you don’t have a SWD/JTAG debugger? And I don’t want to onboard it through the mobile app, just plug into computer and set it up. I have about 100 of these to do for a major client. Maybe if I get this process down, my sleep issues current issues will be resolved.
@rickkas7 Well unfortunately same issue. Sleep starts out at around 90uA and then in a perceived split second jumps to +900uAmps. Really not sure what other things to try. This is with 3 Argons now all experiencing the same issue. Also, tested on two different work benchs with different measurement tools, one at my lab at work and one at home. Not sure what else to try.
If you checkout my video I posted in this thread you will see how the Argon is setup. @rickkas7 Let me know if that helps. Actually here is the link again to the video.
Also, I should note that I believe I see the power initially drop to about 90 uAmps right when it goes to sleep but immediately pops up to +900uAmps. I tried to record this with my Siglent SDM 3055 with fast sample mode but it appears to miss it in the trace export to an xls file.
I have also tried this code and wiring D5 to GND to see it is a floating GPIO that might be waking it up if one doesn’t supply a .gpio argument to the config.mode call but I still got the same results.
I have also reverted to 3.3 with same results.
