ESP8266 Community Forum

- Tue Dec 01, 2020 9:49 am #89658 Unfortunately I cannot, like most users do, just go to sleep to save power.
Please let me repost my question in this foldr, since on the general folder everybody recommended to ask here:

My instruments need a processing every 125 ms, a precise timing and network updates every second.
on the top of it, I need OTA.
What can I do, to save power?
I have seen, that the ESP8266 powers down the energy hungry WiFi interface during delay(); instructions.
But, my timing requires millis();
What can I do to power down WiFi without delay() just for the rest of my time budget?

Additionally, how much WiFi does the ArduinoOTA.handle(); consume and how frequently must it be run to be able to update a new sketch, while accepting a few minutes delay?

Thank you for your help

The code I use is a bit complex, for those wanting to look at it, it is here:
https://github.com/rin67630/SPL-Booster

- Wed Dec 02, 2020 6:51 am #89672 The only way I know of to save any power is to find a way to incorporate delay() into your time calculations. The modem only sleeps during delay() between WiFi transmissions, either TIM beacons or your network transmissions, both of which are around the same 100-125ms period from your description. You won't get much of a savings even with delay() since you're hitting the network so frequently. Any WiFi transmission (not counting beacons) will wake the modem at >67mA full power, and it will stay on for up to 2 seconds after it's wakened. It can sleep between beacons, but not between your rapid network updates.

There are two different modes that can achieve modem sleep:
1) Automatic Modem Sleep drops to 15mA between beacons or WiFi transmissions. This is the default power saving mode, and happens with any connection in STA mode during delay().
2) Automatic Light Sleep drops to 2mA between beacons or WiFi transmissions, again only in STA mode and only during periods of delay(). You can only achieve Light Sleep in a network with sparse traffic (the TIM beacons don't count), and the 125ms update rate for your instruments will insure that it can't ever go into Light Sleep.

I can't find it documented, but I vaguely remember the timeout on OTA checks is around 10 seconds, so I don't think you need to test more often than that. That's a limit in espota.py?, not the ArduinoOTA library. The acknowledge is a single UDP 'ok' packet, pretty brief.

- Wed Dec 02, 2020 8:11 am #89673 Thank you very much @Stanj for your confirmation of my findings. I appreciate it a lot!
I will have to live with that facts.
The network updates are at 1s, not 125mS. But even that is too frequent...
I probably cannot hope to reduce the consumption if i need to update every 1second.

I will now look if I can buffer 8 seconds of data into an array and transmit it as a frame every 8 seconds together with the OTA check, putting the modem into sleep for tiny 50ms delays every 125ms in between, maybe that could help to reduce average mA by 30%.

That will complicate the process and add an awful latency, but i probably have got no chance to do otherwise.

- Wed Dec 02, 2020 7:19 pm #89676 Sorry, I misunderstood your initial description. If processing your instruments every 125ms doesn't take that whole 125ms time, then you might be able to set an ets_timer to 125ms, process the hardware, do an RF squirt every 8 times through, then go to 'idle' / delay() until woken by the ets_timer again. You won't get down to the Automatic Light Sleep level of 2mA, but you might get some Automatic Modem Sleep savings, depending on what your network traffic is like. I was seeing pings keep the modem on for 100ms to 2s (worst case). It purely depends on what your network traffic does. If your traffic doesn't trigger the modem to stay on for long periods, you might see a 50% reduction in total power or more.