OK, I plan on adding WiFi data connectivity to some new battery based products were building. Since these are battery based devices the less power the new Photon consumes the better.
@zach @peekay123 @BDub1 I’m curious if you guys have any data on power consumption figures for the new Photon?
If my memory serves me correct the Spark Core was consuming around 250ma @ 5v constantly.
I’m eager to see if its dropped or not.
@RWB, we don’t have power consumption numbers yet but it is fair to say that the low power modes on the Photon will be better than those of the Core. This includes the new wake-up pin and a direct battery input (VBAT), neither of which was supported by the Core. The VBAT can be powered by a battery or super-capacitor to maintain the RTC and the backup registers of the STM32 so it can be awakened either via the RTC or the wake-up pin.
Regarding the Core power consumption, your figure of 250ma is incorrect. With the CC3000 module enabled but not transmitting, the core power consumption is typically about 50ma depending on how hard the processor is run. With wifi transmitting, the consumption is typically 150ma or so. So if your app is not working the wifi very hard, power consumption is low. The Core also supports great sleep modes where power is very low though the on-board regulator and flash do consume extra power that cannot be “shut off”.
The Photon will not use an external flash chip and the on-board regulator has a very low (30 nA) shutdown voltage. Using VBAT to maintain the RTC and backup registers will allow for a super-low current consumption. Using STANDBY mode, processor will use 2-3uA from the 3.3v supply and less than 1uA from the VBAT line. 
Will the Photon be able to wake from a low power mode and still retain SRAM? The current core does not.
And will there be support for the new sleepmodes the later WiFi accesspoints? some WiFi chips can do ~8mA while connected, but with a latency of about 250mS
@mtnscott, from the STM32F2xx specs:
- The backup domain includes 4 Kbytes of backup SRAM accessible only from the
CPU, and address in 32-bit, 16-bit or 8-bit mode. Its content is retained
even in Standby or VBAT mode when the low power backup regulator is enabled.
It can be considered as an internal EEPROM when VBAT is always present.
You can use the PWR_BackupRegulatorCmd() function to enable the low power
backup regulator and use the PWR_GetFlagStatus(PWR_FLAG_BRR) to check if it is
ready or not.
- When the backup domain is supplied by VDD (analog switch connected to VDD)
the backup SRAM is powered from VDD which replaces the VBAT power supply to
save battery life.
This suggests some very interesting low power modes and EEPROM modes for the backup SRAM!
I also found (on a separate site):
Backup mode: Backup mode: ~3µA with RTC on with RTC on, ~1uA with 4-Kbyte backed up SRAM Kbyte backed up SRAM,
~4uA with both on
@remcohn, which wifi chips are you referring to?
@peekay123 Thanks, I was more specifically trying to understand if the firmware rewrite and implementation for the Photon will try and take advantage of all the capabilities provided by the STM32. For example STOP which us suppose to retain SRAM and only use .5ma:
Due to current Spark implementation of the firmware resuming from a STOP condition will result in SRAM being cleared.
So - my question is directly related to how the firmware team plan on implementing the modes and if there will be a mode where SRAM will be retained when resuming from a sleep state?
@mtnscott, I believe the issue with the SRAM being wiped is that VBAT is not supported on the Core, not allowing the full exploitation of STOP and STANDBY modes. Since VBAT will be implemented with the Photon, the short answer, IMO, is YES it will support SRAM retention with an external battery/supercap on VBAT.
Nope - it's due to the firmware implementation when returning from the STOP state.
I'm happy to help the photon team make sure we can leverage the full capabilities of the sleep modes.
@mtnscott, you are correct regarding STOP mode. So it comes down to the fact that you can’t stop the IWDG timer once you start it. What would be nice is to be able to set a (fixed address) flag in flash that would cause a bypass of the IWDG setup in the bootloader and in firmware. The flag would also be used in spark_utilities to configure the sleep mode. It could be set and read from the user app for full control of both the IDWG and the way STOP works. Any thoughts?
i might as well say it, the electric imp has a sleepmode like that, based on the same broadcom chipset. it asks the accesspoint to tell in its beacons if there is data or something and wakes up synced to those beacons. average powerusage is about 8 - 10mA, while still beeing ‘connected’
so maybe a compile time flag, much like how SYSTEM_MODE is implemented?
An additional Spark. function call, or even just change Spark.sleep() The two modes currently supported by Spark.sleep() are basically the same, lets make the one with STOP mode not execute the IWDG and return execution to the next line of code after the sleep call. We may have to add code to restore the CC3000 to its state before going to sleep.
@remcohn, what is really happening is the IMP goes to sleep for a pre-determined amount of time and when it wakes it reconnects to the access point, does a DHCP IP request and connects to its cloud then goes back to sleep. It does not stay "connected" as you say. The "average" power consumption is dependent on the amount of sleep vs the connection time (seconds) with the peak current being drawn during wifi activity.
As per IMP's specs,
Normal operation, WiFi on: 80-250[2]mA
Normal operation, WiFi power-save mode enabled: 5-250[2] mA
WiFi is off, processor sleep, RTC on, nvram preserved: 6 µA
(2) 250mA current is during worst-case TX events. These are a maximum of ~4.8ms long (802.11b 1Mbps
This is very much like the Core but a bit more evolved. In the Photon, functionality will be the same as the IMP I suspect. 
@mtnscott, it would have to be a runtime flag since the bootloader is not compiled and flashed with the user code. It is in the bootloader that the IDWG is enabled to begin with I believe. So a static (fixed address) control byte is needed IMO. As for restoring the CC3000, the regular Spark.sleep() puts the module in low power mode so doing a WiFi.on() essentially wakes it up.
Sorry, had to de-lurk and correct this
The mode @remcohn is referring to does actually stay connected. It’s not sleeping, reassociating, etc - this is IEEE PS mode where the radio sleeps between beacons which reduces the radio power significantly. Association is maintained, there’s no latency impact to outbound traffic but a small impact to inbound as the AP tells the STA during the beacon that there’s data waiting, then the STA leaves IEEE PS and receives the packet.
The Photon can definitely enable this mode too, which should result in similar wifi power consumption to the imp in the same mode (though the imp, due to the VM setup, manages all the STM clock trees automatically so application code has to do absolutely nothing to minimize the static and dynamic SoC power; we have further improvements coming here too).
One big fat note about IEEE PS mode though. It’s dumb. You will see the lowest power consumption on quiet networks. If you have a big network with loads of devices doing bonjour broadcasts constantly (I’m looking at you, printers) the savings vary immensely - the AP will wake every STA in IEEE PS mode for every broadcast, and that’s an AP-side thing hence not something you can fix in the device itself.
@hfiennes - agreed. You can even violate the specs (with variable results) by sleeping for < n> beacons and relying on the AP to try more than once to get the message through to you.
Agreed also that the savings very greatly depending on the network, but any time you get to turn the receiver off is a good thing, if you are trying to get long life from limited power.
The core was able to wake-using many different pins based on an interrupt, will the photon support the same or can it only be woken up on the wake pin?
Do I understand it right? (on the Photon), If using a supercap on the VBAT pin, that VBAT pin gets 3.3 volts from the chip while in full operation, and when the chip is shutdown, the supercap will then be providing its charge (2.9 - 3.3 volts) to maintain the RTC and backup registers.
@Jack, the VBAT pin will not charge the supercap directly. Take a look at these STM32 threads for more info:
So with the addition of a 100 ohm resistor to prevent to much current draw during charging the superCap (or battery), it should be ok?
The basic question was: does the VBAT provide 3.3V while system is in normal operation.
I have used a 5.5volt (don’t use any rated less than 3.3 !), superCap , as well as a 3.7V lithium battery on a Core, 3.3v pin as a UPS with good results before. It provided self charging from the Core, and when the 5volts dropped, it continued running for some time (2 minutes - over 1 hour).