@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.
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!
@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.
@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-250mA
Normal operation, WiFi power-save mode enabled: 5-250 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.
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.
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.
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).