Esp-idf: [TW#12287] ESP32 ADC accuracy

Created on 14 Dec 2016  Â·  157Comments  Â·  Source: espressif/esp-idf

Hi,

I'm testing the ESP32's ADC on the SparkFun ESP32 Thing.
Currently my measure seems very noisy, it constantly varies on the 5 first bits, and the zero value is around 90mV.
Is there a way to achieve better accuracy?

My test code :

adc1_config_width(ADC_WIDTH_12Bit);
adc1_config_channel_atten(ADC1_CHANNEL_7, ADC_ATTEN_0db);

while (true) {
        vTaskDelay(300 / portTICK_PERIOD_MS);
        printf("ADC value : %x\n", adc1_get_voltage(ADC1_CHANNEL_7));
}

Thank you in advance for your help.

Bug

Most helpful comment

Yes, we are. It took us some time to build an automated testing rig to accurately and reliably grab the characteristics of a representative sample of ESP32s; that has rendered the first curves this week and we're working on converting these into some linearization code.

All 157 comments

The ADC has a non-linear response, and we are working on producing characterisation data which will be added to esp-idf to produce a linear output.

When you say "noisy", are you getting noisy readings on a constant voltage or is this noise caused by the non-linearity?

There's some more in this related Arduino bug: https://github.com/espressif/arduino-esp32/issues/92

Hi, a bit off-topic but I didn't want to start a new thread:

How come the adc2 function headers are not defined in adc.h? Won't adc2
work in the same way as adc1?

I see the adc2 functionality has already been implemented in the arduino
kernel, and it looks to me it works exactly as the adc1.

Also, thanks for the great work. I'm loving the ESP32 so far :-)

On 16 Dec 2016 00:18, "Angus Gratton" notifications@github.com wrote:

The ADC has a non-linear response, and we are working on producing
characterisation data which will be added to esp-idf to produce a linear
output.

When you say "noisy", are you getting noisy readings on a constant voltage
or is this noise caused by the non-linearity?

There's some more in this related Arduino bug: espressif/arduino-esp32#92
https://github.com/espressif/arduino-esp32/issues/92

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-267473316,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABj3qtg3pg5fMlWti_ICEiISxjlYobGxks5rIcregaJpZM4LNbPn
.

@CarlosGS : for issues, it is much better to start a new one than to post off-topic in an existing one.

For questions like this, the http://esp32.com forum may be an even better choice.

@projectgus : I think nassks means the "noise" within same values - additional I have seen that there is a "noise" between the inputs.
put 1 Volt (with capacititor) on inputs CH4 ..CH7 I get such results:
(using 0bd and 11db for the values)

ADC1 CH4 value: 3719 @ 0db, 1056 @ 11db
ADC1 CH5 value: 3889 @ 0db, 1052 @ 11db
ADC1 CH6 value: 3883 @ 0db, 1052 @ 11db
ADC1 CH7 value: 3891 @ 0db, 1052 @ 11db
-------
ADC1 CH4 value: 3867 @ 0db, 1056 @ 11db
ADC1 CH5 value: 3885 @ 0db, 1053 @ 11db
ADC1 CH6 value: 3887 @ 0db, 1040 @ 11db
ADC1 CH7 value: 3886 @ 0db, 1057 @ 11db
-------
ADC1 CH4 value: 3894 @ 0db, 1056 @ 11db
ADC1 CH5 value: 3855 @ 0db, 1061 @ 11db
ADC1 CH6 value: 3887 @ 0db, 1049 @ 11db
ADC1 CH7 value: 3875 @ 0db, 1053 @ 11db
-------

Difference is up to 5% - maybe it is normal?

But for 0V - I get a value "0" ... without "noise" - it is ok for me

Michael

Do not know why the crazy style came up before ;)

Code snippet for reference:

...
adc1_config_width(ADC_WIDTH_12Bit);
...
adc1_config_channel_atten(ADC1_CHANNEL_4,ADC_ATTEN_0db);
int val=adc1_get_voltage(ADC1_CHANNEL_4);
adc1_config_channel_atten(ADC1_CHANNEL_4,ADC_ATTEN_11db);
int val1=adc1_get_voltage(ADC1_CHANNEL_4);
printf("ADC1 CH4 value: %d @ 0db, %d @ 11db\n", val, val1);
....

Michael

So, in case anyone finds this ADC bug, I've found another ADC issue apparently where it will return data between 0-50% input, and cap out at 4096 from 50 to 100% input, but only after I try to use RMT.
Details here: https://github.com/espressif/esp-idf/issues/462

So, the lastest arduino-esp32 fixes the issue I just reported when RMT is turned on, analogread values would get damaged.

Hi nassks, is this problem solved?

@FayeY not yet, @Spritetm is working on it.

Just leaving my two cents on this...
I was hoping to use an inexpensive Voltage Reference IC (LM4040C30ILP) to help increase the accuracy of measured values. I too found the ADC to be non linear and have included my data below for anyone interested.
voltage, ADC
2 2222
3 3730
1 1033
1.5 1629
0 0
0.5 422
2.5 2840
2.8 3300
3.1 3980
3.007 3750

image

took another crack at this, and assuming the ADC readings are related to the 3.3V regulator voltage (mine is at 3.275 V on a developer board). Here's what I found.
image

@dmody interesting, have you tried to fit curves to the upper range and lower range separately?

In the future, are you planning to include linearization of adc1_get_voltage or it will be in charge to the user to correct non linear behavior?

Just to know, because if we implement linearization on user app and then adc1_get_voltage will change behavior we'll have to remove all those parts.

I did not consider doing that. Sounds like a decent idea. I wonder which
would be faster to execute. Sounds like a fun experiment to see.

I think the bigger problem I'm having is the noise. I haven't put my
scope on the unit to see if the noise is real or not, but my approach to
filtering was to do a for loop acquiring 100 samples, and to do a moving
average of 10 samples.
Ie
For I= 1 to 100
Daq = (analog input value + daq*9)/10

Would love to hear other people's thoughts on this.

On Sun, May 7, 2017 at 7:08 PM negativekelvin notifications@github.com
wrote:

@dmody https://github.com/dmody interesting, have you tried to fit
curves to the upper range and lower range separately?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-299742244,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARtFwIoqc_VQwfuKdMKY0gdDNeBqlh1eks5r3k70gaJpZM4LNbPn
.

really interested in this

Are we going to fix this soon? I feel like many applications depend on this feature. Is there a workaround at least?

Yes, we are. It took us some time to build an automated testing rig to accurately and reliably grab the characteristics of a representative sample of ESP32s; that has rendered the first curves this week and we're working on converting these into some linearization code.

@Spritetm any updates on this? Perhaps a timeline to when this might be fixed? Thanks!

@Spritetm @igrr I would love to hear an update on this - or if there is an effective workaround?

@MaxSNi
The best workaround for me was to write a little function that returns the voltage based on the DAQ value using the formula I presented above. I can post the function if you like.

@dmody I would love to see your function. I made a quick function from my own excel trend equation and while it does work better, its pretty crude...

@MaxSNi
//************ Analog to Digital Conversion Function *********
float A2D(float SenVal)
{
if(SenVal<1) return(0);
else if (SenVal>4094) return(99);
else return(-0.000000000023926 * pow(SenVal,3) + 0.000000094746 * pow(SenVal,2) + 0.00074539 * SenVal + 0.14925);

}

Is there any update on this issue?
It sounds me really crazy that on an IoT chip there's no way to have a good ADC reading.

Probably time to look at other options.
i realised a few months ago its simply not going to be ready anytime this calendar year for production use

we have a simmulair problem , i can live with a correction factor but we discoverd in testing 10 esp32 samples , the difference between samples can be >10 to 20% , making a calibration nessesery for each esp , making it unusable for serios work

Hi @jan-bozelie. I'm aware there should be huge differences betweens samples due to the internal reference voltage regulator, but at the moment ADCs suffer of two distinct issues:

  • Non linearities
  • Different end of scale due to internal voltage reference

I think we should split ADC issue in two steps. Once we have corrected the non linearities, the EOS issue could be easily faced using an external voltage reference or a calibration procedure.

This problem has been totally ignored by Espressif, and I think ADCs are really important for an IoT application.

@igrr ... can we have an official response from Espressif about the fact ADC issue can or cannot be solved? At the moment we have a peripheral which is absolutely useless.

The official response has been already given by @Spritetm above (well, that is as official as you will get). We are working on both parts of the issue (nonlinearities and different v_ref):

  • For non linearity, the code and linearization tables are being reviewed at the moment and as mentioned somewhere (i think on the forum) these will be part of 3.0 release.
  • For v_ref variation, there is a provision in the linearization code to take v_ref value for the current chip into account. Obviously you need to determine this value somehow somehow. There are three ways of solving it:

    • Large scale: new chips produced starting from (some date)(1) will have their V_REF burned into efuse at production. Calibration code will automatically pull this value from efuse.

    • Medium scale: if you have purchased a batch of chips/modules or otherwise need to use the ones without V_REF programmed, you have two options:

    • Incorporate V_REF programming into your production flow. During production, you can either measure the V_REF using external tool (we have a function to pull V_REF out onto a pad), or you can use ESP32's ADC to measure a good-known voltage from a reference source, and use that to calculate V_REF; then burn it into efuse.

    • Add a reference voltage source onto your board and connect it to one of the ADC pins. Use that to calculate V_REF and feed the value into calibration code

    • Small scale: use a function which connects V_REF to a pad, measure V_REF voltage with a multimeter, write it into NVS or EFUSE.

V_REF compensation works pretty well, the errors which remain are due to run-time variation of V_REF. If you add an external reference voltage source and connect it to one of the ADC pins, you can apply correction at runtime, compensating even for temperature changes.

Linearization works best for low attenuation settings (0 and 1), as for these settings the transfer curve is closest to being linear. At attenuation setting 3 things get a bit more messy and hard to correct for, so we advise using lowest attenuation if possible. You will still not get rail-to-rail performance, but the result may be sufficient for a non-precision application.

(1): currently I can not give you any indication what that date might be.

Hi @igrr, really thank you for your feedback!

We have 10 samples of a custom board with an external 1.2V voltage reference (TI LM4041A12) and operational amplifier to filter input signals and adapt impedance. They have an output range of 0.15V to 1.8V (in order to avoid start end end of scale).

We tried to implement many of the linearization tables found (they are all different!) and also used an heavy software filter on the external voltage reference pad to correct dynamic fluctuations caused by the internal voltage reference instability and work always with the correct end of scale.

I tried this approach on 10 different boards, and with all of them we have acquisition errors close to the 5-10% (which is useless for an ADC).

In my opinion, the non-linear characteristic is something different chip by chip, it's not only a matter of the internal voltage reference. And if this true, there's absolutely no way to compensate it.

@Spritetm did you try to plot non-linear characteristic on different ESP32 chips?

Few users tried to plot it and they all get different results. I personally tried on few samples and always get something different...

No we have as utility a pilot development for in the medium gas distribution grid ( ongoing)

1 natural gas presure sensor 0-300mBar gauge --> 5V suply 0-3.3V output per home ( the sensor is max 0.5% error and is ok)

  And also not sensitive for 0.5V voltage variations in the supply

There is no noticeble noice on the suply voltage during this experiments

The ESP board has a stabelizer 5V tot 3.3V feeded with a usb adapter / or laptop usb port

We did make 10 samples ahead of a pilot of 5000pc

For each 10 sensors we did make a voltage measurement readung compared to a voltage calibrator , with oversampling and avagaging

From these measurements we did make a correction curve, reducing 10%relative eror to 1% we can live with that

Than we checked the other , assuming the correction curve is aplicapable for all esp

But no --> worst case error between 10 ESP32 samples is 20% , what would inplement we would have to calibrate each sensor seperate

What would take at lease 20min labour , and not afordable

Conclusion , we have to look for an other solution , or a fix

One experiment we planed = ( put more analog inputs in parallel of the same ESP32 )

Van: imotion-software [mailto:[email protected]]
Verzonden: dinsdag 22 augustus 2017 13:53
Aan: espressif/esp-idf esp-idf@noreply.github.com
CC: jan-bozelie jan@bozelie.com; Mention mention@noreply.github.com
Onderwerp: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

@Spritetm https://github.com/spritetm did you try to plot non-linear characteristic on different ESP32 chips?

Few users tried to plot it and they all get different results. I personally tried on few samples and always get something different...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-324003352 , or mute the thread https://github.com/notifications/unsubscribe-auth/AdBrfwkasXeWB1AM092yUDkt9DIz518Cks5sasEvgaJpZM4LNbPn . https://github.com/notifications/beacon/AdBrf07IBwKQbKUCYoXl0WmIRHGEFMX4ks5sasEvgaJpZM4LNbPn.gif

I can confirm that is is chip to chip different from our 10 samples

In my aplication , (one sensor one esp32), i could live with an havy correction algoritm

I cant live with labour time and cost , for calibrating each analog input & each esp seperatly

Is there a bad sample ranproduction range ??

Van: imotion-software [mailto:[email protected]]
Verzonden: dinsdag 22 augustus 2017 13:51
Aan: espressif/esp-idf esp-idf@noreply.github.com
CC: jan-bozelie jan@bozelie.com; Mention mention@noreply.github.com
Onderwerp: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

Hi @igrr https://github.com/igrr , really thank you for your feedback!

We have 10 samples of a custom board with an external 1.2V voltage reference (TI LM4041A12) and operational amplifier to filter input signals and adapt impedance. They have an output range of 0.15V to 1.8V (in order to avoid start end end of scale).

We tried to implement many of the linearization tables found (they are all different!) and also used an heavy software filter on the external voltage reference pad to correct dynamic fluctuations caused by the internal voltage reference instability and work always with the correct end of scale.

I tried this approach on 10 different boards, and with all of them we have acquisition errors close to the 5-10% (which is useless for an ADC).

In my opinion, the non-linear characteristic is something different chip by chip, it's not only a matter of the internal voltage reference. And if this true, there's absolutely no way to compensate it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-324002843 , or mute the thread https://github.com/notifications/unsubscribe-auth/AdBrf7BUz9ceTEpFCbc8SlpLlfbWp4WHks5sasCYgaJpZM4LNbPn . https://github.com/notifications/beacon/AdBrfyvs8QiQJywI5olP6KUU632b_-7fks5sasCYgaJpZM4LNbPn.gif

http://i.imgur.com/mTkip9V.png
This is a set of a few boards. (We have more, but this is data I have right here). As you can see, the reference voltage of all ESP32s is slightly different (hence the steepness of the curve differs from esp to esp) and the start and ends of each curve as well as the entire attn=3 curve is non-linear, but apart from the reference voltage, the ESPs do not really have that different-looking curves.

Hi @Spritetm ! Is it possibile to have raw excel data of the graph you posted with those 8 devices?

Here is some testing I did tonight using freshly pulled code from repo and built firmware. 12-bit and atten at -11db (defaults). I do not know enough to change the atten or width...I can hack away at Arduino sketches but I don't know if I can change it from there and I'm not sure where to change it in the source before I build the firmware. If anyone can tell me I'll try the -6db setting instead of the default -11db and see if it's better:

6e0f1c1a78a49e90bd66b9abd2f8f91518157c7e_1_690x414

ESP32-Voltage-vs-ADC-Reading.txt

Hi @vseven,

if you want to change attenuation, there's a specific function "adc1_config_channel_atten".
For width, you can change it calling "adc1_config_width".

I think -6dB should have a more linear characteristic, but probably reducing width will simply reduce noise but not non-linearities.

If you make a test at -6dB, please share result because I'm interested too.

Ive tried those commands in my Arduino sketch, multiple times, and just get a compile error. I must not have the syntax correct nor can i find it anywhere. I made a post on ESP32.com's forums asking but no reply yet. Once i change it i will retest and post.

Clarification: I have tried "analogReadResolution" and "analogSetAttenuation" from Arduino and it fails to compile. I guess I can try changing the static set values in the code and recompile the firmware? Only place I have found this would be in adc.h and platform.h and I would just hack it, changing the enum for 11db to equal 2 instead of 3 but that doesn't sound like a great idea.

EDIT: Figured it out...had to put the statements in my Setup().

Does this bug get fixed?

No but i did a lot of work on getting better results that might help you: https://esp32.com/viewtopic.php?f=19&t=2881

ok, so basically vref needs to be routed to gpio, measured and recorded in the particular device so it can apply the right correction values. this is unfortunate. i assume this will be fixed in the future revisions of the chip?

in the mean time, i have an application where i only need to measure value of one thermistor. i wonder if i can use vref to gpio routing to avoid the extra calibration step.
say, i have a circuit like this:

IO25 (Vref) ---,
               |
               RT
               |
IO34 ----------*
               |
               RB
               |
              ---
               -
               .

RT is the thermistor, RB is a bias resistor, value TBD. will using Vref like this allow me to get accurate reading of drop across RT on IO34 without calibration? using attenuation of 0, naturally.

How would we "burn" the Vref into the fuses? I'd like to make the test for every ESP32, store the value and not worrying about measuring it again.

@rojer they say chips will ship with factory cal burned to efuse at some unspecified time in the future or possibly by special order.

@negativekelvin that makes sense.

@DrBomb i know you're a mOS user, so this may be handy - mos utility can operate on eFuses:

$ mos -X esp32-efuse-get
...
$ mos -X esp32-efuse-set
Error: one or more ops required. op is 'fuse=value', 'fuse=@file' or 'fuse.{WD|RD}=1'

i guess you could use (part of) the user_key field for this.

FWIW, here are my results from 10 devices i had lying around, calculated error % before calibration and after. 12 bits, 11 db atten.
columns are:
id, measured voltage on input: raw reading => voltage @ vref 1100 (error %); measured vref => voltage @ vref (error %).

00, 1.648: 1953 => 1.697 (3.0%); vref 1.070 => 1.657 (0.5%)
04, 1.669: 1886 => 1.642 (1.6%); vref 1.100 => 1.642 (1.6%)
05, 1.650: 1835 => 1.600 (3.1%); vref 1.130 => 1.639 (0.7%)
06, 1.653: 1856 => 1.618 (2.2%); vref 1.122 => 1.648 (0.3%)
AC, 1.651: 1819 => 1.586 (4.1%); vref 1.132 => 1.628 (1.4%)
03, 1.643: 1776 => 1.552 (5.8%); vref 1.143 => 1.608 (2.2%)
tt, 1.635: 1778 => 1.556 (5.1%); vref 1.129 => 1.595 (2.5%)
SL, 1.658: 1839 => 1.604 (3.4%); vref 1.119 => 1.629 (1.2%)
5C, 1.640: 1819 => 1.587 (3.3%); vref 1.129 => 1.625 (0.9%)
9C, 1.654: 1891 => 1.646 (0.5%); vref 1.105 => 1.652 (0.1%)

so, calibration gets the errors down, but doesn't quite eliminate them.

also, i found that reading ADC disables vref output to the pin, which is unfortunate.

Are you averaging multiple samples?

Yes we did and it improved the noice error , as we could expect

Van: negativekelvin [mailto:[email protected]]
Verzonden: zaterdag 30 september 2017 09:22
Aan: espressif/esp-idf esp-idf@noreply.github.com
CC: jan-bozelie jan@bozelie.com; Mention mention@noreply.github.com
Onderwerp: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

Are you averaging multiple samples?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-333290111 , or mute the thread https://github.com/notifications/unsubscribe-auth/AdBrf7zTC-cTKnUmmpiwW-jCk_qbKrEZks5snewNgaJpZM4LNbPn . https://github.com/notifications/beacon/AdBrf5Hmjj5auK5I-dNJKTJB8nnL_Bx1ks5snewNgaJpZM4LNbPn.gif

Thanks , for the info --> informative

however, calibrating each io is killing each business case

I did buy pressure sensors with 0.25% accuracy , adding than 2.5% is a lot

Van: Deomid Ryabkov [mailto:[email protected]]
Verzonden: vrijdag 29 september 2017 23:34
Aan: espressif/esp-idf esp-idf@noreply.github.com
CC: jan-bozelie jan@bozelie.com; Mention mention@noreply.github.com
Onderwerp: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

FWIW, here are my results from 10 devices i had lying around, calculated error % before calibration and after.
columns are:
id, measured voltage on input: raw reading => voltage @ vref 1100 (error %); measured vref => voltage @ vref (error %).

00, 1.648: 1953 => 1.697 (3.0%); vref 1.070 => 1.657 (0.5%)
04, 1.669: 1886 => 1.642 (1.6%); vref 1.100 => 1.642 (1.6%)
05, 1.650: 1835 => 1.600 (3.1%); vref 1.130 => 1.639 (0.7%)
06, 1.653: 1856 => 1.618 (2.2%); vref 1.122 => 1.648 (0.3%)
AC, 1.651: 1819 => 1.586 (4.1%); vref 1.132 => 1.628 (1.4%)
03, 1.643: 1776 => 1.552 (5.8%); vref 1.143 => 1.608 (2.2%)
tt, 1.635: 1778 => 1.556 (5.1%); vref 1.129 => 1.595 (2.5%)
SL, 1.658: 1839 => 1.604 (3.4%); vref 1.119 => 1.629 (1.2%)
5C, 1.640: 1819 => 1.587 (3.3%); vref 1.129 => 1.625 (0.9%)
9C, 1.654: 1891 => 1.646 (0.5%); vref 1.105 => 1.652 (0.1%)

so, calibration gets the errors down, but doesn't quite eliminate them.

also, i found that reading ADC disables vref output to the pin, which is unfortunate.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-333244540 , or mute the thread https://github.com/notifications/unsubscribe-auth/AdBrf3Rxzrq8sTqrvyQKnSoxqQgmv8etks5snWJZgaJpZM4LNbPn . https://github.com/notifications/beacon/AdBrf4j0b-sqdV7HFJ6Pi_c8XKsNcrGOks5snWJZgaJpZM4LNbPn.gif

Are you averaging multiple samples?

i was not. i'd take a reading every second, print it out, and then use one of these lines to compute.

[Sep 29 22:25:36.037] timer_cb             Tick 1890 1645 (vref 1100) 1651 (vref 1105)
[Sep 29 22:25:37.037] timer_cb             Tock 1887 1643 (vref 1100) 1649 (vref 1105)
[Sep 29 22:25:38.037] timer_cb             Tick 1886 1642 (vref 1100) 1648 (vref 1105)
[Sep 29 22:25:39.037] timer_cb             Tock 1891 1646 (vref 1100) 1652 (vref 1105)
[Sep 29 22:25:40.037] timer_cb             Tick 1894 1649 (vref 1100) 1655 (vref 1105)
[Sep 29 22:25:41.037] timer_cb             Tock 1888 1644 (vref 1100) 1650 (vref 1105)

calibrating each io is killing each business case

exactly my thinking. it's imperative that Espressif starts doing it at some point, or we can forget about ADC for all but the most trivial applications.

So we won't get linearization data integrated into ESP-IDF? Very bad if that's the case..

So we won't get linearization data integrated into ESP-IDF? Very bad if that's the case..

Linearization of ADC readings is integrated into ESP-IDF now via the esp_adc_cal API. The part which is still pending is being able to calibrate the chip's internal Vref (a fixed voltage offset applied to the linearized value) from a value shipped in the ESP32 from the factory.

Right now the options are:

  • Use a default VRef value for all chips and accept that calibration results will be much more linear than "raw" readings but may be off by a fixed offset.
  • Measure VRef on each ESP32 (as described above) and store this value for later use with the calibrated ADC API.

Future revisions of the ESP32 will have VRef measured as part of the in-factory test, with the value stored in efuse.

Well, that's some very good news! Thanks for the reply!

Would it be possible to make calibration routine using DAC and ADC? Both from esp32?

Should the characteristics returned by esp_adc_cal_get_characteristics() be valid for all channels of ADC1?

I have 234mV at Channel 7 (GPIO 35) and 3010mV at Channel 0 (GPIO36) (measured with a multimeter).
Resolution is set to 12Bit, attenuation is set to 11dB.

Trial 1
When I play around with the vref parameter passed to _esp_adc_cal_get_characteristics()_ so that the voltage at Channel 7 (GPIO35) measured correctly by the ESP32, the voltage for Channel 0 (GPIO 36) is off by ~+230mV.
The determined Vref value here is 1163mV.

Trial 2
When I do it vice versa, passing a Vref parameter to _esp_adc_cal_get_characteristics()_ so the voltage at Channel 0 (GPIO 35) is measured correctly by the EPS32, the voltage for Channel 7 (GPIO 35) is off by
~-70mV.
The determined Vref value here is 1056mV.
When I connect GPIO35 with GPIO36 so that both do get the same voltage, measurements on both channels are equal.

So it seems that even with the linearisation tables in use, its not getting that good. What should be the the optimal voltage connected to an ADC Channel determine ones Vref voltage that way? Maybe 0.5xVmax?

In my case, the three Pins where I could route the internal Vref to for measurement are not available due to already connected components on my prototype board so I can not measure it directly (and I could not ask the customer to do so at all).

My initial idea was to connect a well-known voltage to a free ADC Channel, manipulating the Vref parameter in a loop until the measured value is equal to the well-known one and use that for all channels.

@ESP32DE
i will leave my finger from the ESP32 until the problem is hardware solved
to ESP if you cant do it right , dont make such a product !!!

to the rest of the world , is there an other product out there we can use , and will do better
this esp32 we will never get it working right ,

@elFallino if you are going to try that you should pick the value of vref that has the smallest max error at both voltages. You should not try to get zero error.

That's not easy to implement as it would require to switch between two stable, well-known voltages with hardware. That would also require to generate a second voltage.

One of the voltages I need to measure is the output of a hall sensor for current measurement with a resolution with 33mV/Ampere. So even some few mV's error would be a big off in current measurement.

What a pain in the ass:(

question about linearization. i see that 0 raw reading is not actually 0 in voltage after linearization, it's actually 110 mV. similarly, max raw reading (4095 in 12-bit mode) is interpolated to 3160 mV when vdd is set to 3.3. what is the reason for this?

@rojer check the graph posted above https://github.com/espressif/esp-idf/issues/164#issuecomment-326476297

Nonlinearity could be handled. The main problem is the ambiguity. The input voltage stays within uV precise (2.9967V), while the display readings swinging in a 1,6% range what is averaged from 15 measurements! This ADC is unusable. And not forget I have put a 68nF capacitor on the input, but almost no effect. This looks a serious mistake or I have to do something very different. Maybe I have to use a separate ADC for most of the analog projects with ESP32. measured

Hi people,
Have any solution for ambiguity? I am trying to measure voltage from current transformer via 22omh resistror. And I get always different measurment for input current of 0A. Can someone give me advice how to calibrate my ADC and get right measeurment?

Here is my piece of code for ADC initailization and for measuring:

void init_adc(void)
{

// ADC capture width is 12Bit
adc1_config_width(ADC_WIDTH_12Bit);
// ADC1 channel 6 is GPIO34, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_6,ADC_ATTEN_11db);
// ADC1 channel 7 is GPIO35, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_7,ADC_ATTEN_11db);
// ADC1 channel 4 is GPIO32, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_4,ADC_ATTEN_11db);

// Calculate ADC characteristics i.e. gain and offset factors
esp_adc_cal_get_characteristics(V_REF, ADC_ATTEN_DB_11, ADC_WIDTH_BIT_12, &characteristics);

}
void ADC_Task(){

results[0] = adc1_to_voltage(ADC1_CHANNEL_6,  &characteristics); // ADC1 channel 6 is GPIO34
results[1] = adc1_to_voltage(ADC1_CHANNEL_7,  &characteristics); // ADC1 channel 7 is GPIO35
results[2] = adc1_to_voltage(ADC1_CHANNEL_4,  &characteristics); // ADC1 channel 4 is GPIO32

}

I have the same problem.

I will make a comparative ADC test soon to find the answer. (ESP32, ADS1115, voltage reference, OpAmp buffers, 6,5 digit DMM).

I need some spare time.

I am afraid the ESP32 inside ADC is unusable, or maybe at 8,9 bit resolution.

I will refer, when I have finished.

From: rajkovicbojan [mailto:[email protected]]
Sent: Thursday, February 08, 2018 1:20 PM
To: espressif/esp-idf
Cc: tcsaba101; Comment
Subject: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

Hi people,
Have any solution for ambiguity? I am trying to measure voltage from current transformer via 22omh resistror. And I get always different measurment for input current of 0A. Can someone give me advice how to calibrate my ADC and get right measeurment?

Here is my peace of code for ADC initailization and for measuring:

void init_adc(void)
{

// ADC capture width is 12Bit
adc1_config_width(ADC_WIDTH_12Bit);
// ADC1 channel 6 is GPIO34, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_6,ADC_ATTEN_11db);
// ADC1 channel 7 is GPIO35, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_7,ADC_ATTEN_11db);
// ADC1 channel 4 is GPIO32, full-scale voltage 3.9V
adc1_config_channel_atten(ADC1_CHANNEL_4,ADC_ATTEN_11db);

// Calculate ADC characteristics i.e. gain and offset factors
esp_adc_cal_get_characteristics(V_REF, ADC_ATTEN_DB_11, ADC_WIDTH_BIT_12, &characteristics);

}
void ADC_Task(){

results[0] = adc1_to_voltage(ADC1_CHANNEL_6, &characteristics); // ADC1 channel 6 is GPIO34
results[1] = adc1_to_voltage(ADC1_CHANNEL_7, &characteristics); // ADC1 channel 7 is GPIO35
results[2] = adc1_to_voltage(ADC1_CHANNEL_4, &characteristics); // ADC1 channel 4 is GPIO32

}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-364095139 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXFYFgy1qZmFwPnUzUZAkIfYHbGM6Z2_ks5tSuZTgaJpZM4LNbPn . https://github.com/notifications/beacon/AXFYFhnP26KP-pqFJBchdkDoElZ6c9dPks5tSuZTgaJpZM4LNbPn.gif

You may want to use an external ADC. I am using the already mentioned ADS1115 as well.
It's cheap, connects via i2c, has 4 Channels and 16Bit. It's very accurate.

You may want to use an external ADC. I am using the already mentioned ADS1115 as well.

Yes, right. I use it a long time with ESP without any problems. Can also suggest it ...

Thanks Michael!

I know the ADS family is good and cheap, but I have changed to ESP32, because of wide combination of pheripherals.

I was able to solve all my ideas on ESP32, but this ADC is disappointing.

I want to see the test result with my eyes, before I switch to ADS1x15 ADC.

Best Regards, Csaba

From: Michael P. [mailto:[email protected]]
Sent: Thursday, February 08, 2018 5:39 PM
To: espressif/esp-idf
Cc: tcsaba101; Comment
Subject: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

You may want to use an external ADC. I am using the already mentioned ADS1115 as well.

Yes, right. I use it a long time with ESP without any problems. Can also suggest it ...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-364170691 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXFYFuJPiGsRfjGLoaKqmi218k8PrGXaks5tSyMdgaJpZM4LNbPn . https://github.com/notifications/beacon/AXFYFpXL9LKx110p0NunIk7Wdb1eLCQ4ks5tSyMdgaJpZM4LNbPn.gif

The input voltage stays within uV precise (2.9967V), while the display readings swinging in a 1,6% range what is averaged from 15 measurements!

Hi @tcsaba101,

Do you mean the raw readings or the averages from 15 measurements are swinging in a 1,6% range?

Below is a sample of measurements where I tried to do a similar test using generic ESP-WROVER-KIT V1 and slightly modified peripherals/adc example. The average of the last column is 3829.575. The values from the last column are within -0.09% to +0.2% from the average. This is for a test setup as on a picture at the end using short leads between the board and calibrator to minimize induced noise. If instead I use standard 1.5m multimeter leads, then the variations increase more than twice.

I am sure the test results will vary depending on the board type and where measurements are taken, if the board is not designed to reduce noise of analog measurements.

3811 / 3831 / 3839 / 3823 / 3847 / 3823 / 3825 / 3823 / 3835 / 3831 / 3827 / 3839 / 3855 / 3829 / 3839 / Sum:57477 / Avg: 3831
3823 / 3823 / 3839 / 3851 / 3819 / 3835 / 3821 / 3838 / 3831 / 3831 / 3823 / 3827 / 3813 / 3811 / 3823 / Sum:57408 / Avg: 3827
3831 / 3831 / 3825 / 3827 / 3827 / 3819 / 3831 / 3827 / 3823 / 3819 / 3829 / 3839 / 3823 / 3827 / 3835 / Sum:57413 / Avg: 3827
3839 / 3826 / 3827 / 3835 / 3831 / 3831 / 3835 / 3839 / 3839 / 3823 / 3825 / 3823 / 3839 / 3819 / 3846 / Sum:57477 / Avg: 3831
3831 / 3813 / 3831 / 3837 / 3839 / 3839 / 3835 / 3829 / 3831 / 3839 / 3829 / 3839 / 3837 / 3839 / 3821 / Sum:57489 / Avg: 3832
3815 / 3835 / 3823 / 3825 / 3839 / 3831 / 3823 / 3839 / 3825 / 3819 / 3827 / 3837 / 3827 / 3835 / 3823 / Sum:57423 / Avg: 3828
3839 / 3831 / 3823 / 3823 / 3831 / 3829 / 3837 / 3825 / 3830 / 3839 / 3831 / 3839 / 3847 / 3825 / 3825 / Sum:57474 / Avg: 3831
3837 / 3839 / 3825 / 3831 / 3823 / 3839 / 3835 / 3823 / 3827 / 3836 / 3835 / 3837 / 3831 / 3823 / 3823 / Sum:57464 / Avg: 3830
3831 / 3827 / 3835 / 3845 / 3826 / 3839 / 3825 / 3823 / 3827 / 3835 / 3823 / 3827 / 3834 / 3839 / 3829 / Sum:57465 / Avg: 3831
3835 / 3835 / 3826 / 3835 / 3823 / 3839 / 3831 / 3813 / 3847 / 3831 / 3826 / 3838 / 3833 / 3818 / 3839 / Sum:57469 / Avg: 3831
3823 / 3830 / 3838 / 3831 / 3837 / 3839 / 3823 / 3835 / 3825 / 3839 / 3831 / 3823 / 3847 / 3819 / 3839 / Sum:57479 / Avg: 3831
3839 / 3847 / 3831 / 3823 / 3831 / 3819 / 3824 / 3835 / 3839 / 3837 / 3825 / 3826 / 3824 / 3825 / 3825 / Sum:57450 / Avg: 3830
3835 / 3823 / 3833 / 3825 / 3823 / 3821 / 3819 / 3823 / 3831 / 3831 / 3847 / 3847 / 3825 / 3835 / 3811 / Sum:57429 / Avg: 3828
3827 / 3838 / 3825 / 3839 / 3815 / 3839 / 3834 / 3815 / 3814 / 3825 / 3834 / 3822 / 3835 / 3823 / 3829 / Sum:57414 / Avg: 3827
3831 / 3837 / 3826 / 3839 / 3835 / 3839 / 3827 / 3827 / 3827 / 3831 / 3839 / 3825 / 3839 / 3825 / 3837 / Sum:57484 / Avg: 3832
3831 / 3839 / 3821 / 3831 / 3827 / 3830 / 3839 / 3831 / 3821 / 3827 / 3839 / 3839 / 3830 / 3839 / 3839 / Sum:57483 / Avg: 3832
3839 / 3839 / 3825 / 3845 / 3818 / 3823 / 3827 / 3839 / 3831 / 3823 / 3839 / 3825 / 3827 / 3824 / 3829 / Sum:57453 / Avg: 3830
3823 / 3823 / 3834 / 3823 / 3837 / 3829 / 3839 / 3831 / 3831 / 3839 / 3821 / 3819 / 3831 / 3819 / 3831 / Sum:57430 / Avg: 3828
3822 / 3839 / 3846 / 3839 / 3851 / 3835 / 3823 / 3827 / 3835 / 3826 / 3835 / 3825 / 3829 / 3822 / 3827 / Sum:57481 / Avg: 3832
3805 / 3831 / 3827 / 3829 / 3822 / 3826 / 3824 / 3825 / 3807 / 3839 / 3839 / 3815 / 3825 / 3825 / 3835 / Sum:57374 / Avg: 3824
3819 / 3853 / 3827 / 3835 / 3839 / 3831 / 3827 / 3839 / 3819 / 3823 / 3825 / 3825 / 3839 / 3831 / 3831 / Sum:57463 / Avg: 3830
3839 / 3821 / 3819 / 3839 / 3837 / 3839 / 3827 / 3825 / 3831 / 3824 / 3839 / 3823 / 3823 / 3826 / 3823 / Sum:57435 / Avg: 3829
3839 / 3839 / 3827 / 3839 / 3824 / 3839 / 3839 / 3815 / 3825 / 3845 / 3839 / 3831 / 3837 / 3839 / 3831 / Sum:57508 / Avg: 3833
3839 / 3831 / 3839 / 3834 / 3821 / 3835 / 3827 / 3824 / 3819 / 3835 / 3837 / 3851 / 3831 / 3827 / 3831 / Sum:57481 / Avg: 3832
3835 / 3823 / 3823 / 3839 / 3831 / 3839 / 3835 / 3837 / 3831 / 3835 / 3839 / 3827 / 3827 / 3827 / 3829 / Sum:57477 / Avg: 3831
3839 / 3837 / 3827 / 3807 / 3833 / 3823 / 3839 / 3837 / 3819 / 3825 / 3839 / 3827 / 3815 / 3827 / 3823 / Sum:57417 / Avg: 3827
3839 / 3819 / 3826 / 3831 / 3815 / 3839 / 3827 / 3826 / 3839 / 3837 / 3835 / 3823 / 3823 / 3819 / 3827 / Sum:57425 / Avg: 3828
3839 / 3827 / 3839 / 3823 / 3839 / 3835 / 3827 / 3839 / 3826 / 3839 / 3823 / 3826 / 3830 / 3835 / 3837 / Sum:57484 / Avg: 3832
3823 / 3835 / 3847 / 3821 / 3827 / 3813 / 3831 / 3823 / 3839 / 3831 / 3839 / 3839 / 3839 / 3857 / 3835 / Sum:57499 / Avg: 3833
3824 / 3823 / 3822 / 3839 / 3823 / 3835 / 3823 / 3839 / 3839 / 3839 / 3823 / 3823 / 3827 / 3837 / 3838 / Sum:57454 / Avg: 3830
3835 / 3831 / 3827 / 3855 / 3813 / 3831 / 3819 / 3824 / 3854 / 3835 / 3825 / 3839 / 3823 / 3815 / 3817 / Sum:57443 / Avg: 3829
3831 / 3839 / 3830 / 3837 / 3831 / 3824 / 3826 / 3826 / 3827 / 3826 / 3822 / 3823 / 3851 / 3825 / 3827 / Sum:57445 / Avg: 3829
3819 / 3827 / 3823 / 3825 / 3815 / 3823 / 3827 / 3825 / 3819 / 3815 / 3823 / 3826 / 3839 / 3819 / 3817 / Sum:57342 / Avg: 3822
3821 / 3835 / 3819 / 3839 / 3837 / 3825 / 3827 / 3825 / 3827 / 3819 / 3831 / 3829 / 3814 / 3815 / 3827 / Sum:57390 / Avg: 3826
3827 / 3821 / 3823 / 3831 / 3827 / 3839 / 3855 / 3839 / 3819 / 3826 / 3851 / 3837 / 3819 / 3839 / 3822 / Sum:57475 / Avg: 3831
3824 / 3839 / 3807 / 3829 / 3839 / 3834 / 3839 / 3835 / 3839 / 3839 / 3835 / 3834 / 3823 / 3827 / 3835 / Sum:57478 / Avg: 3831
3815 / 3827 / 3847 / 3831 / 3831 / 3825 / 3823 / 3826 / 3829 / 3839 / 3815 / 3813 / 3826 / 3825 / 3811 / Sum:57383 / Avg: 3825
3823 / 3821 / 3839 / 3819 / 3833 / 3839 / 3831 / 3827 / 3827 / 3839 / 3835 / 3839 / 3821 / 3835 / 3835 / Sum:57463 / Avg: 3830
3833 / 3831 / 3824 / 3839 / 3835 / 3824 / 3829 / 3839 / 3826 / 3839 / 3827 / 3815 / 3831 / 3835 / 3834 / Sum:57461 / Avg: 3830
3825 / 3827 / 3839 / 3829 / 3831 / 3839 / 3831 / 3815 / 3839 / 3831 / 3839 / 3839 / 3839 / 3823 / 3839 / Sum:57485 / Avg: 3832

img_3855

Krzysztof, probably you are right with the cable. This is a Vegetronix Soil Moisture sensor measure on about a 1 m cable and the output impedance 10k so it is definitely not identical.
I connected the UNI-T U71D on the input and the read value was within 1-2 uV, while the displayed data you see in my post.
I also tried with an 1k helipot using a V-ref and was the same fluctuations on the display by visual analysis. I didn't made a report on that.

The first should be to put an OpAmp to the input of the ADC. I still have more serial problems with the firmware development, and i still haven't looked for an OpAmp solution.

What and how you connected to the ADC input, and what was on the display? What hw you use?

What and how you connected to the ADC input, and what was on the display? What hw you use?

Csaba,
All connections and h/w I used are on the picture above.
The FLUKE calibrator is set in voltage source mode to provide 2.997V.
It is connected to GPIO34 (ADC1_CHANNEL_6 / ADC_WIDTH_12Bit / ADC_ATTEN_11db) and GND pins of the ESP-WROVER-KIT.

Ok, now I see. But what you have read from the ADC? I made stable voltage on the inputs, but reading from ADC was what you have seen in my post.

Readings from the ADC are copy-and-pasted above the picture in a format similar what you used.

Slowly I see your example.
I would be happy with your readings.
I use Arduino, the same setup, on Pin39. Same Wroom on Lolin32 board
adcAttachPin(PIN_VEGETRO);
analogReadResolution(12);
analogSetWidth(12);
analogSetAttenuation(ADC_0db);
analogSetPinAttenuation(PIN_VEGETRO, ADC_11db);

Do you use Ext Reference?
Version of ESP32?
I don't see any special noise reduction on the Wrover-Kit board!

Now I have done again the v-ref and helipot experiment, short wires.
Output impedance approx 400ohm. Value on input is 100nV stable.
No real change in readings: +- 1% variation.
If I connect the Vegetronix sensor using a non inverting MCP6021 OpAmp the variation decreased to +- 0,5%. But this is still hardly reaching the 8 bit precision.

This is quite strange.
I have used breadboard with Arduino, PIC boards, there was no problem.
Any ideas to solve it?

20180218_113122

I have EVB board from Olimex,
I try on that too.

I have tried EVB.
Mdev: max deviation of samples from the average, also in %.
At 3 V input:
evb_adc

At 1V input
evb_adc2

I give it up now.
This ADC is unusable for measurement.
This I can call "guess", if this is enough I can use ESP32 ADC.

@tcsaba101 did you try a pin other than 36 or 39?

negativekelvin: no only those two in three different projects.

I can try, in the present project I have free ADC pins.

just to be sure I made the same test on Arduino-Uno, Due, Chipkit Uno32.
Chipkit very good, Uno acceptable.
The same hw and firmware. Those ADCs are woorking our ESP32 is not.

UNo 1V
uno_adc_1v
Uno 3V
uno_adc_3v
Uno 5V
uno_adc_5v

DUe 1V
due_adc_1v
DUE 3V
due_adc_3v

Chipkit UNO32 1V
uno32_adc2
UNO32 3V
uno32_adc_3v

All acceptable.

I have tried pin34 ADC1_CH6 what Krzysztof used in his test, no real change.
I have to put an ADS1x15 chip on i2c bus.

Csaba,

I like you have introduced other boards to compare the noise of the ADC readings. :+1:

To substitute your analysis, below are results of couple of my tests for different ESP32 boards and silicon revisions. It looks like ESP-WROVER-KIT board design is more immune to noise of the ADC readings comparing to other boards I have.

I made the tests using latest master of esp-idf and the following code - https://gist.github.com/krzychb/37076b52ee90a34bb59d32c1a8407beb

If you post your Arduino code I can test my boards with Arduino as well to have a complete picture.

With the data you posted I do not expect breaking news but would like to indicate that results may depend on design of particular board with the ESP32 chip.

Olimex ESP32-EVB, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 0

3795 3983 3943 3819 3771 3775 3839 3839 3797 3743 3811 3807 3799 3851 3879 Avg: 3830 Dev:  4.0%
4023 3835 3935 3775 3921 3975 3915 3921 3871 3939 3789 3711 3755 3891 3831 Avg: 3872 Dev: -4.2%
3839 3851 3807 3826 3903 3823 3824 3823 3907 3759 3791 3871 3835 3783 3806 Avg: 3829 Dev:  2.0%
3727 3919 3915 3915 3743 3831 3941 3760 3839 3699 3855 3796 3839 3941 3795 Avg: 3834 Dev: -3.5%
3920 3787 3839 3767 3871 3815 3919 3895 3951 3850 3863 3871 3837 3781 3839 Avg: 3853 Dev:  2.5%
3859 3915 3915 3763 3923 3919 3838 3947 3811 3887 3803 3797 3823 3783 3919 Avg: 3860 Dev: -2.5%
3919 3879 3875 3949 3919 3667 3759 3767 3799 3760 3807 3831 3711 3897 3822 Avg: 3824 Dev: -4.1%
3951 3791 3743 3889 3814 3751 3829 3799 3875 3875 3947 3823 3787 3915 3823 Avg: 3840 Dev:  2.9%
3927 3807 3787 3933 3863 3829 3856 3789 3907 3919 3879 3862 3831 3805 3765 Avg: 3850 Dev: -2.2%
3859 3747 3824 3727 3855 3851 3923 3875 3797 3792 3953 3774 3943 3837 3895 Avg: 3843 Dev: -3.0%
3919 3935 3831 3839 3751 3835 3839 3767 3882 3824 3999 3837 3919 3759 3759 Avg: 3846 Dev:  4.0%
3954 3894 3901 3903 3743 3867 3839 3879 3859 3811 3825 3839 3891 3883 3791 Avg: 3858 Dev: -3.0%
3839 3789 3878 3839 3885 3895 3871 3879 3889 3822 3763 3751 3871 3981 3807 Avg: 3850 Dev:  3.4%
3767 3795 3802 3815 3919 3863 3823 3789 3963 3779 3935 3826 3789 3855 3907 Avg: 3841 Dev:  3.2%
3827 3790 3781 3571 3623 3927 3826 3793 3888 3907 3959 3847 3939 3783 3750 Avg: 3814 Dev: -6.4%
3765 3795 3863 3903 3887 3879 3811 3861 3824 3779 3699 3877 3913 3775 3855 Avg: 3832 Dev: -3.5%
3889 3810 3821 3903 3903 3871 3925 3923 3877 3894 3861 3763 3835 3827 3770 Avg: 3858 Dev: -2.5%
3867 3883 3951 3739 3855 3839 3847 3785 3891 3859 3765 3869 3934 3870 3967 Avg: 3861 Dev: -3.2%
3871 3839 4011 3935 3883 3855 3775 3921 3825 3871 3889 3891 3851 3807 3887 Avg: 3874 Dev:  3.5%
3815 3895 3903 3885 3939 3935 3822 3858 3851 3903 3779 3859 3815 3735 3782 Avg: 3851 Dev: -3.0%
3715 3794 3831 3859 4095 3791 3954 3839 3931 3735 3863 3947 3839 3871 3761 Avg: 3855 Dev:  6.2%
3955 3813 3865 3867 3951 3890 3718 3815 3823 3839 3823 3910 3879 3879 3879 Avg: 3860 Dev: -3.7%
3823 3761 3838 3831 3755 3957 3923 3862 3895 3791 3925 3774 3733 3987 3847 Avg: 3846 Dev:  3.7%
3955 3927 3857 3779 3707 3807 3934 3793 3921 3835 3799 3891 3919 3887 3893 Avg: 3860 Dev: -4.0%
3811 3931 3826 3827 3739 3819 3795 3761 3891 3772 3869 3719 3879 3727 3815 Avg: 3812 Dev:  3.1%
3699 3753 3920 3735 3871 3856 3735 3826 3731 3893 3887 3761 3802 3803 3831 Avg: 3806 Dev:  3.0%
4015 3811 3728 3893 3783 3857 3943 3863 3807 3926 3875 3807 3939 3853 3879 Avg: 3865 Dev:  3.9%
3787 3839 3941 3935 3835 3887 3958 3833 3839 3903 3943 3886 3887 3871 3803 Avg: 3876 Dev: -2.3%
3855 3921 3725 3963 3863 3857 3911 3962 3903 3773 3787 3869 3901 3901 3887 Avg: 3871 Dev: -3.8%
3839 3871 3911 3863 3919 3767 3781 3883 3887 3815 3935 3903 3799 3885 3895 Avg: 3863 Dev: -2.5%

Olimex ESP32-EVB, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 0

3671 3695 3677 3741 3687 3675 3657 3647 3618 3651 3679 3739 3663 3669 3703 Avg: 3678 Dev:  1.7%
3583 3679 3699 3607 3735 3709 3728 3723 3747 3655 3743 3743 3759 3747 3723 Avg: 3705 Dev: -3.3%
3675 3679 3751 3627 3743 3711 3655 3697 3677 3677 3655 3759 3703 3717 3679 Avg: 3693 Dev:  1.8%
3633 3671 3775 3653 3642 3690 3733 3647 3711 3683 3687 3703 3685 3677 3675 Avg: 3684 Dev:  2.5%
3750 3711 3699 3695 3711 3615 3679 3702 3695 3651 3701 3723 3703 3629 3623 Avg: 3685 Dev: -1.9%
3661 3707 3631 3735 3652 3664 3693 3687 3721 3665 3643 3697 3695 3709 3677 Avg: 3682 Dev:  1.4%
3683 3706 3687 3735 3723 3695 3727 3721 3813 3687 3695 3749 3667 3711 3707 Avg: 3713 Dev:  2.7%
3741 3663 3607 3760 3695 3775 3723 3659 3719 3669 3693 3671 3696 3693 3677 Avg: 3696 Dev: -2.4%
3671 3629 3723 3721 3747 3709 3695 3727 3783 3729 3639 3679 3675 3699 3696 Avg: 3701 Dev:  2.2%
3718 3739 3695 3739 3731 3685 3711 3674 3600 3698 3723 3751 3663 3755 3743 Avg: 3708 Dev: -2.9%
3711 3701 3727 3695 3671 3691 3735 3663 3697 3701 3653 3711 3655 3655 3631 Avg: 3686 Dev: -1.5%
3649 3691 3664 3711 3664 3615 3735 3743 3735 3718 3735 3695 3751 3679 3687 Avg: 3698 Dev: -2.2%
3647 3639 3727 3711 3691 3675 3770 3695 3686 3711 3727 3665 3639 3638 3735 Avg: 3690 Dev:  2.2%
3701 3699 3707 3665 3664 3647 3633 3685 3701 3655 3671 3747 3711 3706 3661 Avg: 3683 Dev:  1.7%
3727 3649 3673 3711 3743 3698 3686 3699 3678 3742 3711 3643 3743 3707 3697 Avg: 3700 Dev: -1.5%
3791 3757 3690 3632 3703 3670 3699 3723 3763 3638 3679 3719 3651 3707 3695 Avg: 3701 Dev:  2.4%
3760 3727 3637 3731 3647 3663 3664 3659 3702 3723 3743 3664 3683 3759 3695 Avg: 3697 Dev:  1.7%
3711 3623 3691 3711 3770 3667 3711 3709 3715 3757 3721 3751 3675 3643 3707 Avg: 3704 Dev: -2.2%
3719 3655 3671 3685 3679 3723 3718 3647 3600 3675 3667 3651 3663 3696 3679 Avg: 3675 Dev: -2.0%
3762 3677 3723 3757 3671 3651 3735 3645 3647 3663 3667 3671 3695 3733 3703 Avg: 3693 Dev:  1.9%
3699 3670 3700 3699 3711 3696 3663 3639 3663 3683 3663 3743 3694 3699 3703 Avg: 3688 Dev:  1.5%
3639 3695 3605 3699 3675 3665 3707 3699 3679 3673 3735 3751 3729 3655 3685 Avg: 3686 Dev: -2.2%
3647 3623 3715 3694 3723 3638 3669 3664 3707 3702 3735 3755 3678 3671 3635 Avg: 3683 Dev:  2.0%
3631 3650 3583 3699 3659 3761 3755 3759 3783 3638 3703 3649 3611 3683 3721 Avg: 3685 Dev: -2.8%
3707 3664 3678 3759 3729 3661 3703 3751 3684 3683 3787 3759 3659 3743 3759 Avg: 3715 Dev:  1.9%
3633 3667 3669 3701 3735 3733 3691 3696 3647 3696 3685 3687 3647 3697 3679 Avg: 3684 Dev:  1.4%
3783 3717 3701 3723 3671 3671 3735 3615 3742 3743 3691 3739 3643 3679 3683 Avg: 3702 Dev: -2.4%
3741 3643 3711 3659 3655 3687 3671 3647 3698 3728 3703 3723 3729 3687 3645 Avg: 3688 Dev:  1.4%
3691 3647 3691 3711 3659 3635 3677 3607 3671 3669 3727 3667 3691 3651 3699 Avg: 3672 Dev: -1.8%
3631 3679 3699 3751 3679 3703 3742 3711 3643 3614 3727 3666 3677 3623 3715 Avg: 3684 Dev: -1.9%

ESP32 DevKitC V2, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 0

4083 4078 4011 4015 4077 4016 4049 4039 4011 4087 4027 4071 4043 4031 4031 Avg: 4044 Dev:  1.1%
4083 4051 4067 4051 4063 4061 4071 4055 4079 4051 4071 4062 4027 4011 4022 Avg: 4055 Dev: -1.1%
4031 4022 4081 4067 3990 4015 4093 4017 3990 4061 4030 4055 3999 4003 4063 Avg: 4034 Dev:  1.5%
3999 4080 4063 4023 4023 4023 4049 4006 4021 4007 4047 4031 4015 4031 4071 Avg: 4032 Dev:  1.2%
4083 4016 4079 4080 4031 4039 4079 4017 4063 4015 4027 4039 4045 4023 4003 Avg: 4042 Dev:  1.0%
4047 4039 3995 4031 4035 4079 4027 4007 3979 4045 4022 4007 4037 4095 4031 Avg: 4031 Dev:  1.6%
4019 3991 3987 4053 3966 4017 4075 4063 4017 4023 4063 3986 4071 4087 4063 Avg: 4032 Dev: -1.6%
3983 4071 4079 4079 4010 4023 3983 4071 4083 4081 4016 4016 4059 4031 4031 Avg: 4041 Dev: -1.4%
4039 4087 4015 4086 4050 4047 4067 4007 4055 4031 4055 4011 4015 4043 4035 Avg: 4042 Dev:  1.1%
4031 4043 4083 4037 4071 4039 4071 4015 4035 4055 4030 4019 4095 4031 4059 Avg: 4047 Dev:  1.2%
4047 4059 4049 4071 4039 3999 4047 4079 4003 4035 3990 4080 4019 4063 4087 Avg: 4044 Dev: -1.3%
4059 4047 4043 4059 4013 4063 4079 4019 4018 4009 4027 4015 4031 4051 4063 Avg: 4039 Dev:  1.0%
3986 4007 3991 4059 4031 4031 4016 4051 4031 4059 4019 4075 4061 4023 4043 Avg: 4032 Dev: -1.1%
4017 4063 4063 4027 4043 3991 4049 4087 4047 4017 4067 4015 4049 4047 3998 Avg: 4038 Dev:  1.2%
4003 4019 4047 4031 4031 4035 4062 4043 4031 4059 4021 4047 4077 4043 3995 Avg: 4036 Dev:  1.0%
4046 4035 4050 4017 4038 4015 4016 3989 4047 4031 4047 4079 4063 4047 4015 Avg: 4035 Dev: -1.1%
4015 4061 4063 4031 4045 4047 4015 4055 4079 4017 4087 4061 4023 4067 4063 Avg: 4048 Dev:  1.0%
4059 4031 4019 4063 4083 4031 4080 3989 4019 4031 4095 4041 4074 4027 4079 Avg: 4048 Dev: -1.5%
4071 4039 4035 4031 3999 4031 4071 4063 4031 3995 4071 4091 4031 4035 4022 Avg: 4041 Dev:  1.2%
4087 4063 3999 4071 4047 4023 4039 4049 4011 4059 4022 4062 3995 4079 4063 Avg: 4044 Dev: -1.2%
4087 4039 4029 4025 4079 4048 4063 3991 4055 4063 4031 4022 4045 4051 4049 Avg: 4045 Dev: -1.3%
4047 4063 4063 4021 3999 4059 4031 4011 4027 4081 4031 4029 4014 4015 4070 Avg: 4037 Dev:  1.1%
4048 4031 4047 4094 4031 4062 4007 4055 4003 4077 4063 4019 3995 4007 4070 Avg: 4040 Dev:  1.3%
4031 4071 4023 4023 4031 4031 4023 4083 4055 3986 4061 4067 4031 4035 4037 Avg: 4039 Dev: -1.3%
4015 4039 4079 4043 4049 4003 4071 3987 4087 4055 4087 4031 4017 3995 4031 Avg: 4039 Dev: -1.3%
4051 4023 4007 4051 4007 4031 4037 4083 4051 4047 3999 4063 4051 4047 4063 Avg: 4040 Dev:  1.1%
4079 4011 4015 3999 4055 4019 4085 4087 4075 4082 4027 4015 4007 4067 4035 Avg: 4043 Dev:  1.1%
4055 4061 4063 4035 4015 4027 4007 4063 4059 4047 4095 4049 4059 4011 4037 Avg: 4045 Dev:  1.2%
4043 4018 3997 4031 4051 4031 4035 4039 4023 4017 4061 4017 4053 4007 4059 Avg: 4032 Dev: -0.9%
4070 4092 4049 4006 4047 4083 4079 4050 4050 3999 4068 4051 4035 4045 4019 Avg: 4049 Dev: -1.2%

ESP32 DevKitC V2, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 0

3792 3798 3790 3793 3819 3803 3792 3789 3793 3792 3807 3827 3795 3795 3824 Avg: 3800 Dev:  0.7%
3799 3827 3799 3775 3775 3793 3794 3813 3815 3781 3811 3794 3811 3831 3801 Avg: 3801 Dev:  0.8%
3789 3807 3823 3827 3813 3814 3802 3829 3797 3831 3811 3807 3798 3807 3805 Avg: 3810 Dev:  0.6%
3787 3793 3791 3821 3807 3807 3793 3823 3799 3807 3811 3815 3807 3793 3775 Avg: 3801 Dev: -0.7%
3811 3797 3819 3791 3783 3791 3824 3803 3823 3807 3819 3799 3787 3793 3827 Avg: 3804 Dev:  0.6%
3826 3838 3775 3803 3818 3821 3823 3827 3807 3819 3779 3775 3827 3823 3823 Avg: 3812 Dev: -1.0%
3803 3830 3791 3823 3825 3827 3831 3824 3838 3827 3819 3793 3802 3773 3803 Avg: 3813 Dev: -1.0%
3802 3803 3807 3839 3821 3799 3823 3793 3803 3791 3795 3795 3783 3787 3795 Avg: 3802 Dev:  1.0%
3791 3790 3791 3821 3815 3799 3803 3791 3825 3822 3791 3815 3782 3795 3797 Avg: 3801 Dev:  0.6%
3779 3831 3803 3795 3825 3811 3793 3799 3791 3779 3799 3799 3803 3811 3799 Avg: 3801 Dev:  0.8%
3815 3827 3795 3815 3815 3783 3793 3815 3795 3815 3793 3815 3815 3797 3823 Avg: 3807 Dev: -0.6%
3786 3791 3827 3797 3787 3795 3799 3807 3830 3819 3799 3822 3825 3793 3831 Avg: 3807 Dev:  0.6%
3798 3815 3787 3791 3815 3780 3799 3795 3821 3799 3793 3792 3819 3823 3807 Avg: 3802 Dev: -0.6%
3774 3829 3827 3791 3813 3807 3799 3814 3798 3787 3831 3795 3823 3798 3823 Avg: 3807 Dev: -0.9%
3799 3823 3803 3819 3775 3787 3789 3829 3814 3819 3791 3795 3825 3823 3793 Avg: 3805 Dev: -0.8%
3807 3815 3775 3799 3831 3819 3827 3807 3793 3787 3795 3830 3783 3792 3794 Avg: 3803 Dev:  0.7%
3827 3807 3791 3785 3805 3807 3783 3823 3815 3807 3791 3783 3779 3803 3787 Avg: 3799 Dev:  0.7%
3799 3839 3823 3783 3791 3823 3774 3767 3815 3791 3773 3798 3807 3791 3831 Avg: 3800 Dev:  1.0%
3805 3792 3793 3783 3823 3795 3803 3795 3799 3798 3823 3823 3791 3815 3794 Avg: 3802 Dev:  0.6%
3827 3792 3819 3819 3815 3791 3793 3803 3815 3779 3782 3795 3815 3783 3795 Avg: 3801 Dev:  0.7%
3790 3799 3795 3791 3794 3787 3792 3791 3787 3793 3821 3822 3783 3794 3775 Avg: 3794 Dev:  0.7%
3807 3782 3807 3803 3779 3807 3783 3787 3823 3798 3807 3802 3791 3807 3797 Avg: 3798 Dev:  0.7%
3811 3811 3799 3819 3799 3795 3799 3811 3803 3789 3779 3797 3811 3792 3813 Avg: 3801 Dev: -0.6%
3794 3811 3787 3823 3783 3783 3779 3819 3813 3799 3829 3839 3807 3815 3791 Avg: 3804 Dev:  0.9%
3839 3807 3815 3815 3807 3835 3794 3823 3787 3791 3775 3799 3822 3791 3799 Avg: 3806 Dev:  0.9%
3783 3787 3815 3797 3815 3799 3793 3823 3789 3815 3799 3821 3807 3781 3798 Avg: 3801 Dev:  0.6%
3807 3793 3814 3783 3807 3830 3814 3826 3807 3795 3821 3783 3795 3819 3827 Avg: 3808 Dev: -0.7%
3825 3807 3831 3813 3795 3791 3787 3803 3793 3807 3779 3799 3803 3815 3815 Avg: 3804 Dev:  0.7%
3813 3797 3815 3795 3819 3813 3795 3789 3807 3815 3827 3807 3793 3807 3807 Avg: 3806 Dev:  0.6%
3829 3795 3822 3821 3825 3793 3807 3807 3802 3791 3815 3815 3779 3803 3799 Avg: 3806 Dev: -0.7%

ESP-WROVER-KIT V1, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 0

3957 3967 3967 3983 3959 3984 3985 3959 3987 3983 3967 3967 3959 3984 3975 Avg: 3972 Dev:  0.4%
3967 3959 3986 3979 3967 3975 3963 3987 3981 3991 3975 3987 3967 3983 3955 Avg: 3974 Dev: -0.5%
3991 3984 3990 3975 3982 3967 3967 3999 3979 3955 3983 3967 3967 3959 3967 Avg: 3975 Dev:  0.6%
3973 3963 3967 3965 3965 3959 3981 3986 3975 3974 3983 3983 3959 3955 3967 Avg: 3970 Dev:  0.4%
3979 3983 3971 3967 3959 3963 3967 3975 3979 3967 3965 3979 3959 3983 3979 Avg: 3971 Dev:  0.3%
3967 3963 3953 3959 3971 3967 3979 3975 3966 3967 3979 3975 3987 3967 3971 Avg: 3969 Dev:  0.5%
3967 3967 3959 3991 3967 3995 3974 3947 3973 3958 3967 3991 3985 3973 3959 Avg: 3971 Dev:  0.6%
3985 3983 3967 3967 3984 3991 3967 3963 3983 3979 3979 3967 3975 3983 3967 Avg: 3976 Dev:  0.4%
3967 3953 3967 3973 3991 3995 3967 3983 3978 3999 3979 3974 3991 3983 3979 Avg: 3978 Dev: -0.6%
3975 3959 3975 3983 3982 3983 3974 3979 3991 3967 3987 3979 3967 3999 3979 Avg: 3978 Dev:  0.5%
3967 3951 3967 3979 3953 3951 3975 3983 3967 3985 3983 3975 3963 3979 3959 Avg: 3969 Dev: -0.5%
3981 3981 3953 3967 3954 3959 3967 3967 3967 3959 3979 3983 3965 3967 3971 Avg: 3968 Dev:  0.4%
3951 3967 3995 3973 3983 3967 3967 3967 3967 3995 3966 3959 3975 3985 3980 Avg: 3973 Dev:  0.6%
3983 3959 3999 3967 3967 3959 3975 3951 3967 3979 3984 3959 3958 3959 3975 Avg: 3969 Dev:  0.8%
3967 3983 3975 3975 3967 3983 3967 3967 3983 3979 3967 3975 3963 3975 3975 Avg: 3973 Dev:  0.3%
3967 3985 3975 3957 3967 3967 3967 3985 3963 3955 3985 3981 3957 3967 3967 Avg: 3969 Dev:  0.4%
3967 3974 3975 3981 3989 3967 3995 3975 3963 3957 3967 3979 3967 3965 3983 Avg: 3973 Dev:  0.6%
3954 3983 3967 3955 3985 3987 3955 3959 3967 3975 3989 3986 3963 3967 3975 Avg: 3971 Dev:  0.5%
3979 3979 3975 3983 3975 3967 3973 3991 3963 3975 3979 3965 3985 3979 3967 Avg: 3975 Dev:  0.4%
3975 3973 3963 3963 3975 3963 3979 3953 3981 3985 3979 3966 3953 3975 3981 Avg: 3970 Dev: -0.4%
3967 3967 3967 3979 3979 3975 3967 3979 3985 3955 3984 3975 3963 3983 3971 Avg: 3973 Dev: -0.5%
3975 3983 3967 3982 3975 3983 3955 3955 3975 3991 3975 3998 3999 3979 3959 Avg: 3976 Dev:  0.6%
3987 3963 3967 3967 3979 3990 3963 3977 3957 3963 3987 3975 3957 3979 3959 Avg: 3971 Dev:  0.5%
3975 3955 3983 3959 3966 3975 3959 3975 3967 3983 3963 3975 3971 3979 3967 Avg: 3970 Dev: -0.4%
3981 3986 3983 3967 3967 3985 3953 3967 3985 3967 3974 3951 3983 3952 3943 Avg: 3969 Dev: -0.7%
3985 3967 3955 3983 3947 3967 3979 3975 3975 3974 3983 3979 3979 3975 3983 Avg: 3973 Dev: -0.7%
3963 3975 3983 3959 3957 3958 3967 3967 3967 3967 3967 3963 3974 3967 3983 Avg: 3967 Dev:  0.4%
3963 3999 3959 3975 3979 3981 3995 3963 3981 3983 3983 3967 3975 3963 3967 Avg: 3975 Dev:  0.6%
3981 3967 3971 3963 3963 3983 3967 3959 3967 3959 3987 3951 3974 3959 3967 Avg: 3967 Dev:  0.5%
3983 3983 3967 3967 3959 3991 3975 3987 3959 3973 3991 3963 3967 3989 3973 Avg: 3975 Dev:  0.4%

ESP-WROVER-KIT V1, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 0

3845 3834 3823 3829 3831 3827 3839 3847 3835 3839 3825 3824 3839 3838 3839 Avg: 3834 Dev:  0.3%
3827 3839 3823 3831 3827 3839 3827 3839 3824 3831 3847 3831 3835 3837 3847 Avg: 3833 Dev:  0.4%
3827 3825 3834 3851 3838 3829 3839 3851 3831 3839 3823 3839 3835 3847 3831 Avg: 3835 Dev:  0.4%
3831 3835 3827 3839 3827 3853 3839 3846 3819 3855 3851 3823 3839 3827 3839 Avg: 3836 Dev:  0.5%
3831 3831 3853 3839 3825 3829 3825 3838 3827 3829 3847 3837 3847 3831 3831 Avg: 3834 Dev:  0.5%
3830 3831 3835 3829 3823 3827 3847 3839 3835 3827 3831 3835 3839 3829 3831 Avg: 3832 Dev:  0.4%
3831 3835 3839 3837 3839 3847 3839 3830 3839 3839 3827 3847 3837 3851 3827 Avg: 3837 Dev:  0.4%
3824 3819 3839 3839 3839 3823 3839 3831 3839 3827 3839 3839 3831 3837 3831 Avg: 3833 Dev: -0.4%
3821 3839 3827 3835 3835 3823 3839 3823 3839 3835 3831 3839 3839 3829 3831 Avg: 3832 Dev: -0.3%
3822 3849 3838 3831 3839 3831 3829 3823 3839 3835 3835 3839 3827 3826 3827 Avg: 3832 Dev:  0.4%
3827 3819 3839 3853 3827 3839 3839 3847 3827 3839 3829 3839 3825 3831 3831 Avg: 3834 Dev:  0.5%
3827 3835 3831 3827 3831 3827 3839 3847 3831 3838 3835 3839 3839 3839 3838 Avg: 3834 Dev:  0.3%
3831 3837 3839 3837 3834 3839 3839 3825 3831 3839 3831 3827 3847 3835 3819 Avg: 3834 Dev: -0.4%
3826 3851 3823 3829 3837 3839 3831 3823 3830 3831 3838 3839 3839 3839 3826 Avg: 3833 Dev:  0.5%
3831 3839 3831 3839 3831 3831 3823 3835 3839 3831 3827 3839 3831 3839 3831 Avg: 3833 Dev: -0.3%
3831 3847 3847 3839 3823 3827 3823 3839 3834 3839 3831 3839 3823 3827 3839 Avg: 3833 Dev:  0.4%
3839 3835 3847 3847 3839 3839 3839 3839 3855 3839 3838 3839 3839 3838 3826 Avg: 3839 Dev:  0.4%
3823 3839 3839 3831 3839 3839 3839 3839 3835 3839 3838 3851 3823 3825 3831 Avg: 3835 Dev:  0.4%
3851 3839 3821 3829 3839 3834 3831 3839 3835 3837 3839 3831 3854 3839 3835 Avg: 3836 Dev:  0.5%
3837 3839 3822 3827 3823 3839 3839 3824 3825 3821 3847 3839 3831 3835 3831 Avg: 3831 Dev:  0.4%
3823 3825 3823 3838 3835 3839 3839 3839 3835 3839 3835 3831 3823 3815 3827 Avg: 3831 Dev: -0.4%
3829 3847 3831 3847 3839 3831 3831 3851 3839 3823 3835 3831 3827 3839 3823 Avg: 3834 Dev:  0.4%
3831 3830 3839 3829 3839 3845 3839 3834 3839 3827 3829 3823 3839 3839 3839 Avg: 3834 Dev:  0.3%
3827 3839 3839 3839 3825 3829 3837 3826 3845 3837 3835 3831 3823 3827 3839 Avg: 3833 Dev:  0.3%
3831 3839 3827 3839 3839 3831 3824 3847 3829 3847 3831 3839 3839 3839 3824 Avg: 3835 Dev:  0.3%
3835 3824 3831 3851 3827 3855 3839 3823 3847 3839 3821 3847 3839 3825 3847 Avg: 3836 Dev:  0.5%
3837 3823 3835 3839 3839 3831 3839 3847 3835 3839 3845 3847 3847 3829 3827 Avg: 3837 Dev: -0.4%
3839 3839 3831 3822 3825 3839 3822 3839 3839 3855 3847 3830 3835 3831 3839 Avg: 3835 Dev:  0.5%
3835 3831 3831 3851 3847 3839 3839 3831 3831 3846 3835 3830 3825 3839 3839 Avg: 3836 Dev:  0.4%
3825 3824 3826 3830 3822 3851 3839 3833 3851 3839 3839 3839 3827 3831 3835 Avg: 3834 Dev:  0.4%

ESP-WROVER-KIT V3, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 1

3863 3859 3863 3855 3855 3859 3863 3863 3863 3857 3856 3853 3853 3853 3855 Avg: 3858 Dev:  0.1%
3855 3855 3862 3839 3839 3847 3855 3856 3851 3863 3855 3855 3851 3847 3863 Avg: 3852 Dev: -0.3%
3855 3863 3871 3867 3855 3863 3855 3859 3859 3855 3857 3853 3855 3855 3855 Avg: 3858 Dev:  0.3%
3857 3857 3857 3861 3855 3855 3854 3857 3859 3855 3867 3855 3854 3862 3857 Avg: 3857 Dev:  0.3%
3858 3858 3869 3859 3851 3855 3851 3867 3855 3870 3855 3851 3855 3853 3855 Avg: 3857 Dev:  0.3%
3847 3855 3859 3861 3857 3859 3839 3867 3863 3857 3854 3847 3859 3857 3856 Avg: 3855 Dev: -0.4%
3857 3856 3859 3855 3856 3879 3855 3857 3858 3855 3851 3856 3859 3856 3860 Avg: 3857 Dev:  0.6%
3855 3861 3862 3855 3855 3869 3859 3855 3859 3859 3855 3823 3859 3863 3854 Avg: 3856 Dev: -0.9%
3859 3857 3856 3847 3855 3859 3859 3859 3855 3857 3859 3858 3859 3855 3847 Avg: 3856 Dev: -0.2%
3856 3854 3857 3857 3859 3853 3861 3863 3854 3855 3863 3862 3855 3859 3855 Avg: 3857 Dev:  0.2%
3863 3863 3856 3855 3857 3858 3859 3863 3856 3855 3871 3856 3859 3853 3869 Avg: 3859 Dev:  0.3%
3854 3855 3859 3863 3862 3858 3847 3857 3855 3855 3857 3855 3839 3879 3853 Avg: 3856 Dev:  0.6%
3857 3857 3839 3861 3867 3855 3855 3855 3863 3857 3847 3855 3862 3855 3859 Avg: 3856 Dev: -0.4%
3855 3831 3855 3847 3853 3854 3859 3851 3855 3855 3870 3862 3861 3855 3853 Avg: 3854 Dev: -0.6%
3847 3853 3847 3855 3855 3839 3869 3847 3863 3857 3863 3871 3823 3859 3851 Avg: 3853 Dev: -0.8%
3859 3867 3855 3855 3847 3855 3847 3856 3855 3855 3855 3851 3855 3851 3839 Avg: 3853 Dev:  0.4%
3857 3859 3851 3855 3847 3855 3851 3845 3859 3859 3859 3859 3853 3858 3855 Avg: 3854 Dev: -0.2%
3851 3857 3861 3858 3859 3855 3859 3856 3839 3855 3863 3871 3879 3859 3863 Avg: 3859 Dev:  0.5%
3839 3847 3855 3854 3855 3855 3859 3855 3855 3859 3863 3859 3867 3867 3860 Avg: 3856 Dev: -0.4%
3861 3862 3851 3857 3862 3847 3850 3851 3858 3857 3856 3853 3863 3863 3855 Avg: 3856 Dev: -0.2%
3855 3859 3863 3855 3863 3854 3867 3856 3867 3853 3859 3858 3847 3867 3855 Avg: 3858 Dev: -0.3%
3853 3855 3855 3855 3855 3853 3847 3847 3860 3855 3871 3855 3847 3839 3863 Avg: 3854 Dev:  0.4%
3855 3855 3859 3851 3861 3856 3861 3847 3855 3855 3861 3851 3857 3847 3851 Avg: 3854 Dev:  0.2%
3863 3861 3859 3856 3855 3863 3861 3861 3858 3859 3845 3857 3859 3862 3847 Avg: 3857 Dev: -0.3%
3857 3857 3863 3862 3857 3855 3855 3851 3855 3851 3856 3857 3863 3856 3857 Avg: 3856 Dev:  0.2%
3859 3856 3863 3853 3839 3861 3851 3854 3856 3863 3847 3855 3871 3859 3851 Avg: 3855 Dev:  0.4%
3853 3859 3851 3867 3855 3859 3857 3857 3851 3855 3855 3855 3855 3849 3859 Avg: 3855 Dev:  0.3%
3857 3855 3871 3870 3855 3859 3857 3859 3855 3855 3857 3856 3859 3887 3855 Avg: 3860 Dev:  0.7%
3847 3855 3859 3857 3858 3863 3867 3855 3861 3855 3839 3851 3863 3867 3863 Avg: 3857 Dev: -0.5%
3855 3851 3851 3853 3847 3867 3855 3851 3858 3878 3886 3851 3859 3855 3856 Avg: 3858 Dev:  0.7%

ESP-WROVER-KIT V3, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 1

3738 3727 3731 3734 3729 3731 3739 3730 3741 3731 3739 3739 3735 3735 3733 Avg: 3734 Dev:  0.2%
3728 3733 3739 3731 3735 3733 3743 3731 3735 3731 3728 3739 3737 3731 3735 Avg: 3733 Dev:  0.3%
3731 3728 3731 3735 3735 3731 3743 3739 3731 3735 3728 3739 3729 3733 3739 Avg: 3733 Dev:  0.3%
3739 3743 3728 3739 3739 3728 3739 3735 3742 3735 3738 3735 3734 3741 3737 Avg: 3736 Dev: -0.2%
3719 3735 3747 3725 3735 3741 3729 3733 3731 3743 3731 3729 3739 3731 3735 Avg: 3733 Dev:  0.4%
3731 3733 3731 3730 3739 3741 3729 3741 3731 3741 3739 3735 3735 3733 3729 Avg: 3734 Dev:  0.2%
3739 3731 3738 3741 3743 3738 3731 3729 3731 3735 3738 3729 3735 3735 3743 Avg: 3735 Dev:  0.2%
3735 3743 3739 3743 3731 3733 3739 3733 3734 3731 3731 3729 3739 3739 3735 Avg: 3735 Dev:  0.2%
3739 3731 3739 3743 3735 3735 3727 3731 3733 3735 3739 3733 3731 3735 3735 Avg: 3734 Dev:  0.2%
3731 3739 3733 3734 3735 3735 3738 3732 3735 3729 3727 3741 3743 3731 3739 Avg: 3734 Dev:  0.2%
3729 3731 3734 3731 3742 3737 3735 3733 3735 3735 3746 3739 3735 3739 3739 Avg: 3736 Dev:  0.3%
3731 3735 3735 3728 3741 3727 3735 3735 3729 3735 3738 3741 3733 3739 3727 Avg: 3733 Dev:  0.2%
3739 3739 3727 3735 3735 3733 3739 3727 3741 3735 3739 3739 3735 3731 3739 Avg: 3735 Dev: -0.2%
3729 3735 3731 3733 3735 3739 3735 3738 3733 3731 3743 3735 3741 3735 3735 Avg: 3735 Dev:  0.2%
3735 3735 3731 3735 3743 3731 3731 3750 3743 3735 3735 3731 3735 3733 3734 Avg: 3735 Dev:  0.4%
3741 3735 3731 3731 3743 3731 3735 3735 3735 3727 3743 3735 3729 3731 3731 Avg: 3734 Dev:  0.2%
3735 3743 3731 3725 3741 3735 3739 3743 3733 3746 3739 3743 3728 3735 3739 Avg: 3737 Dev: -0.3%
3731 3735 3731 3749 3729 3731 3733 3743 3743 3739 3733 3731 3739 3731 3743 Avg: 3736 Dev:  0.3%
3733 3731 3731 3731 3728 3743 3739 3739 3735 3735 3735 3735 3741 3743 3739 Avg: 3735 Dev:  0.2%
3743 3735 3735 3733 3743 3751 3743 3739 3743 3743 3719 3739 3729 3727 3733 Avg: 3737 Dev: -0.5%
3731 3739 3733 3731 3741 3735 3735 3735 3731 3729 3739 3735 3731 3729 3738 Avg: 3734 Dev:  0.2%
3731 3735 3730 3741 3742 3729 3742 3743 3733 3743 3735 3735 3733 3731 3731 Avg: 3735 Dev:  0.2%
3739 3733 3729 3739 3731 3729 3731 3735 3731 3733 3735 3735 3730 3735 3739 Avg: 3733 Dev:  0.2%
3731 3733 3731 3729 3739 3734 3730 3727 3735 3729 3731 3731 3743 3730 3733 Avg: 3732 Dev:  0.3%
3751 3731 3743 3739 3735 3738 3747 3733 3731 3739 3739 3732 3739 3743 3735 Avg: 3738 Dev:  0.3%
3731 3751 3739 3733 3733 3739 3735 3743 3731 3739 3743 3729 3739 3731 3731 Avg: 3736 Dev:  0.4%
3731 3731 3731 3742 3739 3741 3743 3739 3733 3728 3733 3735 3735 3730 3729 Avg: 3734 Dev:  0.2%
3731 3739 3743 3735 3741 3742 3743 3731 3728 3731 3731 3729 3729 3739 3743 Avg: 3735 Dev:  0.2%
3731 3735 3731 3743 3733 3731 3741 3734 3731 3735 3731 3735 3739 3739 3738 Avg: 3735 Dev:  0.2%
3731 3733 3731 3735 3735 3731 3735 3735 3731 3735 3731 3729 3735 3731 3739 Avg: 3733 Dev:  0.2%

@krzychb
super results , and nice work , complements with the results of <0.5% of 1V input
Did you compare also for the other ports as GPIO34 , one of the complains was that we had to calibrate for each port individual , what will kill the case , but overall the fun
are you still capable to do multiple AD channels with an 0.1 sec refresch ?

This editor is not supporting to attach xxx.ino file.
I am not expert of github, and I have no time to play at the moment. I attach as an txt.
Chip_EVB_ADC_Test.txt

I have studied a bit of wrover kit, I don't see any specific what would validate the result..
All wrover-kit boards give this good result?

Csaba,

Below are sample results for three ESP-WROVER-KIT boards using your sketch. This is to give some indication what variation of measurements to expect. I would not judge for other wrover-kit boards. My general observation is that ADC measurements perform better on ESP-WROVER-KIT comparing to e.g. ESP32-DevKitC or ESP32-EVB. This is likely related to layout of power distribution, overall layout of traces and components on PCB, selection of decoupling capacitors, etc.

ESP-WROVER-KIT V1, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 0

esp-wrover-kit-v1_3v_11db

ESP-WROVER-KIT V2, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 0

esp-wrover-kit-v2_3v_11db

ESP-WROVER-KIT V3, GPIO34 = 3.000V, ADC_ATTEN_11db, Silicon Rev 1

esp-wrover-kit-v3_3v_11db

ESP-WROVER-KIT V1, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 0

esp-wrover-kit-v1_1v_0db

ESP-WROVER-KIT V2, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 0

esp-wrover-ki-v2_1v_0db

ESP-WROVER-KIT V3, GPIO34 = 1.000V, ADC_ATTEN_0db, Silicon Rev 1

esp-wrover-ki-v3_1v_0db

Thanks Krzysztof!
At least we see there is possible to make close reach to 10 bit ADCs (Chipkit, Arduino boards) with ESP32.
There is some light at the end of the tunnel.

We could use the ESP32 ADC in other application too, if the real secret of Wrover-Kit would be revealed.
I have no idea how to make it!

Thanks Krzysztof! , im reading your results with interest
i will buy one of these and see if that really make the difference
however if layout an powersuply would be the problem, expected , the manufacturer , would have give out pcb instructions , for sure i checked the rimple on the power supply before we published the ADC problems
i did not see reactions of the manufacturer in these
one question did you also use multiple analog inputs at the same time ?

@igrr Maybe we can try to close this issue.

@jack0c expectations of accuracy/precision should be documented

The issue has not been solved!
I hope somebody will present a reproducible solution, at least to reach the Arduino 10 bit performance, what was not an issue with any board I tried.
Should we close the issue, when the problem still exist?

pls leave it open , as it is a real problem in using this chip as it was intended
the worst was that you have to calibrate for each chanel seperatly , which is undoable

i hope the manufacturer will solve this with a newer version

I have here following settings with a chip ESP32D0WDQ6 (revision 1) (WROOM32) powered by exactly 3,3V Vcc:

analogSetWidth(10); // 10Bit resolution
analogSetAttenuation((adc_attenuation_t)0); // 0=0db (0..1V) 1= 2,5dB; 2=-6dB (0..2V); 3=-11dB

I expected to get a reasonable linearity and ADC=512 upon applying 0,5V on pin SVP.

In fact I get 459. That is about 10% error!

I'm trying to use the ADC on an ESP-WROOM-32, and I'm not quite understanding where this issue left off.

the worst was that you have to calibrate for each chanel seperatly , which is undoable

Acknowledging that this is a massive pain, for what I'm doing right now, that seems feasible. I've read the documentation for ADC Calibration, but I'm not quite understanding the process. Can someone lay out how to get usable values out of the ADC today given a single channel on a single chip?

With the chip I'm using I don't have the two point values or reference voltage stored in eFuse, so I understand it's using the default Vref. While the values coming out of the ADC are not particularly close, I've applied a non-linear compensation and it seems to be working reasonably well - this says to me that it's likely usable if I do the right thing. How do we find a more accurate Vref?

Can we use external ADC chip like MCP3008 or something else to get better results?
Actually, I am working on LoPy modules which are based on ESP32. And I need to get the correct reading of soil moistures. Please, someone, help. Novice here.

Sure you can. I am using ADS1115 ADC's and they are working fine. Library and sample code are available.

Am 4. Juni 2018 11:20:27 MESZ schrieb shivankgarg98 notifications@github.com:

Can we use external ADC chip like MCP3008 or something else to get
better results?
Actually, I am working on LoPy modules which are based on ESP32. And I
need to get the correct reading of soil moistures. Please, someone,
help. Novice here.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/espressif/esp-idf/issues/164#issuecomment-394289570

Yes, we can use ADS, but for Arduino and other MCUs you don't need it, if 10 bit precision is enough, what works reasonably many times (STM32 12 bit, Teensy 11bit).
The ESP32 ADC has not only calibration problem. Huge noise too. Calibration problem could be handled with some effort. Noise makes the internal ADC usable at about 8 bit precision, what is a big disadvantage on the comparison with other MCUs.

8 bit precision is like knowing its hot but not knowing the temperature

Hello all,

I am quite new with ESP32 and I am facing an issue I can't solve: I want to get a TFT Touch (resisitv) working and I have the 4 wires (X+,X- and Y+,Y-). Working with the ADC I can get the X position or the Y position alone but no way that I get both of them simultaneously.
I have put some delays, combine them in different functions but something is crashing when I combine the two:
gpio_set_direction(GPIO_NUM_33, GPIO_MODE_OUTPUT); //X+
gpio_set_level(GPIO_NUM_33, 1);
gpio_set_direction(GPIO_NUM_26, GPIO_MODE_OUTPUT); //X-
gpio_set_level(GPIO_NUM_26, 0);
gpio_set_direction(GPIO_NUM_25, GPIO_MODE_OUTPUT); //Y-
gpio_set_level(GPIO_NUM_25, 0);
gpio_set_direction(GPIO_NUM_32, GPIO_MODE_INPUT); //Y+
adc1_config_width(3);
adc1_config_channel_atten(ADC1_CHANNEL_4, ADC_ATTEN_11db); //3v3 signal from TFT
X=adc1_get_raw(ADC1_CHANNEL_4)/(4096/240);//Reads X axis touch position
gpio_set_direction(GPIO_NUM_32, GPIO_MODE_OUTPUT); //Y+
gpio_set_level(GPIO_NUM_32, 1);
gpio_set_direction(GPIO_NUM_33, GPIO_MODE_INPUT); //X+
adc1_config_width(3);
adc1_config_channel_atten(ADC1_CHANNEL_5, ADC_ATTEN_11db); //3v3 signal from TFT
Y=adc1_get_raw(ADC1_CHANNEL_5)/(4096/320);//Reads Y axis touch position
printf("X=%d Y=%d\r\n", X, Y);

I only get 0. Has one of you already face that problem?

Hardware revision required!

There is no need for reference voltage calibration and crap. The process of making a ADC is to deliver a product ready to use. If calibration is needed is has to be made in the manufacturing process and not made a software issue.

The hardware issue should not be fixed by customers spending time calibrating.

The biggest problem is it has an offset error so any voltage below ~100mV will return 0.

Secondly it has reference voltages worse than a two resistor voltage divider. On top of that it is so unlinear it can not possibly be made properly using the simplest ADC principles.

Tested a few ESP-WROOM-32 and an early Lolin 32 Lite with a PWM output sweep heavily filtered using both a 1k and 10k resistor charging 1000µF//220nF capacitors close to ADC input.

The ADC ranges 0..3 tested and all have a starting offset, but the highest ADC range is really bad.

esp32_adc_vs_pwm_dac_2

Unacceptable

Espressif - Fix the hardware!

A closer look at the offset at which each ADC attenuation range produces a reading. The PWM high side is 3.4 Volts so PWM filtered DC voltage is 3.4/4096 = 0.83 mV/tick

In my case ADC readings starts ticking from:
Range 0 & 1 = 85 * 0.83 = 71mV
Range 2 = 110 * 0.83 = 91 mV
Range 3 = 148 * 0.83 = 123 mV

adc_sweep_2018-11-21_215115
Chart - The offsets makes it harder to read smaller voltages in the 100mV range out of the box.

adc_sweep_2018-11-21_162935
Chart - Range 3, gray curve is more than unlinear.

@projectgus
Hi, are there planned hardware revisions aiming at correcting the adc's offset and non linearity issues?
I say hardware because, unlike the non linearity problem that can be "masked" by using the inverse of a "custom" fitting curve (I say "masked" because you're losing resolution anyway in the non linear zone of the adc characteristic), the offset problem can not be corrected via software, neither by the user nor by the manufacturer, hence an hardware review is the only possible solution.

Our small company would really really like to adopt your ESP32 Wroom as "core" for all our present and future projects, still this adc issues makes such a choice really impratical and risky, unless one can be assured that, in the immediate future, hardware revisions aiming at solvinh those issues are planned.
And I guess that our small company is not alone in this feeling.
You have already one of the best quality/price SOIC on the market, but having it with tha adc issues corrected, in my humble opinion, would automatically make you not one of the best, but THE best.

I'm wondering how products from particle.io are using the A2D on ESP32.
trying to use it with a temp sensor, with the readings being completely unusable.

on an other case we discovered the origing of the non liniarity was an overvoltage protection zener already conducting , could that here also the case inthe esp32 , nothing we can change ourselves

@Alteregoxxx would you switch to a different soc/module before adding an external adc? Which one? Just curious.

I am also seeing serious issues with the ADC. Tests on a 1 kHz sine wave input show significant variations from one period to the next. On the WROOM version achieving 12-bit resolution is impossible. By the way particle.io uses ESP32 only for WiFi. They have a separate STM microcontroller with an excellent ADC.

For my project I got over the noise issue on the ADC inputs by taking an average reading over 50 samples taken 1ms apart. This produces a steady, stable and usable voltage reading where any errors can consistently be adjusted /compensated for. I repeat this process once a second to update my project and that works well for me.

In my application averaging is not an option - I need to operate at a sampling rate of 500000 samples/second.

Anyone noticed a gap between the values 2303 and 2353? I'm not able the read any voltages between this values :/.

Tested on ADC1 channel 3 and 7 with 0db and -6db on two different ESP32 Dev Boards.

The poor performance of the ADC makes the otherwise fantastic ESP32 useless for many applications. I have abandoned it in favor of Particle Photon.

was this fixed/is it being fixed in a newer revision of the chip?

The poor performance of the ADC makes the otherwise fantastic ESP32 useless for many applications. I have abandoned it in favor of Particle Photon.

@srini1948 just add the ads1115 and you'll have a much better and cheaper solution than a particle photon. I've got over 4,000 Particle P1's (the module chip version of the photon when you're producing large quantities) in the field and I'm moving our product across the ESP32.

does the latest idf fix thsi issue or not? other than ADC i have no problems. yet without proper ADC using this board seems useless.

No IDF does not solve the problem.

alright, I hope this will be fixed near to arduino or even better on the next hardware or software release

srly, just use an ads1115. its much better than onboard ADC and has a number of filtering and protection benefits.

srly, just use an ads1115. its _much_ better than onboard ADC and has a number of filtering and protection benefits.

I thought the same thing before finding this post, after 3 weeks lost, I'll use an external ADC.
Now, I'm testing ADS7142 and MCP3221.

I know it's closed but still want to say... not good :-)

Been following this issue for 2 years now. Still no solution. At the point I can only believe that it is not a priority or cannot be solved by Espressif. Such a shame since the ESP32 is such a great board for IoT dev otherwise.

Yeah I am now using dedicated adc. its not much trouble but its kinda hassle to layout in PCB and all extra code footprint. well its a nice workaround but as we know it should have been working. people are buying this because of a need. now maybe it is too expensive to solve it. lets just wait for the next version of the board.

The internal ADC gives between 4 and 5 LSB`s noise.

Hi,
I'm new in this and looking into ESP32. I found and am aware of the cuple of errors of the ADC of this part. With my work I found a very strange behavior of the ADC. My observation looks into the huge amount of noise in the measurement of a stable voltage:

My setting:
ESP32 devkit v1
attenuation 0db
resolution 12 bit
one sample on GPIO34 every one ms
filtering with a simple Kalman filter
output on COM port every 100 ms

The min and max readings are stored over the output periode and sent together with the result of the filter.

My observation:
Over a time of about 17 seconds I can see the expected huge noise, but then for abaut 1.4sec. the noise is dramatical reduced. Then the periode repeats.
Attached a picture.
Variations of the settings do not have any influence.

It seems that the ADC in special conditions is able to give a quite low noisy reading, but this conditions are mostly not present?
Is there any explanation for this behavior?

adc2b

This ADC is a piece of junk. Don’t use it. I gave up on this chip 2 years ago because of this. Sent from Mail for Windows 10 From: wosch1Sent: Saturday, March 14, 2020 12:38 PMTo: espressif/esp-idfCc: srini1948; MentionSubject: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164) Hi,I'm new in this and looking into ESP32. I found and am aware of the cuple of errors of the ADC of this part. With my work I found a very strange behavior of the ADC. My observation looks into the huge amount of noise in the measurement of a stable voltage:My setting:ESP32 devkit v1attenuation 0dbresolution 12 bitone sample on GPIO34 every one msfiltering with a simple Kalman filteroutput on COM port every 100 msThe min and max readings are stored over the output periode and sent together with the result of the filter.My observation:Over a time of about 17 seconds I can see the expected huge noise, but then for abaut 1.4sec. the noise is dramatical reduced. Then the periode repeats.Attached a picture.Variations of the settings do not have any influence.It seems that the ADC in special conditions is able to give a quite low noisy reading, but this conditions are mostly not present?Is there any explanation for this behavior?—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. 

Thanks for reply, I think you are right at all. But I am interrestet in the mechanics of the error. My mesurement show that the ADC periodically is able to sample the voltage over a time of about 1.5 s ( equals about 1500 samples) with a rather little noise. Why not during the other time? If one this could find out, the part would be a bit more useable.

It is a pretty interesting result but that large of a period it seems like it is probably an external factor. What are your test conditions and what chip features are enabled?

Afaik I have no special chip features enabled in my sketch. It id not a real gadget, rather a workbench test. So in the vicinty is nothing with such a timing.
Is it possible that the second core is working something I dont know?
I have done some experiments with WIFI and BT with this devkit before, but not stored anything permanent. Could there be a leftover from that?
The measured values are raw binary from the ADC (except the Kalman fitered value). Some infos in my first post. Attached a further picture. It shows the difference between the lowest and the highest reading over the COM sendperiod multiplied by 10.
If you are interrested, I can send my code.
adc4

For further explanation. I stored the min and max readvalues during the time between the serial messages. Then I send the difference ((vmax-vmin)10). Sampling occures every one ms, that means I sample100 readings. The blue line shows the diff between the highest and the lowest read value from this 100.(10)

Has anybody tried with the WiFi turned off? The problem could be related to internal or external ground currents. When the radio is on, ground current could be causing voltage drops that are effectively in series with either the input to the ADC, or the internal reference, or both. A long ago I was tasked with reducing the noise of a 13-bit ADC that was implemented with discrete components. I improved it by >10 dB by changing the PCB layout so the ground current from other digital components flowed through separate paths so the ADC did not "see" the ever-changing ground voltage drop caused by the digital switching.

In addition to ground current errors, the noise could be caused by other forms of interference from the radio. The antenna is very close to the SVN and SVP pins. There is a ground pin on the module that is quite close to the SVN and SVP pins, but the nearest GND pins on the dev boards are rather far away - one is on the other row of pins and another is at the other end of the row of pins from SVN/SVP. Given that, and the high currents involved in the radio, I suspect that this is a difficult problem to fix. I think an external ADC might be the only solution if low noise and high sample rate is required. We shall see how the new ESP32-S2 fares in this regard...

The least expensive external ADC solution might be to add an ATTiny MCU. They cost about $0.30 in quantity, and have a 10 bit ADC that can sample one of several input pins and can accessed from another MCU via I2C. For not much more money, you can get a STM32G030J with a 32-bit MCU and 12-bit ADCs.

Without the ADC linearity problem fixed the ESP32 is like a ten floor building without an elevator. Wonder why the spent so much effort to make the product, and do not care about completing it?

Wonder how they think and where the thinking is located? What kind of reasoning can justify ignoring this gigant problem? Is it costly, impossible or some policy to never fix a broken thing?

It is a mystery.

That's a very extreme position to take. Lots of applications do not require an ADC at all, others can get by with limited resolution ADC, still others can get by with slow ADC (noise reduction via averaging), and the linearity issue can be handled in software. Obviously it would be preferable to have a good ADC, but even without it, ESP32 is very good functionality for the money.

Regarding "why don't they fix it": do you have any idea how much it costs to do a mask set and other NRE for a microprocessor? Apparently you do not. Fixing an existing product, especially if the fix requires deep changes to layout, is often much less economical than coming out with a new product. The new ESP32-S2 is already starting production, slated to be out this summer, modulo coronavirus. We can hope that they have improved the ADC on that one. Maybe they have and maybe they haven't, but even if not, the new chip has impressive functionality and price/performance if the price is anywhere comparable to the old ESP32.

As Mark Twain said "To do good is noble. To tell other to do good is even nobler and much less trouble."

@mitchbreadly --> i disagree
if you were one of the first users , and spend hunderd of hours , getting it to work , and on the end it will not work by faulty specifications , you would think otherwise
and errors in technicue occur , its your attitude to fix it ( or not in this case )

It's true, a lot of applications do not need a very accurate ADC. In my case it's just the interest to understand and to find solutions for "as good as possible without attended invest".
I think, the ESP's rather bad ADC is a "accident" in developement/design of the part and the investment to fix it is to high. As you said.
But as you can see on my measurement, there are periodical times (1.5s) who the part is able to give results with rather low noise. What is the reason for the huge noise in the other time (17s)?
Althoug in my sketch WIFI and BT are not used I switched both off explicitly. The strange behavior stays unchanged. A cuple of changes in my timing (samplerate, outputrate) and filtering ( Kalman, moving average) have no effect at all. Check of the supply gave no indication (USB 5V) for a variation. Could a watchdog timer or RTC or similar do this? I have none activated (knowingly).

Addentum: At the moment I am not looking in the linearity or offset problems.

I can also see a variation in ADC behavior every 17s. I sample four channels every second and send the measured values through wifi/mqtt. Every 17s I have one value measuring about 100mV less than for the rest of the time.

Auswahl_026

That's a very extreme position to take. Lots of applications do not require an ADC at all, others can get by with limited resolution ADC, still others can get by with slow ADC (noise reduction via averaging), and the linearity issue can be handled in software. Obviously it would be preferable to have a good ADC, but even without it, ESP32 is very good functionality for the money.

Regarding "why don't they fix it": do you have any idea how much it costs to do a mask set and other NRE for a microprocessor? Apparently you do not. Fixing an existing product, especially if the fix requires deep changes to layout, is often much less economical than coming out with a new product. The new ESP32-S2 is already starting production, slated to be out this summer, modulo coronavirus. We can hope that they have improved the ADC on that one. Maybe they have and maybe they haven't, but even if not, the new chip has impressive functionality and price/performance if the price is anywhere comparable to the old ESP32.

As Mark Twain said "To do good is noble. To tell other to do good is even nobler and much less trouble."

Espressif is so silent about the problem. When cars catch fire at lest manufacturers show the have a plan or worry about the problem.

It should be stated in the datasheet the ADC has serious issues. Lot of companies start off thinking this any MPU with an ADC and slowly find out it has shaky readings an a terrible offset where calibration does not help.

Honesty and being service minded will work too.

When cars catch fire at lest manufacturers show the have a plan or worry about the problem.

When Toyotas were accelerating out of control, the response for a long time was denial. Volkswagen similarly denied the diesel emission cheating for a long time. Ralph Nader became famous by revealing that car manufacturers were hiding safety problems Hiding problems is not good, but it is common. In a company, it is pretty difficult to get rewarded for being honest about problems, especially when it could hurt sales, but it is pretty easy to get fired. That's the way the world works. It sucks, but it is what it is.

There are detailed instructions how to read analog values on the ADC-page of Espressif. You have to use multisampling! I collect 20 values, sort them and remove the two smallest and the two greatest to filter wrong ones. Then i calculate the average of the left values. These values can be collected, sorted and filtered again to get a more stable result. I get usable temperatures of a Pt1000 with only a simple voltage divider this way, even with WiFi enabled.

@projectgus --> thanks for the sugestions , is this some ESP sugests on there side ?? . your saying more or les 2 out of 10 readings are rubbisch . We tried even 100* oversampling . and we had no usable result inside a decents acuracy

There are detailed instructions how to read analog values on the ADC-page of Espressif. You have to use multisampling! I collect 20 values, sort them and remove the two smallest and the two greatest to filter wrong ones. Then i calculate the average of the left values. These values can be collected, sorted and filtered again to get a more stable result. I get usable temperatures of a Pt1000 with only a simple voltage divider this way, even with WiFi enabled.

yes that works, but still wont solve the linearity of the reading. those are just sampling techniques we can implement. to fix the linearity it is so laborious to calibrate 1 esp at a time

Yes, Espressif suggests multisampling. I did some measurement series with a Pt1000 and some values were wrong. With 16 values out of 20 i get good results from -5°C to 140°C. I'm using it for a thermal solar control for over 3 months now.

---- jan-bozelie schrieb ----

@projectgushttps://github.com/projectgus --> thanks for the sugestions , is this some ESP sugests on there side ?? . your saying more or les 2 out of 10 readings are rubbisch . We tried even 100* oversampling . and we had no usable result inside a decents acuracy

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-idf/issues/164#issuecomment-624463666, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADABDAWOFSWLRTLA2CYRERLRQD62TANCNFSM4CZVWPTQ.

_20200506_215817

Hi,
we have to make a difference between hobbyists and professionals. A hobbyist can calibrate each exemplar of his Project, which is unacceptable for a professional.
In my opinion the biggest problem ist the "dead zone" near zero. So a correct measurement of a voltage for example isn't possible in this region.

After so many years, it's evident that the ADC was implemented merely for marketing reasons (:

I think we will be missing a proper apology from Espressif on this matter. And of course we can forget about a reliable ADC until they can sell us one.

But we do take note, @Espressif, we do take note.

I don't think so. There is a formula how to compensate non-linearity in this thread. The chip has a reference voltage wich could cause offset-problems. You need to get a known voltage to an input pin, then You can calculate the Offset too!
…
---- raevillena schrieb ---- There are detailed instructions how to read analog values on the ADC-page of Espressif. You have to use multisampling! I collect 20 values, sort them and remove the two smallest and the two greatest to filter wrong ones. Then i calculate the average of the left values. These values can be collected, sorted and filtered again to get a more stable result. I get usable temperatures of a Pt1000 with only a simple voltage divider this way, even with WiFi enabled. yes that works, but still wont solve the linearity of the reading. those are just sampling techniques we can implement. to fix the linearity it is so laborious to calibrate 1 esp at a time — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#164 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADABDAXXU7AOQCKLDZZCMPDRQFF6LANCNFSM4CZVWPTQ.

yes i understand and i have tried that already. but like i said Its just to laborious and waste of computing cycles just for compensation, for a code that is time critical, sometimes assync. hmm nahh.

Some Comments on ADC noise and accuracy from someone who designed data converters embedded into SOC's.
Although the Espressif spec says ADC1 has a resolution of 12 bits it is impractical to use it as a 12bit ADC. The specified DNL is +/- 8lsb or 2.1mv. This means ADC1 is a 9bit converter(lsb->2.15mv). In a SOC design using a junction isolated CMOS process such as TSMC 40nm the noise floor is typically above 1mv rms. This noise can be either correlated to clocks or pink due to the nature of the radio system. The only practical solution is averaging based on characterization of the application environment. I would be impressed if Espressif achieved 10 bits accuracy.

My issue is the conversion error vs input voltage. I would really like someone for Espressif to comment and provide compensation information. If the error is repeatable it can be corrected.
Thanks,
Tekguy49

This issues has any update?

It ain't a bug, it is working fine for me. You can find detailed information about multisampling on Espressif's ADC-site!

It is a bug. It is a 12bit ADC with 3LSB's of noise leaving only 9bits of
resolution if you do multisample or remove the noise with a filter. A 12bit
ADC should have at least 12*6dB=72dB S/N. Even the cheap ones does.

On Fri, Dec 11, 2020, 8:03 PM Sven Bieg notifications@github.com wrote:

It ain't a bug, it is working fine for me. You can find detailed
information about multisampling on Espressif's ADC-site!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-743369040,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHUW5TMSX25RL7UMSDXMK3SUJUHDANCNFSM4CZVWPTQ
.

This is a comparison to other chips, no bug.

No it is not. A 12 bit ADC should be capable of capturing a signal with at
least 72dB S/N (the math is (resolution*6)+3=S/N) The ESP32 is only capable
of capturing a signal with 54dB S/N. So there is a serious bug in the
hardware.

On Fri, Dec 11, 2020, 10:22 PM Sven Bieg notifications@github.com wrote:

This is a comparison to other chips, no bug.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-743433552,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHUW5XYDOL767UKTE7UOHDSUKESZANCNFSM4CZVWPTQ
.

I don't think Espressif is promising this accuracy.

You can use the ADC with multisampling, calibration and ... but never will get from ESP32 such a reliable result as from a good ADC like ADS1115.
It depends on your needs - since a long time I do not longer use ESP32 ADC for any sensors,... do not trust the results more ;)
But for simple control of values it is ok.

They do. They are promising 12bits of resolution

On Sat, Dec 12, 2020, 12:43 AM Sven Bieg notifications@github.com wrote:

I don't think Espressif is promising this accuracy.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-743483993,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHUW5WBSGFJZFFJ6MGCCR3SUKVDPANCNFSM4CZVWPTQ
.

What news about new ESP32-C3?

They solved ADC hardware bug?

Thanks

@VincentBruinink is it possible you might be confusing number of bits (12) for effective number of bits (ENOB, not sure if specified)?

I don't think Espressif is promising this accuracy.

It ain't a bug, it is working fine for me. You can find detailed information about multisampling on Espressif's ADC-site!

You've made it clear where you sit in the spectrum of people purchasing this chip. We've heard you. You're also dead set wrong for commercial applications, but that's ok, you do you.

For anyone serious, ADS1119IPWR. It's next level tech from TI with proper input buffers (we've got 1Mohm sources) / internal reference / I2C / 16bit / PGA and common noise rejection at 20 SPS.

Nope. It is specified as a 12-bit SAR ADC.

On Sat, Dec 12, 2020, 5:00 PM Richard Allen notifications@github.com
wrote:

@VincentBruinink https://github.com/VincentBruinink is it possible you
might be confusing number of bits (12) for effective number of bits (ENOB,
not sure if specified)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-743776539,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHUW5TD6CE64A4CEVTMHZDSUOHRDANCNFSM4CZVWPTQ
.

Nope. It is specified as a 12-bit SAR ADC.

Just because the ADC is specified as 12 bits does not mean that you get 12 bits of useful data. You can have a million-bit ADC with a noisy power supply and you might be lucky to get 2 bits of actual information. The longstanding problems with the ESP32 ADC are in the noise category. Depending on the phase of the moon it will generate useful results for awhile, then the answer will jump around with no change in the input voltage. It is probably picking up noise from some other subsystem in the chip turning on and off. It could be related to the radio, or the cache, or some I/O device; so far nobody has figured it out for sure. Maybe Espressif knows, but if so they are not saying. It is really hard to get precision analog results from a system-on-chip that has as many digital and radio functions as ESP32. The best analog systems have strict isolation between digital circuitry and analog areas, with careful separation of ground paths, power routing, and galvanic/magnetic isolation of critical analog areas. That is really tricky to do all on one small die that has many other functions and especially that has too few pins to allow separate power and ground for analog circuits. Most likely, the ESP32 ADC was included just to check a box on a marketing bullet list. It can be useful for low-accuracy stuff like monitoring battery voltage, but getting high accuracy requires serious averaging. Even that is of questionable utility, since the noise is not gaussian - it tends to be step functions that jump around at hard-to-predict times.

Even with the WIFI RF turned off, good isolated power supply and only using
the analog input, the 3 LSB's of noise remain. You can't even measure
voltage correctly. It is that bad.

With the AVR microcontrollers which has 10bit ADC you get easily 60dB of
resolution and 1LSB of noise even without using a dedicated analog REF
power supply.

With ARM controllers which has 12bit ADC you get easily 74dB of resolution
even without using a dedicated analog REF power supply.

So ADC embedded in a controller is not a problem at all but for Espressif
it is.

On Mon, Dec 14, 2020, 6:47 PM Mitch Bradley notifications@github.com
wrote:

Nope. It is specified as a 12-bit SAR ADC.

Just because the ADC is specified as 12 bits does not mean that you get 12
bits of useful data. You can have a million-bit ADC with a noisy power
supply and you might be lucky to get 2 bits of actual information. The
longstanding problems with the ESP32 ADC are in the noise category.
Depending on the phase of the moon it will generate useful results for
awhile, then the answer will jump around with no change in the input
voltage. It is probably picking up noise from some other subsystem in the
chip turning on and off. It could be related to the radio, or the cache, or
some I/O device; so far nobody has figured it out for sure. Maybe Espressif
knows, but if so they are not saying. It is really hard to get precision
analog results from a system-on-chip that has as many digital and radio
functions as ESP32. The best analog systems have strict isolation between
digital circuitry and analog areas, with careful separation of ground
paths, power routing, and galvanic/magnetic isolation of critical analog
areas. That is really tricky to do all on one small die that has many other
functions and especially that has too few pins to allow separate power and
ground for analog circuits. Most likely, the ESP32 ADC was included just to
check a box on a marketing bullet list. It can be useful for low-accuracy
stuff like monitoring battery voltage, but getting high accuracy requires
serious averaging. Even that is of questionable utility, since the noise is
not gaussian - it tends to be step functions that jump around at
hard-to-predict times.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/164#issuecomment-744602578,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHUW5VZOHHKCKZNTBX2LYLSUZFS3ANCNFSM4CZVWPTQ
.

The ADC has unusual linearity and offset drawbacks. When feed a linear ramp the lowest range is terribly non linear.

ESP32_ADC_vs_PWM_DAC_2

Also the ADC is "dead" with no reading below 100 LSB on a 4096 scale depending on amplification.

ADC_Sweep_2018-11-20_123554

It means the ADC inputs have to be offset with external components to start measuring from 0V. That is really bad.

We can live with the noise, and it is not hat bad as you can see from the multisampled curve. But the ADC being detached from reality makes it a bad experience. The ESP32 is a fantastic device it is such a pity the ADC problem never gets corrected.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

me21 picture me21  Â·  3Comments

waayst picture waayst  Â·  4Comments

howroyd picture howroyd  Â·  3Comments

feelfreelinux picture feelfreelinux  Â·  4Comments

kylefelipe picture kylefelipe  Â·  3Comments