Turning off WIFI radio on the Pico W

[UsuallyErrored]

I'm trying to use an HTML server, as a temporary initial configuration UI, and then once the post request from the client is received, shut down and deep sleep. I'm chasing efficiency as this is a battery application and Im noticing that

wlan.disconnect()
wlan.active(False)

Does not shut down the radio, as I'm .07mA higher than without ever starting it during deep sleep. Doing some searching I've found that this is somewhat to be expected as the esp8266 required additional commands ( https://forum.micropython.org/viewtopic.php?t=2734 ) to be sent to completely shut off the WIFI radio. Basically I'm on the hunt for how to turn this radio off, without completely shutting down the cpu.

Greatly appreciate any time or info you might give.

[danjperron]

I was able to go lightsleep on my PicoW solar garden with 2ma by using deinit()

wlan.disconnect()
wlan.active(False)
wlan.deinit()
wlan=None
time.sleep_ms(100)

I also use the watchdog but you can't have sleep more than 8 seconds so I create a small light sleep
check my code on my solar garden to figure out what I did to solve the problem of the watch dog.
(https://github.com/danjperron/PicoWSolar)

[jimmo]

@dpgeorge

So for a station interface there are six levels (these current values include the 20mA baseline)

1. up (31mA)
2. active (37mA)
3. connected (41mA)
4. disconnected-still-active (37mA)
5. inactive (37mA)
6. deinitialised (20mA)

Like you say, the transition from deinitialised back to up/active takes ~3s at 60mA.
The "up" state is only reachable via using a GPIO pin multiplexed on the CYW43 (e.g. the LED). You can only get back to it via deinit.

deinit also affects both interfaces (i.e. if you deinit the station, it also takes out the ap).

So I guess I don't really understand why deinit() needs to exist -- i.e. what need is there for state 5, given that states 4&5 use the same power? Instead, if both the station and the ap are inactive, then why wouldn't I want the cyw43 to be shut down?

The GPIO multiplexing makes this more complicated... perhaps ideally making both interfaces inactive could get us back to state 1, in which case state 5 would be a middle-ground (31mA) between off (20mA) and active (37mA).

[danjperron]

@jimmo
How come you get 20ma after deinit(). Are you doing lightsleep() also? I Get 2ma when I do deinit() follow by lightsleep().
Do you have something else attached to the Pico which draw current from any GPIO?

Also when the Pico wake up from lightsleep I just reconnect the wifi and up it goes. Its on a while True: loop.

[dpgeorge]

I guess it makes sense for active(0) to properly power down the CYW43. That would make it consistent with active(1) powering it up. And also be more obvious on how to use it (as evident by the initial question of this discussion).

[jmodrako]

@danjperron what firmware are you running on your Pico W?

[danjperron]

Right now my picow is inside a storage box waiting for the spring to come up . It was made to record data about my garden. Then it should be the release available in the last summer. I won't be able to tell you until this spring when I put it on the garden. (It's in my shed with 3 feet of snow all around). You have my github on one of my post which contains the micropython code and schematic.
N.B. on the schematic I specify that I removed the TP4056 but If you have better solar cell you don't need to. I could check again with one of my spare picow how much current it draws with the latest build.

[danjperron]

Le 14 févr. 2023 à 09:31, Jacek Modrakowski ***@***.***> a écrit : @danjperron <https://github.com/danjperron> what firmware are you running on your Pico W? — Reply to this email directly, view it on GitHub <#9135 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBF7XAXKYSGS7OYFD7PDDLWXOJL5ANCNFSM575HDZ6Q>. You are receiving this because you were mentioned.

Jacek I could confirm that machine.lightsleep() doesn’t work very well with the new firmware. It was working and still works with this one rp2-pico-w-20220817-unstable-v1.19.1-286-g98bd7e33b.uf2 But with the newest nope! I tried this one rp2-pico-w-20230217-unstable-v1.19.1-878-g4598b89ce.uf2 Event a simple loop with no import hangs after few light toggle led=machine.Pin(‘LED’,machine.Pin.OUT) while True: led.value(1) machine.lightsleep(1000) led.value(0) machine.lightsleep(1000) regards, Daniel Perron

[jmodrako]

Yeah, I do have the same problems... I will try the firmware you mentioned otherwise I will rewrite my code to C++...

[danjperron]

I found a small bug in my code about the watchdog. It is in ms and not in µs. I also included the august 2022 uf2 firmware in my GitHub. https://github.com/danjperron/PicoWSolar danjperron/PicoWSolar github.com Daniel

…

Le 19 févr. 2023 à 04:34, Jacek Modrakowski ***@***.***> a écrit : Yeah, I do have the same problems... I will try the firmware you mentioned otherwise I will rewrite my code to C++... — Reply to this email directly, view it on GitHub <#9135 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBF7XBRO5K53H6APILLON3WYHSI7ANCNFSM575HDZ6Q>. You are receiving this because you were mentioned.

[jmodrako]

Awesome, I will try this firmware :)

[danjperron]

Ok the work around has been discussed here
ac0a135

On modmachine.c just change the line 149 to if (cyw43_has_pending && cyw43_poll != NULL)

I recompiled the most recent micropython with the modification and it is working fine!

ex: post mqtt around every 30sec compare to 5sec before which was no sleep at all.
daniel@linuxserver:~$ mosquitto_sub -t "#" -v | xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T $0"'
2023-03-03 10:05:15 PicoW2/TempCPU 27.981
2023-03-03 10:05:15 PicoW2/Vsys 4.796
2023-03-03 10:05:45 PicoW2/TempCPU 27.044
2023-03-03 10:05:45 PicoW2/Vsys 4.801
2023-03-03 10:06:15 PicoW2/TempCPU 27.044
2023-03-03 10:06:15 PicoW2/Vsys 4.801
2023-03-03 10:06:45 PicoW2/TempCPU 27.044
2023-03-03 10:06:45 PicoW2/Vsys 4.796