Espruino Wifi Power Consumption in Deep Sleep at 2mA

Posted on
Page
of 2
/ 2
Next
  • Really enjoying getting to know my Espruino Wifi. I'm trying to build a test simple device that wakes on a button press and sends a signal. I want it to be battery powered so was super excited about the very low power consumption in deep sleep mode and easy wake on interrupt.

    When I set this up to wake on a signal to A0, and then go back to sleep I still get a current draw of 2.3 mA (not the hoped for 0.05 mA). Is there something that I need to instruct to power down (like explicitly telling the wifi to power down) to get to the low power consumption?

    pinMode(A0, 'input_pulldown');
    setSleepIndicator(LED1);
    
    setWatch(function() {  
    
      // doing stuff
      console.log("doing stuff");
    
      setTimeout(function(){
          console.log("Going to sleep again");
          setDeepSleep(1);
        }, 2000);
      
    }, A0, {repeat: true, edge: 'rising'});
    
    console.log("Going to sleep");
    setDeepSleep(1);
    

    Thanks in advance,
    Narath

  • Thr 2020.02.20

    Hi @narath, and thank you for your interest in the world of Espruino!

    Not able to respond with an intuitive answer just yet, but which version of Espruino is currently flashed? It's possible that recent updates have improved on sleep mode.

    Please post the result of process.env


    'I still get a current draw of 2.3 mA (not the hoped for 0.05 mA)'



    How is the Wifi device being powered?

     

    Ref calc
    L1 pinMode(A0, 'input_pulldown');
    p.96   http://www.espruino.com/datasheets/STM32­F411xE.pdf

    Typical 40K
    Checking: 3.3 / 40,000 = 0.000 082



    Are there any LED's on? What does the switch resistor(s) on 'A0' or input cirucit appear like? Is there a resistor constanly drawing current during the test? A picture might assist us here.



    Are you able to confirm ALL the five listed items beneath 'you must' heading 'Conditions for Deep Sleep'

    http://www.espruino.com/Power+Consumptio­n

  • Hi Robin,

    Thanks for the thoughtful reply. Some responses:

    >process.env
    ={
      VERSION: "2v04",
      GIT_COMMIT: "3956264e",
      BOARD: "ESPRUINOWIFI",
      FLASH: 524288, RAM: 131072,
      SERIAL: "41006e00-0b513532-39333638",
      CONSOLE: "USB",
      MODULES: "Flash,Storage,hea" ... ",neopixel,Wifi,AT",
      EXPTR: 536871212 }
    > 
    

    It was being powered by a LiPoly battery (also tested it with USB power breakout - with the same result).

    Have no external LEDs. Had set the SleepIndicator as per the code, but turning that off did not seem to change anything.

    The pull down resistor was 10K, I increased this to 100K and it did not change the current draw (and the button still worked). Picture of that attached.

    I have noticed that there is a small blue LED on the Espruino that is faintly active when powered by battery.

    Thanks again for your help. Hopefully we can get this down to 0.05mA


    2 Attachments

    • blueled.jpg
    • wiring.jpg
  • Hey Robin, and yes - all 5 conditions for deep sleep should be met.

  • Sat 2020.02.22

    Thank you @narath for the images as they provide immense confirmation. That said, I'm with you on this one, with your attention to detail following the tutorial, and am a bit baffled myself.

    Up to date firmware. Check Running on battery, not USB. Check - okay.

    Do we know the limits on the current measuring meter. Do we have a spec sheet indicating it's limits? e.g. can it measure down beneath milliamp to microamp?


    From post #1 L2 setSleepIndicator(LED1);

    Beneath heading 'Debugging Sleep'

    'You can call setSleepIndicator(LED1). LED1 will then be lit whenever the device is not sleeping'
    http://www.espruino.com/Power+Consumptio­n

    Does the Red LED1 illuminate ever? (and it's opposite state)


    ' (also tested it with USB power breakout - with the same result)'

    As it was indicated that all five bullet items, post #4 were confirmed, it is known that power save mode will not work using USB.

    'to instruct to power down (like explicitly telling the wifi to power down)'

    This may be the clue, although I am not able to say definitively, as I'm unable to locate specific documentation on the Blue LED and it's indication under battery usage.

    Nothing jumps out from the programmability side of things:

    http://www.espruino.com/Reference#Wifi

    Has the powersave parameter been supplied an argument to test that as an option?

    http://www.espruino.com/Reference#l_Wifi­_setConfig

    The note that followed indicated for ESP8266, so maybe disregard?

     

    Fifth bullet item below 'Features'

    Three on-board LEDs (2x user programmable, 1x WiFi activity) and one button
    http://www.espruino.com/WiFi

     
    Typically, the user defined ones are LED1 and LED2, Red and Green. I'm making the assumption, and I feel that from your comment above you are in agreement, that the Blue LED is indicating the WiFi is attempting to turn on. As we know LED's can be power hogs, even when dimmed, this is likely causing the high current draw. But I'm not able to provide a solution on how to resolve that, just yet.


    See note beneath heading 'Saving Power' regarding pinMode.

    http://www.espruino.com/Power+Consumptio­n

    I suppose it might be possible that one or more of the output pins are taking on a state, not being explicitly defined. Maybe (a bit redundant though) setting every pin to a known state might provide a bit more peace of mind.

    Hang in there, I'm sure someone with a bit more knowledge or even been down this path will now have enough information to provide the answer.


    EDIT:
    Checking the schematic, there is a note referring to 'Debug output' on the Blue LED line, also limited by a 100 ohm resistor.
    https://github.com/espruino/EspruinoBoar­d/blob/master/WiFi/pdf/espruino_wifi_sch­.pdf

    But, that must be for full on, as:

    3.3 / 100 = 33ma

    which is much higher than the value that was mentioned earlier. Also, I thought that maybe the 10K might be 'on' all the time, but that doesn't appear to be the case either:

    3.3 / 10 000 = 0.000 330

  • Hi Robin, thanks for sticking with me on this.

    Do we know the limits on the current measuring meter. Do we have a spec sheet indicating it's limits? e.g. can it measure down beneath milliamp to microamp?

    It can go from milli down to microamps.

    'You can call setSleepIndicator(LED1). LED1 will then be lit whenever the device is not sleeping'

    http://www.espruino.com/Power+Consumptio­n
    

    Does the Red LED1 illuminate ever?

    It does when I have the chip "doing stuff", but then does go off after setDeepSleep(1).

    As it was indicated that all five bullet items, post #4 were confirmed, it is known that power save mode will not work using USB.

    Yes - thanks, had noticed this when trying to test sleep while connected through the Web IDE :-)

    'to instruct to power down (like explicitly telling the wifi to power down)'
    This may be the clue, although I am not able to say definitively, as I'm unable to locate specific documentation on the Blue LED and it's indication under battery usage.

    I see that the blue led is faintly lit on the top surface and another blue led on the undersurface. It does seem that there might be some ongoing power to the 8266 chip.

    I have tried reflashing the Espruino and then upgrading the Esp8266 chip. Has not changed the power consumption.

    http://www.espruino.com/Reference#Wifi
    Has the powersave parameter been supplied an argument to test that as an option?
    http://www.espruino.com/Reference#l_Wifi­_setConfig

    Interestingly, that is not an option for me. I get an error when trying to setConfig on wifi:

    >var wifi = require("Wifi");
    ={
      connect: function (a,b,c) { ... },
      disconnect: function (a) { ... },
      startAP: function (a,b,c) { ... },
      stopAP: function (a) { ... },
      scan: function (a) { ... },
      getIP: function (a) { ... },
      setIP: function (a,b) { ... },
      getAPIP: function (a) { ... },
      setAPIP: function (a,b) { ... },
      setHostname: function (a,b) { ... },
      ping: function (a,b) { ... },
      turbo: function (a,b) { ... },
      debug: function () { ... }
     }
    >wifi.debug()
    ={ wifiMode: 0, connected: 0,
      socks: [  ],
      sockData: [
        "",
        "",
        "",
        "",
        ""
       ]
     }
    >wifi.setConfig();
    Uncaught Error: Function "setConfig" not found!
     at line 1 col 6
    wifi.setConfig();
         ^
    

    Typically, the user defined ones are LED1 and LED2, Red and Green. I'm making the assumption, and I feel that from your comment above you are in agreement, that the Blue LED is indicating the WiFi is attempting to turn on. As we know LED's can be power hogs, even when dimmed, this is likely causing the high current draw. But I'm not able to provide a solution on how to resolve that, just yet.

    Thanks - it looks like setDeepSleep might not be appropriately powering down the wifi, or the wifi leds.

    See note beneath heading 'Saving Power' regarding pinMode.
    http://www.espruino.com/Power+Consumptio­n
    I suppose it might be possible that one or more of the output pins are taking on a state, not being explicitly defined. Maybe (a bit redundant though) setting every pin to a known state might provide a bit more peace of mind.

    Will certainly try this if no further progress. I suspect based on https://www.electro-tech-online.com/arti­cles/achieving-low-power-on-adafruit-tri­nket.830/ that this would only account for a few micro amps.

    Thanks again for your help. Hoping we can get to low power sleep at some point.

  • Sat 2020.02.22

    'Hi Robin, thanks for sticking with me on this.'

    Ahhhh, you wouldn't know this, but I have a bit of a selfish reason to do so. Eventually, I'll get around to battery powering, then this will come in handy!

    'Interestingly, that is not an option for me. I get an error when trying to setConfig on wifi'

    Had a hunch that the note regarding ESP8266 might reign here, and your trial seems to confirm that. It is still good info though.

    Unless there are other power users that see this in the short term, there (most likely) is enough here for @Gordon to pipe in, but as he is a bit underwater with the Bangle KickStarter, it might take a few days. In any event, he may need to take a break from flashing those ~1000 units, and welcome this as a nice diversion!!

    p. 73 indicates that the designated mimimum is achievable:

    http://www.espruino.com/datasheets/STM32­F411xE.pdf

    So, my hunch is that as we know the LED full on is 33mA and it is currently dimly lit, that it's ~3mA draw is likely the culprit.

  • I see console.log("doing stuff"); in your code, but no serial port connected on the picture. Do you have data waiting at the serial port?

  • Sun 2020.02.23

    Good catch @maze1980.

    L10 console.log("Going to sleep again");

    It's very likely L7 is processed but not line 10, as the watch would trigger on the rising edge as the button is released. Two seconds elapse, the L10 log message is cued and Espruino immediately executes and enters Deep Sleep long before the (same for L16) log message is processed.

    EDIT: then again maybe not - Note from Power Consumption
    Bullet 3 'Not have any data waiting to be sent down Serial or USB'
    Note: Espruino won't enter deep sleep as soon as you execute setDeepSleep(1). It'll wait until all the bullet points above are satisfied, and then it'll enter it.

  • Hi! Yes, this could be an issue with the default config of the WiFi pins... Most of the testing would have been done after having turned WiFi on then off.

    Does:

    var wifi = require("Wifi");
    wifi.disconnect();
    

    help you at all?

    edit: wifi.setConfig's docs mention that it is only for ESP8266/32 boards - there's nothing in the WiFi for it.

  • Thanks all.

    @Robin and @maze1980 re console: it did not make a difference when I did not include these messages.

    @Gordon: unfortunately wifi.disconnect() does not change power consumption, and surprisingly does not change the small blue light on the top or bottom.

  • Hi - I've just looked into this, and found it was due to the pin state on the boot mode selection pin of the WiFi board.

    I've now made some changes to the firmware which will be in the 2v05 release (when it happens), or are in 'cutting edge' firmwares downloaded from http://www.espruino.com/binaries/travis/­master right now.

    However, you should be able to get the same effect just by adding A13.read(); to your code.

  • Awesome Gordon! Thanks will try it out and let you know.

  • Added this to my code:

    A13.read();

    And the blue led is now off.

    The power consumption in sleep unfortunately still seems to be around 2.3 mA

  • Wed 2020.02.27

    'And the blue led is now off'

    YIPEE !!

    'still seems to be around 2.3 mA'

    Didn't expect it to be close to the same, but a bit more of a lesser value.

    Can we confirm that we don't have an off by 1000 setting on the current measuring device? I've burned myself thinking uA but reading mA and vice-versa

    Time for a 1% resistor and battery only circuit to prove out the meter will actually read that on the low end? e.g. the meter can actually read below 2uA

  • Please can you post up your finished code? It's possible that if you're still calling wifi.disconnect() (my previous suggestion), it is undoing the work of A13.read();...

  • Okay - I am a believer!

    Great suggestion by @Robin

    Time for a 1% resistor and battery only circuit to prove out the meter will actually read that on the low end? e.g. the meter can actually read below 2uA

    I used a 100K resistor on the battery circuit and verified getting uA readings.

    Then tested the espruino with the A13.read() and got the readings seen below with pressing the button (no wifi, just turns on, then sets sleep mode)


    1 Attachment

    • Screen Shot 2020-02-27 at 10.59.29 PM.png
  • And then when going to sleep got this!! 0.03 mA - in the microAmp category - woot!


    1 Attachment

    • Screen Shot 2020-02-27 at 10.59.43 PM.png
  • I will be getting an oscilloscope this weekend and will do more testing (esp launching wifi and then disconnecting before sleep), but so far this seems very promising. Thank you both for your help.

  • Thr 2020.02.27

    I like the positive feedback image of the stand in actor, in the lower image, side left. How much additional was needed (bribe) for that shot?

    So, was it as simple as just powering down the device, thus clearing memory, or was it discovered the meter was upside down?   ;-)

    . . . . or,

    'And then when going to sleep got this!! 0.03 mA'

    a discovered code anomaly, breadboard issue, unknown?

    Has setting the pinMode to known states been included yet? suggestion from #5 post - and second sentence from last response in #6 post

  • Great! Not quite sure I understand though - what did you change that managed to get it to the lower power consumption?

  • Hey guys, unfortunately - Gordon was right - without me clearly knowing what I had changed to fix it - it returned to it's previous power consumption. I did get an oscilloscope, but unfortunately no current probe (I have a shunt resistor, but have no differential probe, so have not tried reading it yet). I did get an analog meter as well, and it gets the same power reading.

    @Gordon, here is my current code on the device:

    pinMode(A0, 'input_pulldown');
    A13.read();
    
    setSleepIndicator(LED1);
    
    function doStuff() {
      console.log("doing stuff");
    
      setTimeout(function(){
          console.log("Going to sleep again");
          setDeepSleep(1);
        }, 500);
    }
    
    setWatch(function() {  
      console.log("A0 pressed");
      doStuff();
    }, A0, {repeat: true, edge: 'rising', debounce: 10});
    
    console.log("Going to sleep");
    setDeepSleep(1);
    

    @Robin, seems reasonable to explicitly set the pinmodes: pinMode looks like it can be all of these: analog', 'input', 'input_pullup', 'input_pulldown', 'output', 'opendrain', 'af_output' or 'af_opendrain'.

    These are the pinModes I expect to set, what would you recommend the others be set to:

    pinMode(A0, 'input_pulldown');
    pinMode(A1, 'input_pulldown');
    A13.read();
    

    The pins I expect to set are: A4, A5, A6, A7, B0, B1, B3, B4, B5, B6, B7, B8, B9, B10, B13, B14

    Best,
    Narath

  • Sun 2020.03.01

    Link from post #7 p.96 indicates pull-up and pull-down of 40K nominal. Although I can't find the post just yet, there was a suggestion to set to a known state. Still searching. The other idea was to use getPinMode() to see what the defaults are at start-up and see if they remain in that state.

    Regarding the code snippet, ref L9 I've had issues with timers running after cut-n-paste into the Lefthand console side of the WebIDE, under the assumption they were cleared. From another post I use the following to see if any are running:

    console.log(global["\xFF"].timers); //nice, less info
    trace(global["\xFF"].timers); //full info
    

    It might be that constantly pressing the button creates a new timer instance L9, leaving the previous there in memory. Should that be the case, code might be running not allowing the deep sleep state to occur. Just a guess, but worth checking.

  • Thanks for sending over the code. The pulldown mode seems reasonable (as long as you don't have a normally-closed switch that's constantly pulling against it!). Also you'd see LED1 (your sleep indicator LED) blinking if you had something waking the WiFi up.

    Please could you ensure that you've uploaded your code to Flash? That might be your issue.

    Either that or add:

    function onInit() {
      A13.read();
    }
    

    There's some info on http://www.espruino.com/Saving

    But basically: When you save to RAM the code executes right away, and when you then run save() Espruino effectively 'hibernates', writing the current state of the interpreter to flash and reloading it at boot.

    The issue here is that because it knows that A13 is a pin that's used internally by WiFi, Espruino WiFi may not save the state of that pin for you, so after the initial upload the A13.read() command may not have an effect.

  • I see console.log("doing stuff"); in your code, but no serial port connected on the picture. Do you have data waiting at the serial port?

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino Wifi Power Consumption in Deep Sleep at 2mA

Posted by Avatar for narath @narath

Actions