MODEM_SLEEP_T and system idle task

[andrewtinkers]

In the documentation, MODEM_SLEEP_T seems like a great way to keep the wifi connection alive, yet still saving power.

However, I see some indeterminate behavior:

Most of the time, after a http request, I see the modem turn off, and the current draw drops from ~60mA to ~15mA within a second. And then there are short keep-alive connections later. This is expected.

However, sometimes after the http request, the modem stays on for 5 seconds, 10 seconds, even minutes. What determines this? Is it because we haven't hit a system idle task yet? If so, is there a way to debug which task is executing and preventing the system idle task?

Thank you!

[Her Mary]

Maybe because of the idle task, but the more likely reason is the DTIM of your router.

[andrewtinkers]

I see it go into DTIM mode later actually. I attached a oscilloscope capture. There is a steady modem on period (RX I guess?) and then later it goes into DTIM, which is characterized by 15mA base, with 60mA spikes at a regular interval. I'm trying to figure out what the long 60mA bit is. This tail is always after a successful http transaction. And sometimes it is 500ms long, sometimes it can be as long as 10 seconds. I'm trying to figure out why, and how to make it consistent.

[andrewtinkers]

Or, if it is really due to waiting for DTIM, is there a way to check, or to set a timeout? Or is this all in the sdk, and not accessible by developers?