put your setup code here, to run once: Serial.println("ESP8266 in normal mode") Ĭonst char* host = " " Connect RST en gpio16 (RST and D0 on Wemos) A solution could be to close off the Vbat to the A0 with a transistor, controlled from an ESP8266 pin With the battery monitor this would be 87uA, which is a sizeable increase. The powerconsumption of an ESP8266 in deepsleep is about 77uA. If you do use this possibility, do realise that the resistors drain the battery as well with a constant 10uA (4.2V/420 000ohm). Ofcourse you could also do that in one step, but I like to keep it easy to follow. The True voltage then can be calculated by: So if the Voltage of a fully loaded Cell would be 4.2 Volt, the ADC of the ESP8266 would get 4.2 * 100/420= 1 Voltġ Volt is the max input to the ADC and will give a Raw reading of 1023. This is a 220 k resistor over a 100 k resistor Wemos D1 Internal Voltage dividerīy adding a 100k, it will in fact be a total resistance of 100k+220k+100k=420k. Well the Wemos D1 mini already has an internal voltage divider that connects the A0 pin to the ADC of the ESP8266 chip. Then connect the Vbat through a 100k resistor to A0. This is needed to let the chip awake from sleep. If I just leave the Wemos access the internet continuously it will last 6.5 hours, but for this example I will put the Wemos in Deepsleep for a minute, then read the battery voltage and upload that to Thingspeak.įirst, connect RST with GPIO16 (that is D0 on the Wemos D1 mini). I will illustrate it with a Wemos D1 mini and the Battery shield Wemos D1 Mini Battery shield I think this part is getting much more complicated as it will be drastically affected by different battery capacities (Faces kit or the battery stack units etc.) as well as the current draw - this is not so much the case with Step 1 so step 1 would be much more universal function and I think will remain reasoably accurate across battery capacities.There are a million reasons why you would want to monitor the Battery voltage of your Battery fed ESP8266. It could mimick that curve exactly at every percentage point using only 100 float values - and a very simple function:īyte returnBatteryLevel(float would you be willing to share that spreadsheet with me so I can pull the voltages out? I'd be happy to commit this function back to the M5core2 master so we can all report (more) accurate getting to a projected time left would be a step 2 in this process - the first being getting an accurate percentage left, the second projecting how quickly this will diminish based on knowlegde of the battery and the current draw. The most accurate and lightweight solution would be a lookup table. I've observed the same phenomenon in reverse when charging - it looks like you are charging really quickly because you hit 45% really quickly then it takes forever to make it the rest of the way - no wonder - you're only 20% charged! Great thank you! It's the super steep drop off at the end that is messing with everything as the algorithm in the example code just draws a straight line from 3.2v to 4.2v so up until the steep drop off it says you have almost 50% more battery than you actually have! at that dropoff point the voltage is about 3.65v - so the percentage calculation at that point in the graph will read 45%!!! ![]() Upshot would be it will be much more accurate than this basic linear calculation is - so I'm going to do this said in Core2 how to know the current battery level:Īs you can see the line is reasonably linear until the very end. We could also build tables at different consumptions/temperatures if we wish as this will all affect when the "last 20%" fade kicks in. ![]() Then I can build a lookup table to represent this in code for this device. Then we can build a graph - just like the one I linked to based on the specific battery in this device - a new, healthy battery at room temperature - using a fairly normal level of power consumption. Leave it to run down, pinging out to sdcard its battery voltage, current draw (for information) and the time elapsed. We can extrapolate that as being a total life of 1 hour and 15 minutes - based onthe last 20%ĭoes anyone know of a better curve solution someone has already done? You can see this shown in the graph above for Li-ion batteries (i dont really know how close that is to the real performance of these batteries. My little Core2 lasted for 5 hours and 40 minutes.Īt about 5 hours and 25 minutes it was showing 20% (my battery meter turns red at 20% :) ), but the last 20% dropped off in 15 minutes. I implemented and tested this last night While the calculation in the m5core2 factory test is linear - the battery performance is not.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |