rtctime.dsleep(, 4) does not turn off the WiFi

[joysfera]

Expected behavior

rtctime.dsleep(1, 4) should turn off the WiFi just like node.dsleep(1, 4) does. This can be confirmed most easily by measuring the current flowing into ESP8266. With WiFi turned off it should drop dramatically from 70 mA down to 12 mA.

Actual behavior

The current consumption is high (~ 70 mA) after waking up no matter of the "option" parameter value.

Test code

rtctime.dsleep(1, 4)

NodeMCU version

Lua 5.1.4 on SDK 1.5.4.1(39cb9a32)

Hardware

plain ESP8266 version 07. GPIO16 wired to RST.

BTW

I looked into the source code and noticed just one little difference between node.dsleep() and rtctime.dsleep() - the former uses option = lua_tointeger while the latter uses option = lua_tonumber. No idea if this could be say zeroing the option value that would in turn cause the observed behavior.

The rtctime.dsleep_aligned() suffers from the same issue, IIRC.

This is a serious issue for anyone who tries to create a low power application with running system time. Thank you in advance for looking into this.

[marcelstoer]

The docs don't mention why the two functions should behave differently in this respect. @jmattsson is this just an oversight?

[jmattsson]

Nope, that is not an oversight. It used to work. I suspect something has changed in the SDK to have broken this. One of the gripes with the "regular" dsleep was that the SDK just set a 200ms timer to do the actual shutdown, which was burning way too much power for our use here. Thus @umisef reverse-engineered the then-current SDK shutdown code and used that to create an "instant" version of it.

What's described here makes it sound like the SDK doesn't actually save the option value before it returns from system_deep_sleep_set_option(). @umisef is currently on leave so I'll have to leave a note for him (unless you want to catch him at the Mont Blanc ultra marathon this weekend and give him something to think about =) ). He should be back in a week and a half.

Another thought: I don't suppose the sleep options got changed/deprecated when they introduced the user_pre_rf_init() support? In theory I think that could be used to provide the same feature.

[joysfera]

FYI, with build from commit 3328c66 and with all the other power saving methods (sleeptype, setmode) active the rtctime.dsleep(,4) did wake up with a sleeping modem. I'm not sure what is the right setting that helped to fix the original issue - would have to try out all 8 combinations (or how many are there) - but the good news is that it is possible to use rtctime for sleeping and have the modem disabled after waking up.

[neilyoung]

In fact, this issue is still present. rtctime.dsleep(1, 4) behaves different compared to node.dsleep(1,4). It is not even necessary to measure the power. Just join an AP and check the output of wifi.eventmon. With node.dsleep(1,4) the response after wakeup is always DISCONNECTED, whereas rtctime.dsleep(1,4) gives CONNECTED after waekup.

Too bad, rtctime.dsleep was an alternative because of the better accuracy. But so it doesn't really work

[neilyoung]

If I change the code of rtctime_dsleep that way

   // rtctime.dsleep (usec, option)
   static int rtctime_dsleep (lua_State *L)
   {
     uint32_t us = luaL_checknumber (L, 1);
     do_sleep_opt (L, 2);
    // rtctime_deep_sleep_us (us); // does not return
	   system_deep_sleep(us);
     return 0;  
   }

the option is acknowledged. Any ideas?

[tardyp]

@umisef back from the montblanc? Could you please give a bit of starting point of what tool did you use to reverse engineer the sleep procedure?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.