I'm trying to measure battery voltage using a NodeMCU V3 and running ESPeasy, the voltage i'm trying to measure is car battery voltage, so 12-14.5v.
I fitted a voltage divider of 18k and 2k, to divide the voltage by a factor of 10 to feed into the NodeMCU board, which I known has it's own voltage divider (100R and 220R% to drop 3.3v to 1v for the ESP8266.
Obviously in this format it's range is 0-33v.
With some calibration and tweaking of the formula (I worked it out to %value%*0.00334*10) I can get a fairly accurate reading at 12v and at 14v, BUT for some reason the ESP is using only half it's 10bit resolution, jumping from say 370 to 372, but never 371 or 369, never odd numbers.
The voltage reading should according to my calculations be accurate to 0.032v, so from 12.42, it's next increment would be 12.46, which is good enough for what I need, but instead the voltage is jumping from 12.42v to 12.50v, at 0.064v increments.
Does anyone know what might cause the ESP to use only half it's resolution like this?
Using Analogue input AO/TOUT
Moderators: grovkillen, Stuntteam, TD-er
Re: Using Analogue input AO/TOUT
I know there is some internal calibration in the ESP8266.
So maybe this is causing some gaps.
You could try to log as many samples as possible while changing the voltage gradually and try some count function in Excel or something that fits your imagination and experience
Just to see what values are at 0 count and what values are not.
Such charts always give some insight in the distribution of the values.
I can imagine the measured values are also jumping around a bit in the last few bits, so you may also average the measured values over 8 or 16 samples to increase resolution.
So maybe this is causing some gaps.
You could try to log as many samples as possible while changing the voltage gradually and try some count function in Excel or something that fits your imagination and experience
Just to see what values are at 0 count and what values are not.
Such charts always give some insight in the distribution of the values.
I can imagine the measured values are also jumping around a bit in the last few bits, so you may also average the measured values over 8 or 16 samples to increase resolution.
-
- Normal user
- Posts: 14
- Joined: 13 Jan 2018, 11:51
Re: Using Analogue input AO/TOUT
Well, i've got 20+ of these NodeMCU boards, so i'll probably have to do some testing on one of those, I can't really test on the actual unit right now, it's been reporting voltage levels for over 18 hours and the level has stayed at 12.42, and occasionally jumping to 12.50 when the sun hits the solar panel.TD-er wrote: ↑27 Aug 2018, 17:52 I know there is some internal calibration in the ESP8266.
So maybe this is causing some gaps.
You could try to log as many samples as possible while changing the voltage gradually and try some count function in Excel or something that fits your imagination and experience
Just to see what values are at 0 count and what values are not.
Such charts always give some insight in the distribution of the values.
I can imagine the measured values are also jumping around a bit in the last few bits, so you may also average the measured values over 8 or 16 samples to increase resolution.
It's really weird that it won't report uneven numbers from the 10bit analogue input (range 1-1024). I don't know if maybe there is a mode/setting to make the ESP chip do this, or whether it's doing this for stability, or what.
Re: Using Analogue input AO/TOUT
You could try to see if the output can go above 1024.
-
- Normal user
- Posts: 14
- Joined: 13 Jan 2018, 11:51
Re: Using Analogue input AO/TOUT
So all appears to be working as expected now, I have no explanation as to why. I disconnected/reconnected the device yesterday because i'd hit some "daily limit" that couldn't be fixed with a reboot, since power cycling it seems to be behaving as i'd expected measuring voltage at 0.03v increments. I guess the lesson here is to power cycle the ESP every few days.
Re: Using Analogue input AO/TOUT
Or when changing the A0 mode?
Setting that input into a specific mode is quite tricky and in the source code you also have to do it while not calling it from a function for example.
Wouldn't be the first thing that is not entirely properly set until a proper reset has been given.
Setting that input into a specific mode is quite tricky and in the source code you also have to do it while not calling it from a function for example.
Wouldn't be the first thing that is not entirely properly set until a proper reset has been given.
Who is online
Users browsing this forum: No registered users and 103 guests