Photon wifi powersave

In the datasheet theres a listing of power usage, one of them being “Operating Current (Wi-Fi on, w/powersave)”.

Is this something we can activate from user code, or is it automatic based on wifi reception ?

@MORA, take a look at the System.sleep() modes, the Wifi modes and the System modes which variously control the wifi and power modes of the Photon. Everything is contained in the Photon firmware documentation :smiley:

I am already using wifi.on/off and deep sleep, but the datasheet has a “Wifi on with powersave” so surely thats not refering to sleeping with the radio off…

If there is a way to use wifi in powersave mode, and prevent the 430mA peaks that would be really helpful to battery operated nodes, even if they can likely be provided via a capacitor.

@MORA, good point and good question! I’ll ping @BDub and others at Particle :smile:

There is, but we haven’t created a user API for it yet. It’s on the list though and if you dig into the WICED API you can see how to control it. Pull Requests are welcome if this is a feature you want to try to implement now :thumbsup:

Hey @BDub has there been any ip[dated on this? If not, could you point, me out to where in the Wiced API this is documented?


@BDub and @mplacona has there been any progress made on this mode of operation? I’ve seen a couple of threads showing some low-level hacks to enable this, but a higher-level API access to it would be fantastic.

I’m curious about this too, since the numbers in the data sheet don’t seem to make sense. I thought the WiFi module was the main power user, but that doesn’t comport with these numbers form the Photon data sheet,

Operating Current (Wi-Fi on) IIN avg 80 mA
Operating Current (Wi-Fi on, w/powersave) 18 mA
Operating Current (Wi-Fi off) IIN avg 30 mA

Are these numbers correct? Does power save mode with WiFi on use less power than non-powersave mode with the WiFi off? If so, it seems that having an api to enable us to use power save mode would be very useful for battery powered applications. An explanation of what powersave mode is would also be a good thing to have in the docs. If powersave mode would allow us to have a device that’s always responsive to an incoming command (i.e. WiFi on) that uses 18 ma instead of 80, that would be great.

The traditional wifi powersave mode is to skip a certain amount of beacons, it works with pretty much any AP out there since it was part of the original 802.11 spec, how many beacons you can skip differs between APs though, but around 2 is the norm (so checkin every 3 beacons of 100ms each).

The trade off is latency, since you only check for new messenges every 300ms or so, but thats very much worth it, imo.

We had this on the table early on, but it seems to have gotten lost in the private repo where initial development took place. I added those current measurement numbers (w/powersave 18 mA) to the datasheet in anticipation for this API. I’ve recreated the issue here:

Please chime in there ^ if you would like an official API sooner than later :wink: Thanks all!

@BDub Looking at the Github issue that you just posted, I still don’t understand the numbers. It appears that the power save mode is all about the WiFi, so how can it be that the average current with WiFi off (30 ma) is higher than in power save mode (18 ma) where the WiFi is on part of the time?

Good question Ric! I’m trying to think back to when I wrote this up… the 18mA was measured from the broadcom evaluation board which included the same microcontroller and radio that the Photon has, so theoretically Powersave mode (as a Particle Photon API) could typically achieve the same. However, there could be a big difference in processor clock speed that attributes for the difference. On the Photon, simply turning WiFi off does not change the processor clock speed or turn off any other peripherals, therefore the 30mA. So when enabling the Powersave feature on the Photon, it’s possible that without doing anything to the processor and peripherals the actual current could be 30+18mA. That is not to say we couldn’t add more power-saving changes to “Powersave mode” to get closer to, achieve 18mA or exceed less than 18mA.

Right now a good alternative to Powersave mode is Sleep Stop mode ( System.sleep(D1, RISING, 20) ). Code execution is halted in place, and the Wi-Fi module is turned off. This consumes about 2-3mA. It will not currently handle asynchronous events from the Cloud like Powersave mode might, but there could be a possibility to also combine Powersave and Sleep Stop mode in a couple different ways in the future.

May I know the differences between these three highlighted items?
Is Operating Current (Wi-Fi off) it when; is executed?
What does Sleep Current imply?
I am confused.:sweat:

Ping @BDub

@ScruffR is correct below :slight_smile: - BDub

AFAIK, the first one is not yet available as the powersaving features where the WiFi stays connected but only limited (serviced less frequently with lower gain) aren’t fully implemented/exposed yet.
The second is - as you said - after or in similar situations.
And the third one is - as I understand it - in Stop Mode Sleep (as STM calls it in their datasheets) which would be entered via System.sleep(wakePin, wakeEdge [, timeout]);


@ScruffR thanks for clarifying!

As it stands presently, whats the most battery efficient way to implement a sleep state that wakes for a simple PIR sensor interrupt? I presume you turn the wifi off and then when the interrupt is triggered, you could turn the wifi back on again, but how do you optimize sleeping the Photon?

Actually I’d go for Stop Mode sleep since the PIR can trigger a wake interrupt.

If you get a rising edge you could even go for deep sleep and wake on PIR -> WKP.

1 Like

@Bdub @rickkas7 Does Wifi Power Save Mode work on the Photon or P1 as of May 2018?

The Photon/P1 power save modes are not supported at this time.

1 Like

The best I’ve been able to do is do a once-per/time wakeup (an hour in my case) and check in. I’m able to get around a week of battery on a 2000mAh LiPo while still running the application semi-online by throttling the CPU clock way back and turning WiFi off. Unfortunately the CPU has to be sped back up when the connection is activated, otherwise the device freezes. I had to implement some juggling to keep that all straightened out.

Fortunately my use-case is primarily driven by events at the device side, so it can wake itself up when it needs to respond quickly-- otherwise you have to either activate it or wait for it to come online again.