[@eyal’s post]
Following up on the esp8266 talk this evening, here are the timings that I see.
My esp8266 app starts 75ms after wakeup, WiFi is up 40ms later and deep sleep is requested at 320ms (from wakeup). The DSO shows power usage drops at around 550ms so it takes a long time (230ms) to enter deep sleep. Here is a DSO capture. Note the total power usage is just 41mAs for the full cycle, with idle WiFi current of 80mA and short peaks up to 288mA. The trigger is the reset (=wakeup) signal.
[later] Following up after the discussions of the 11/May meeting.
I am testing a setup where I do not make any WiFi connections (as Ken plans to do). First, here is what it looks like:
The full cycle takes 245ms. There is now a short pink (ch3) showing. This is the actual app, which is lua:
start_time = tmr.now()
-- node.setcpufreq(node.CPU160MHZ)
out_pin = 2 -- gpio4
gpio.mode (out_pin, gpio.OUTPUT)
gpio.write(out_pin, gpio.HIGH)
magic_pin = 1 -- gpio5
abort = false
if magic_pin and magic_pin >= 0 then
gpio.mode (magic_pin, gpio.INPUT, gpio.PULLUP)
if 0 == gpio.read (magic_pin) then
print (("aborting by magic, start time %.6f"):format(start_time/1000))
abort = true
end
end
if not abort then
gpio.write(out_pin, gpio.LOW)
wifi.sta.autoconnect(0)
wifi.sleeptype(wifi.MODEM_SLEEP)
node.dsleep (500000, 4) -- 100ms, no WiFi
end
Note the ‘gpio.write()’ which sets a pin HIGH at the start and LOW at the end. This is what ch3 is showing. So the bulk of the time is not in the app at all.
I measured 145ms from the trigger to ch3 rising. It then takes about 100ms to enter deep sleep.
However, the more interesting point is that I also print the time (if magic_pin is low) and this shows 70ms, not 145 as the DSO shows. I do not understand why this is so, unless the timer does not start at power up.
I also do not know what the high peak (at 400-500mA) is, when the WiFi is supposed to be disabled. Generally, I expected the stable power usage to be more like 30-40mA rather than the 70-80 that I see (same as when WiFi is on).
I probably am not turning it off correctly.
BTW, if I do a node.restart() (not node.dsleep()) then it shows 267ms.
I now tested a bare esp8266 (rather than the NodeMCU module used here). Similar timing but less power used, peaking at below 330mA. Still unexplained though.
[later] I think I managed to turn off wifi somewhat with the two wifi.*() calls. Note that ch3 is inverted here.
70mA is still too high, the wifi engine is not fully turned off.
[end of @eyal’s post]
Very interesting @eyal but unlikely to be found under the heading “Can anyone run Electronics Wednesday this week?” I’ve been looking for this sort of information elsewhere and I haven’t found this level of detail. It deserves it’s own topic.
I’m having some trouble understanding though. For example I can’t understand where the 145 is in “However, the more interesting point is that I also print the time (if magic_pin is low) and this shows 70ms, not 145 as the DSO shows. I do not understand why this is so, unless the timer does not start at power up.”
I can suggest a reason the timer does not start at power up though. According to Boot Process · esp8266/esp8266-wiki Wiki · GitHub it has a BIOS. It “Boots into Espressif code in IROM0” . This must check the pins etc to decide what to do next e.g. go into flash mode, then it “Loads SPI ROM data” which means the Espressif SDK libraries from one address and your program code which resides in another Memory Map · esp8266/esp8266-wiki Wiki · GitHub. Finally it starts executing user code. I guess that the timer you are reading is started just after the “Loads SPI ROM” data step before starting user code.
I don’t understand this line either
“if I do a node.restart() (not node.dsleep()) then it shows 267ms.”
but perhaps a different startup time is due to not having to do the “Loads SPI ROM data” step in one version.
You mention that the radio is not fully off. There is an interesting Arduino deep sleep library at IoT/ESPDailyTask at master · HarringayMakerSpace/IoT · GitHub . I’m wondering whether the radio is fully off in their version. They also use the RTC timer to keep reasonably accurate time across deep sleeps and according to GitHub - liangchen-harold/nodelua Lua is interpreted rather than compiled which would suggest that Arduino, being compiled, should have a faster cycle time.
Looking forward to some more help interpreting this data at the next MHV meet up.
