@mnetwork, sleep with a wakeup pin puts the processor in STOP mode. This mode requires a bit more power than STANDBY mode used by DEEP_SLEEP. We are talking about 300ua for STOP versus about 5ua for STANDBY. This is ONLY for the CPU and does not include the onboard regulator and external flash current consumption. The total power consumption for the Core in DEEP_SLEEP is about 187ua. No one has measured the STOP mode consumption (@BDub?) yet. 
1 Like
The general fact that these sleep modes do differ is documented here, tho’
http://docs.spark.io/firmware/#spark-sleep
But as for the technical and electrical details @peekay123 's the source of bottomless depths of insight 
I guess he’s got the STM32 datasheet as a custom wall paper in his office
2 Likes
@peekay123 I have recently measured a bunch of the modes on the Core and Photon. I need more Photons to test though to really lock those numbers in, and as the firmware settles down things might change again. The numbers for the Core are good though.
1 Like
@BDub, can we call “Sleep” something like “Sleep with wake on pin” instead so it is not confused with Spark.sleep(time) which is really the same as WiFi.off()?
I would have expected STOP mode to be lower than 800-900uA but a lot of factors affect that power level. 
System.sleepwithwakeonpin(D0, RISING) 
I kid…
what about
System.standby(D0, RISING, 30);
For the stop mode, you are right… there are a few other devices on the board that add some quiescent current. Also, it’s possible some peripherals can be turned off that are still on, but then when you come out of STOP mode you would need to re-enable them. It’s doable though.
Thanks @BDub for the hard facts table 
I think this would again be a source for confusion, since as I understood @peekay123 STANDBY is technically what SLEEP_MODE_DEEP would trigger, but this kind of System.sleepwithwakeonpintortwo() 
would technically be STOP, or not?
I'd rather drop the Spark.sleep(timeout) since it's not really a Spark.sleep() but more a WiFi.sleep(timeout).
Granted, this might break running code, so it might not be the most brilliant of ideas, but I'm well known for these 
- the non-brilliant ones, that is 
BTW: Was it intentional to call it System.sleep() rather than Spark.sleep()?
@BDub, I think “standby” and logically “stop” modes might make more sense than “sleep”:
System.standby(30); //Since only WKUP pin, RTC event or RST event will wake STM32
System.stop(D0, RISING, 30); //Since EXTI, RTC or RST event will wake STM32
Exiting STANDBY causes a reset whereas STOP simply stops the code execution and continues from where it left off when awakened (only on Photon; Core forces reset).
Exploiting VBAT with controlled VDD presents interesting options, especially with peripheral power control.
1 Like
Yeah a couple things… we definitely don’t want to break existing code, so we need to keep that in mind. We do however need to depreciate certain things from time to time as the firmware evolves. That’s typically a good thing 
This is a balancing act, that sometimes tips one way or the other… ideally it stays balanced though.
I used System.sleep() instead of Spark.sleep() because we had made this change on the Photon… separating peripheral control from more API-centric methods. It’s becoming a habit to type already.
I like .standby() and .stop(), but there’s always going to be some confusion if you look at how STM labels these modes (SLEEP, STOP, STANDBY) verses what makes intuitive sense from an application point of view (STANDBY, SLEEP, DEEP SLEEP) respectively.
We also need to add something for VBAT mode 
1 Like
@BDub agreed on compatibility. However, I don't believe we use the STM32 "sleep" mode and thus why I only mentioned "stop" and "standby". Given that "sleep" is not implemented on the Core (it is really a re-packaged WiFi.off()), will it be implemented on the Photon?
I touched on VBAT here:
The power drop event (interrupt?) needs to be handled via a callback IMO and some use cases need to be illustrated. 
That's the way to do it
I'm aware that you'll do it right anyway, but just for the sake of having it said:
One way to start deprecating some of the things that seem to confuse several people might be to add the successor functions into the code and document them already, add the deprecation note to the docs of the "old" versions as soon as possible, later on remove them from the docs, but leave them in the code base (well documented for open source browsers like me ;-)) to keep old programms intact.
The tricky part might be, when to completely let them go 
3 Likes
Great information guys. I decided there is no point in me using STOP because in my case I am only using a button to wake up the core. I can do the same thing with the RST pin. Do I ground this pin to initiate a reset?
EDIT: Never mind, grounding RST works.
WKP on Photon is active HIGH, so this is a good pin to have access to for waking up from DEEP SLEEP. Also by using a pin such as WKP which is also a GPIO, you can read the state of the pin on start up in MANUAL mode and debounce this active HIGH state so that you know for sure someone pressed your button (and you are not waking up from noise or some other quick bump of the switch that’s not technically a press).
1 Like