Espruino Wifi Power Consumption in Deep Sleep at 2mA

[espruino-discuss]

Posted at 2020-02-21 by narath

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

[espruino-discuss]

Posted at 2020-02-21 by Robin

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/STM32F411xE.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+Consumption

---

Posted at 2020-02-22 by narath

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

---

Attachments:

• blueled.jpg
  
• wiring.jpg

---

Posted at 2020-02-22 by narath

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

---

Posted at 2020-02-22 by Robin

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+Consumption

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+Consumption

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/EspruinoBoard/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

---

Posted at 2020-02-22 by narath

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/articles/achieving-low-power-on-adafruit-trinket.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.

---

Posted at 2020-02-22 by Robin

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 @gfwilliams 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/STM32F411xE.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.

---

Posted at 2020-02-23 by maze1980

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?

---

Posted at 2020-02-23 by Robin

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.

---

Posted at 2020-02-24 by @gfwilliams

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.

---

Posted at 2020-02-24 by narath

Thanks all.

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

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

---

Posted at 2020-02-25 by @gfwilliams

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.

---

Posted at 2020-02-26 by narath

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

---

Posted at 2020-02-27 by narath

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

---

Posted at 2020-02-27 by Robin

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

---

Posted at 2020-02-27 by @gfwilliams

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();...

---

Posted at 2020-02-28 by narath

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)

---

Attachments:

• Screen Shot 2020-02-27 at 10.59.29 PM.png

---

Posted at 2020-02-28 by narath

And then when going to sleep got this!! 0.03 mA - in the microAmp category - woot!

---

Attachments:

• Screen Shot 2020-02-27 at 10.59.43 PM.png

---

Posted at 2020-02-28 by narath

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.

---

Posted at 2020-02-28 by Robin

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

---

Posted at 2020-02-28 by @gfwilliams

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

---

Posted at 2020-03-01 by narath

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.

@gfwilliams, 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

---

Posted at 2020-03-02 by Robin

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.

---

Posted at 2020-03-03 by @gfwilliams

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.

---

Posted at 2020-03-03 by maze1980

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?

---

Posted at 2020-03-03 by Robin

Tue 2020.03.03

Hi @maze1980 I see that post #25 is identical to post #8

Maybe the edit to post #9 from a week ago was missed? While your concern is valid, the additional note indicates deep sleep couldn't occur in that case. I believe that @narath addressed that, but I'll agree there doesn't appear to be a validation from him.

---

Posted at 2020-03-04 by narath

@gfwilliams - I was using the following commands to save:

1. reset()
2. Upload using IDE with Communication Mode > Save On Send > RAM
3. save()
4. dump() to check what was written

Interestingly, the Blue LED is now showing again, and A13.read() no longer turns it off, nor does wifi.disconnect();

I did download the latest edge firmware and flash it - unfortunately no change - power consumption still 2.3 mA

---

Posted at 2020-03-04 by narath

@maze1980 - thanks for pointing that out. I removed all the console lines - and the same power consumption.

@robin - I tried checking all the pin modes - they don't seem to change. I used this code:

console.log("A0 = ",getPinMode(A0));
console.log("A1 = ",getPinMode(A1));
console.log("A4 = ",getPinMode(A4));
console.log("A5 = ",getPinMode(A5));
console.log("A6 = ",getPinMode(A6));
console.log("A7 = ",getPinMode(A7));
console.log("B0 = ",getPinMode(B0));
console.log("B1 = ",getPinMode(B1));
console.log("B3 = ",getPinMode(B3));
console.log("B4 = ",getPinMode(B4));
console.log("B5 = ",getPinMode(B5));
console.log("B6 = ",getPinMode(B6));
console.log("B7 = ",getPinMode(B7));
console.log("B8 = ",getPinMode(B8));
console.log("B9 = ",getPinMode(B9));
console.log("B10 = ",getPinMode(B10));
console.log("B13 = ",getPinMode(B13));
console.log("B14 = ",getPinMode(B14));

And got this output:

A0 =  analog
A1 =  analog
A4 =  analog
A5 =  analog
A6 =  analog
A7 =  analog
B0 =  analog
B1 =  analog
B3 =  analog
B4 =  analog
B5 =  analog
B6 =  af_output
B7 =  af_output
B8 =  analog
B9 =  analog
B10 =  analog
B13 =  analog
B14 =  analog

---

Posted at 2020-03-04 by Robin

Tue 2020.03.03

@narath thank you for the validation and pin mode output as that will assist us all.

'Interestingly, the Blue LED is now showing again'
'I did download the latest edge firmware and flash it'

Please post process.env for Gordon, thanks.


Regarding pin mode. Now I'm a bit befuddled. In post #22 I was under the impression that it would be intentional to set A0 and A1 to 'pulldown' however the output is showing 'analog'.
Was this done on immediate power-up with no code saved and just uploading the getPinMode() code snippet?

Please see Gordon's comment in post #24 before setting all to a known state. Has that suggestion been tried? When done, please post pre and post pin mode output to verify none are changing.

I wish I could find the post, (first read by me around three months ago - @allObjects was this one of yours?) that provided some insight as to setting to a known state, and the consequences that might result if not done. (even after chip power on to it's default state)

EDIT Thr 2020.03.05:
Found it!! But specifically for nRF and not STM
At minimum, read post #15 thru post #17
http://forum.espruino.com/comments/14608669/

Also remember a comment, but I think pertained to USART port pins, about not leaving in a certain state as that left the oscillator on.   (still searching. . . . )   A S.W.A.G. hunch here, but in 'analog' mode, maybe related to PWM reads, possibly requiring that oscillator?

Narath I know you are extremely detailed and vigilant, but is there a chance something else has changed in the setup? Originally, I started to think that the flash process disconnected the battery-resistor test circuit, and this was cured by that (thumbs up image) task. But, as has been indicated, other things changed, such as code line clean-up and technique etc.

---

Posted at 2020-03-06 by narath

Hey @robin, you are right, I had been trying a lot of different things at once. Let me try to bring us back to a shared baseline. Here is process.env:

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

Here is the code - including the state checking:

pinMode(A0, 'input_pulldown');

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

function doStuff() {  
    console.log("doing stuff");
	setTimeout(function(){       
      console.log("Going to sleep again");
      setDeepSleep(1);
    }, 2000);
}

setSleepIndicator(LED1);

setWatch(function() {  
   console.log("A0 pressed");
   doStuff();  
}, A0, {repeat: true, edge: 'rising', debounce: 10});


console.log("A0 = ",getPinMode(A0));
console.log("A1 = ",getPinMode(A1));
console.log("A4 = ",getPinMode(A4));
console.log("A5 = ",getPinMode(A5));
console.log("A6 = ",getPinMode(A6));
console.log("A7 = ",getPinMode(A7));
console.log("B0 = ",getPinMode(B0));
console.log("B1 = ",getPinMode(B1));
console.log("B3 = ",getPinMode(B3));
console.log("B4 = ",getPinMode(B4));
console.log("B5 = ",getPinMode(B5));
console.log("B6 = ",getPinMode(B6));
console.log("B7 = ",getPinMode(B7));
console.log("B8 = ",getPinMode(B8));
console.log("B9 = ",getPinMode(B9));
console.log("B10 = ",getPinMode(B10));
console.log("B13 = ",getPinMode(B13));
console.log("B14 = ",getPinMode(B14));

console.log("Going to sleep");
setDeepSleep(1);

Here is the console output:

>A0 =  input_pulldown
A1 =  analog
A4 =  analog
A5 =  analog
A6 =  analog
A7 =  analog
B0 =  analog
B1 =  analog
B3 =  analog
B4 =  analog
B5 =  analog
B6 =  af_output
B7 =  af_output
B8 =  analog
B9 =  analog
B10 =  analog
B13 =  analog
B14 =  analog
Going to sleep
>save()
=undefined
Compacting Flash...
Calculating Size...
Writing..
Compressed 114368 bytes to 4919
Running onInit()...

Here is the dump - after reset, upload, save and then reset:

>dump()
function onInit() {A13.read();}
function doStuff() {
  console.log("doing stuff");
    setTimeout(function(){
      console.log("Going to sleep again");
      setDeepSleep(1);
    }, 2000);
}
setWatch(function () {
  console.log("A0 pressed");
   doStuff();
}, A0, { repeat:true, edge:'rising', debounce : 9.99927520751 });
setSleepIndicator(B2);
E.setFlags({ "deepSleep": 1, "pretokenise": 0, "unsafeFlash": 0, "unsyncFiles": 0 });
pinMode(A0, "input_pulldown");
digitalWrite(B2, 1);
=undefined

And here is the power consumption: 2.4 mA again.

I'd certainly welcome any ideas.

---

Posted at 2020-03-06 by narath

Okay - so I tried a different tack. I had it do what I ultimately wanted it to do - wake on button, turn on wifi, send a GET request, turn off wifi and go to sleep. I had hoped to send the battery voltage with the GET request, but it looks like E.getBattery is only for the Pico.

Is there a way to read the battery voltage level?

I saved the code given below, and checked the power consumption - and low and behold - it appears to sleep at 0.64 mA !

I am using a LiPo 3.7V 500mAh battery. I have it wired to the + and - terminal. Should I wire it to the 3.3V instead and skip the power regulator to possibly save power (hopefully without nuking the chip).

I'm also ordering more Espruino's from Adafruit, as this is getting very exciting!

Thanks,
Narath

var wifi = require("Wifi");
var http = require("http");

pinMode(A0, 'input_pulldown');

var webhook_url = "WEBHOOK URL HERE";

function wifiOff() {
  console.log("Trying to turn wifi off");
  wifi.disconnect();
  A13.read();
}

function wifiOn(callback) {
  console.log("Trying to turn wifi ON");
  wifi.connect("WIFI", {"password": "PASSWORD"},
               function(ap){ 
    console.log("connected");
    callback();
  });
}

function get(url, done){
  console.log("GET");
  http.get(url, function(res) {
    res.on('data', function(data) {
      console.log("HTTP> "+data);
    });
    res.on('close', function(data) {
      console.log("Connection closed");
      done(data);
    });
  });
}

function onInit() {
  wifiOff();
}

setSleepIndicator(LED1);

function doneClick(data) {
  console.log("Done! Go to sleep");
  wifiOff();
  setDeepSleep(1);
}

function sendClick() {
  console.log("Trying to connect");
  wifiOn(function(){
    get(webhook_url, doneClick);
  });
}

setWatch(function() {  
  sendClick();
}, A0, {repeat: true, edge: 'rising', debounce: 10});

setDeepSleep(1);

---

Posted at 2020-03-06 by @allObjects

Nope, do NOT connect battery to 3.3V terminal... if the battery is really full - up to 4.2V - it puts too much stress on the mc, which has a limit of 3.6... neither STM nor ESP may survive... A good, low drop, low loss voltage regulator is the answer.

---

Posted at 2020-03-06 by Robin

Thr 2020.03.05

'I am using a LiPo 3.7V 500mAh battery. I have it wired to the + and - terminal. Should I wire it to the 3.3V instead and skip the power regulator to possibly save power (hopefully without nuking the chip).'

I'll defer to @gfwilliams for the designer recommendation.

LiPo and Lion have a tendancy to allow for a higher voltage when fully charged. I don't know if All the external parts have the same non 3V3 rating tolerance, protected by the regulator.

IMO I wouldn't risk a $40 board without a definitive response from the designer, but what about a Buck 3V7 to 3V3 down converter? (I've orderd parts to make some test circuit current comparisons but the Corvid-19 has most of that delayed right now)

> '3.3 is a 3.3v output from the on-board Voltage regulator'

The pin adjacent to B3 is an output.

Note 'On-board 3.3v 250mA voltage regulator, accepts voltages from 3.5v to 5v' at:

http://www.espruino.com/WiFi

The schematic implies connections at VDD are 3V3

https://github.com/espruino/EspruinoBoard/blob/master/WiFi/pdf/espruino_wifi_sch.pdf

'it appears to sleep at 0.64 mA'

Your 0.64 vs 0.05

'Current draw in sleep: < 0.05mA - over 2.5 years on a 2500mAh battery'
http://www.espruino.com/WiFi

Maybe time for that (0.05) test to be re-visited? or at least what the setup was then

An *Interesting* read - regulator power consumption:

Pixl and MDBT42Q deep sleep power figures?

Post #15 thru post #17 answers the statement on floating pins I posed earlier in post #29 but for nRF devices and not STM devices, so not sure it would apply here with WiFi.

---

Posted at 2020-03-06 by @gfwilliams

Ok, great - glad you're getting there! 0.64mA is still more than I'd expect though...

Should I wire it to the 3.3V instead

As others have said, please don't try that :) The Espruino WiFi actually has a pretty decent voltage regulator on board - the quiescent current (that drawn by the regulator) is something in the range of 0.002mA so there are definitely other issues :)

Is there a way to read the battery voltage level?

Not directly, since the battery voltage is never connected to the MCU. You can use E.getAnalogVRef() to get the MCU voltage, which will sit at 3.3v until the LiPo voltage drops below 3.4v(ish). If you google lipo discharge curve you'll see it's at about 98% discharged by that point.

If you want to get a proper reading you'd need to set up a potential divider (maybe 2x 100k resistors) to halve the battery voltage, then put that into an ADC pin (with a small capacitor between it and GND to help keep the voltage constant) and read the value.

Maybe time for that (0.05) test to be re-visited? or at least what the setup was then

As I mentioned above, I actually ran the code and got this figure with up to date firmwares just a few days ago.

---

Posted at 2020-03-10 by narath

Thanks @robin and @gfwilliams.

I will stay away from connecting to 3.3V

I will try E.getAnalogVRef() and if not enough warning will setup the divided resistors.

Best,
Narath