[TW#12287] ESP32 ADC accuracy

[nassks]

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.

[markterrill]

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.

[VincentBruinink]

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 .

[MitchBradley]

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.

[VincentBruinink]

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 .

[flodmotorgrodan]

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

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

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 that 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.

[pylorak]

This is a comparison to other chips, no bug.

Actually, this probably is a bug. It becomes more clear to see it when you have some additional context. The ESP32 contains also an internal temperature sensor and even an analog comparator, but they were removed from all documentation and specifications because they turned out to be unusable months after release. Not not-working-unusable, but working-but-so-bad-that-they-were-unusable. The hardware should still be there in everyone's chips even today, just disabled/unsupported/unreachable through the IDF libraries because their functionality was officially discontinued.

Now, the following is just a hunch, but I assume there is a connection between the removed parts and the under-performing ADC: a general (design- or manufacturing-related) problem with the analog parts of the IC, which is why these components had to be removed and why the ADC performs so poorly. Back when the ESP32 V3 came out, I was actually most excited because I was hoping they would finally fix the analog issues: improve the ADC and maybe even re-enable the other integrated peripherals. Unfortunately this was not the case.

The ESP32 is a very cool and versatile part with a low price, and probably my biggest gripe with it is its ADC. You simply cannot fix some of its defects using multisampling, and per-device calibration is not an option for mass production. I've learned to use external ADCs in ESP32-based projects where I need more than just simple "room temperature measurements". One of my current favorites is the TLA2024. Cheap, small, accurate and easy-to-use.

[DavidSG2020]

I have been doing analog and digital electronics since the dawn of the microprocessor era., and I can say quite definitively that this is not a bug.

It is totally and utterly incompetent design papered over by marketing specmanship.

The guys who designed these parts are brilliant digitologists, but don't know squat about analog chip design.

IMHO the only kind of ADC for which "multisampling" can be justified as a means of hitting a headline spec is in a sigma-delta converter, where you can achieve 23 bit resolution with sufficient filtering. Been there, done that.

Headlining a 12-bit ADC then burying the truth in a table deep in a data sheet is simply deceptive. And that truth says to me "8 bits".

I am now a happily retired hobbyist, doing my first ESP32 design. Fortunately I don't need the ADC function except for a trivial reading of an LDR. I love the pure grunt of the ESP32. Well, atleast I am forewarned if my next project needs some serious A to D.

[srini1948]

I agree with you totally – this is a poor design. I am also a hobbyist and love the other features of ESP32 Sent from Mail for Windows 10 From: DavidSG2020Sent: Wednesday, March 17, 2021 8:59 AMTo: espressif/esp-idfCc: srini1948; MentionSubject: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164) I have been doing analog and digital electronics since the dawn of the microprocessor era., and I can say quite definitively that this is not a bug.It is totally and utterly incompetent design papered over by marketing specmanship.The guys who designed these parts are brilliant digitologists, but don't know squat about analog chip design.IMHO the only kind of ADC for which "multisampling" can be justified as a means of hitting a headline spec is in a sigma-delta converter, where you can achieve 23 bit resolution with sufficient filtering. Been there, done that.Headlining a 12-bit ADC then burying the truth in a table deep in a data sheet is simply deceptive. And that truth says to me "8 bits".I am now a happily retired hobbyist, doing my first ESP32 design. Fortunately I don't need the ADC function except for a trivial reading of an LDR. I love the pure grunt of the ESP32. Well, atleast I am forewarned if my next project needs some serious A to D.—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. 

[CarlosGS]

I didn't realize that esp-idf now incorporates functionality that resolves the linearity issues (internally it uses a lookup table here). Espressif even provided a reasonable calibration solution by flashing chips since 2018 with an accurate Vref reading (link). The linearity correction works for all chips.

Not sure if there were any changes to the hardware regarding the low-end zero value of ~70mV. That could still be a problem depending on the application. But at least the calibrated API provides a layer of abstraction that enables the commercial use of the embedded ADC. Thanks!

[dmody]

Thanks for that update.

On Thu, Oct 21, 2021 at 9:05 AM Carlos Garcia Saura < @.***> wrote:

I didn't realize that esp-idf now incorporates functionality that resolves the linearity issues (internally it uses a lookup table here https://github.com/espressif/esp-idf/blob/c45c6f52f19e8ffed0ffa59bc7bea5e4adf0799d/components/esp_adc_cal/esp_adc_cal_esp32.c#L353-L354). Espressif even provided a reasonable calibration solution by flashing chips since 2018 with an accurate Vref reading (link https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html#adc-calibration). The linearity correction works for all chips.

Not sure if there were any changes to the hardware regarding the low-end zero value of ~70mV. That could still be a problem depending on the application. But at least the calibrated API provides a layer of abstraction that enables the commercial use of the embedded ADC. Thanks!

— 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-948596531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENULQAGCGGYEGIYRMT3D73UIAF3FANCNFSM4CZVWPTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[eos1d3]

For what I read from ESP32, ESP32-S2, ESP32-C3 and ESP32-S3 IDF programming guide, I find there is a table which is exactly the same for all these chips. There is no update for C3 and S3.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html#_CPPv425adc2_config_channel_atten14adc2_channel_t11adc_atten_t

+----------+-------------+-----------------+
|          | attenuation | suggested range |
|    SoC   |     (dB)    |      (mV)       |
+==========+=============+=================+
|          |       0     |    100 ~  950   |
|          +-------------+-----------------+
|          |       2.5   |    100 ~ 1250   |
|   ESP32  +-------------+-----------------+
|          |       6     |    150 ~ 1750   |
|          +-------------+-----------------+
|          |      11     |    150 ~ 2450   |
+----------+-------------+-----------------+
|          |       0     |      0 ~  750   |
|          +-------------+-----------------+
|          |       2.5   |      0 ~ 1050   |
| ESP32-S2 +-------------+-----------------+
|          |       6     |      0 ~ 1300   |
|          +-------------+-----------------+
|          |      11     |      0 ~ 2500   |
+----------+-------------+-----------------+

I think only original ESP32 has problem measuring voltage low below 100-150mV. It is obvious an original ESP32 default fault. I assume they fix this for later chips.

The ADC is nosier than other 8 bit or 32 bit MCUs. But calibration is not unique for ESP32. STM32 also calibration function before the use of ADC. But they do not use lookup table and raw value can be used directly. I think STM32 has hardware to offset the ADC error.

I would like to know how S2, C3 and S3 perform. But the use of lookup table indicates the linearity issues are still there.

[Tobbera]

@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);

}

Thank you for this one. This is the only off-the-shelf solution that I have found to improve the accuracy without doing manual measurements and building LUT´s etc.

[jan-bozelie]

Thanks for sharing your solution

Van: Tobias @.> Verzonden: woensdag 26 januari 2022 18:48 Aan: espressif/esp-idf @.> CC: jan-bozelie @.>; Mention @.> Onderwerp: Re: [espressif/esp-idf] [TW#12287] ESP32 ADC accuracy (#164)

@MaxSNi https://github.com/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);

}

Thank you for this one. This is the only off-the-shelf solution that I have found to improve the accuracy without doing manual measurements and building LUT´s etc.

— Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-1022440824 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIGW7YRQLUEDHDLNGPUND3UYAXWNANCNFSM4CZVWPTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AHIGW72NZ5ZBXLZHSKHFU7LUYAXWNA5CNFSM4CZVWPT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHTYTK6A.gif Message ID: @. @.> >

[melihkucukcalik]

ESP32-S3 ADC noise test

I made some tests with ESP32-S3 Devkit-C. First I insert Devkit to breadboard , and measure a fixed voltage around 1.85V which is divided by resistors from 3V3 and filtered by a capacitor. The results was so bad, there is %5 noise on ADC values.

Then I solder a capacitor (10nf) directly to ground and ADC port pin on Devkit. This reduce the noise so much. I understand that making tests on breadboard mislead tests.

Then I made one last test. instead of using Devkit on board USB-UART connector , I connect an external UART-USB converter and supply Devkit with battery. UART converter supply was separated. This also improves the signal quality. So keep in mind that your computer USB port also can have noise on 5V output.

Cap Filter on breadboard:

Cap Filter soldered to Devkit:

Cap removed while running:

[eos1d3]

@marcmerlin Did you have oversampling with the tests? And how many of sampling for each point?

From my case, I do not think USB supply from PC will make any difference. For example, I have tested STM8S and also STM32G0 ADC using the USB power supply from the same PC, the noise is just 1 or 2 from 10 bit (1023) reading without any capacitor. Using the same USB from the PC, ESP32, C3 and S3 are totally unacceptable.

I recently changed the PSU of my PC, and find the old PSU will have noise around 2 or 3 from 1023. The difference is so small.

And I also notice when WiFi is turned on, the noise is even much larger for ESP chips.

You finding is interesting, I think I will try S3 module only to test again. The ESP boards never gave me good results.

[melihkucukcalik]

First I want to say that Wifi is closed. This morning I rebuild my test setup with more better looking for photo. You can find that setup photo at down. I also made few more test. And again results are good. And there is no over sampling. Max value readed is 1759 min value is 1755. Difference is so small 5. With battery it seems that difference is down to 4 (rarely 5 I saw). This tests didn't show that if there is linearity errors on ESP32-S3. But it shows that it has acceptable noise level. If you take care while drawing PCB you can use it where ever you want.

The mainwhile code is just like following:

vTaskDelay(50 / portTICK_PERIOD_MS);

adc_val =  adc1_get_raw(ADC1_CHANNEL_3);

sprintf ( test_str, " %d \n \r",adc_val);
uart_write_bytes(UART_TEST_PORT_NUM, (const char*)test_str, strlen(test_str));

USB powered with Caps added to pins:

Test Setup:

[MitchBradley]

The most serious ESP32 ADC problem was not the random noise or the nonlinearity, but rather the fact that the value would make big jumps every few seconds. Random noise picked up in external circuitry can be reliably reduced with good layout and good analog design practices including power supply filtering. Random noise due to internal factors can be reduced by mathematical filtering such as IIR polynomial filters or FIR filters like averaging. Nonlinearity can be reduced with lookup tables or math functions that invert the nonlinearity. But big jumps that occur at long time intervals compared to the sample rate are very hard to handle. It is unclear what was causing the big jumps. Some issues have identified data transmission problems where bits are getting lost or added due to problems in interconnects like I2S or RMT or UART channels. In other cases, it seems that the ADC is affected by the WiFi radio - which is unpredictable due to its interaction with outside WiFi devices. Still another possibility is internal chip voltage and current shifts related to cache refills and other FLASH accesses - again difficult to impossible to predict. We can hope that S3 corrects some of these big-jump problems with better isolation between the ADC and the many other functional elements on the chip, but the limited experiments above, which mainly focus on short-term random noise behavior, do not tell us much about the long-term behavior that limited the ESP32's ADC general utility.

[chmorgan]

imo espressif will likely say something if/when they do resolve the issue. It seems like a hardware issue and it’s been years now with it outstanding and I was hoping s3 fixed it but unless there was really good data here I’d use an external adc until espressif confirmed the issue and that it was fixed.

On Fri, Apr 22, 2022 at 2:43 PM Mitch Bradley @.***> wrote:

The most serious ESP32 ADC problem was not the random noise or the nonlinearity, but rather the fact that the value would make big jumps every few seconds. Random noise picked up in external circuitry can be reliably reduced with good layout and good analog design practices including power supply filtering. Random noise due to internal factors can be reduced by mathematical filtering such as IIR polynomial filters or FIR filters like averaging. Nonlinearity can be reduced with lookup tables or math functions that invert the nonlinearity. But big jumps that occur at long time intervals compared to the sample rate are very hard to handle. It is unclear what was causing the big jumps. Some issues have identified data transmission problems where bits are getting lost or added due to problems in interconnects like I2S or RMT or UART channels. In other cases, it seems that the ADC is affected by the WiFi radio - which is unpredictable due to its interaction with outside WiFi devices. Still another possibility is internal chip voltage and current shifts related to cache refills and other FLASH accesses - again difficult to impossible to predict. We can hope that S3 corrects some of these big-jump problems with better isolation between the ADC and the many other functional elements on the chip, but the limited experiments above, which mainly focus on short-term random noise behavior, does not tell us much about the long-term behavior that limited the ESP32's ADC general utility.

— Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/164#issuecomment-1106768249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4AEDGW55SVPOSG7VBUTVGLXL5ANCNFSM4CZVWPTQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[srini1948]

It would have been ideal for my project but for the ADC. I am not sure why they dont fix it.

[MitchBradley]

If you knew how much it costs to do a major revision to a chip design, and how difficult it is to integrate analog and digital functions on a large chip with many different sections including a WiFi radio, they you would know why they don't just "fix" it.

[eos1d3]

The accuracy is one issue. But the way of handling continuous ADC DMA reading is another HUGE issue while Espressif seems did not know and understand what is required to make it useful.

Current IDF implementation of continuous ADC DMA reading involves ISR at end of each conversation. They use very large ring buffer to store EVERY instance of ADC values so that buffer is crazily large. And for each read operation by application, the buffer is full of duplicates of the same channels and with old values which are mostly useless for general applications. And this repeats again for each ADC channels. So it may use many KB for just ADC reading and this is crazy.

To solve the noise issue, Espressif suggest to use oversampling. But with this, the CPU will be mostly used for calculating the average values of ADC readings.

Currently the way of handling ADC in IDF is mostly suitable for audio recording or oscilloscope type applications as they save every reading from ADC. So there is no way to get real time ADC and the buffer is full of old and useless readings. From my test, if application does not handle it correctly, it may take more than 60 seconds to get recent values.

I did contact them via company account for this issue and they gave good response. It seems they understood and I was told than they will have 'real time' version of functions added in future IDF.

Compared with STM32, their ADC is just perfect. All ADC oversampling and conversion is done by ADC hardware with zero CPU time. And it is absolutely clean with no noise issue at all. And it uses just one 16 bit integer for each channel reading.

I will try again for S3, but the initial test with huge CPU and memory usage did not impress me. I believe oversampling via software is not the solution for ESP ADC noise.

PS: In ESP32, ESP32-S2, ESP32-C3 & S3, the ADC modules are very different. It seems they tried to improve ADC for each generation. And the original ESP32 is the worst for ADC.

PPS: @MitchBradley, which ESP32 revision for "big jumps every few seconds"? I tried latest ESP32 V3 and do not have this issue.

[rsaxvc]

ADC can also be run through the ULP to support multiple separate ring buffers as needed. However, it's quite complicated compared to other microcontrollers.

[Guangyang13]

Random noise due to internal factors can be reduced by mathematical filtering such as IIR polynomial filters or FIR filters like averaging.

Hi, can I know how to design and implement the IIR filter to reduce the noise? Is it got any example or source that I can go through? Thank you very much

[MitchBradley]

The simplest IIR filter looks like this in C. There are many more complex ones.

#define factor  0.1
float last = 0.0;
float next(float sample) {  // sample is the value from the ADC converted to a float
   last =  last * (1.0 - factor) + sample * factor;
   return last;
}

You can make the filtering "better" by reducing the value of factor, at the expense of it taking longer for new data to affect the output value. Conversely, larger factor values respond faster with worse filtering. Filtering is a big topic and there is a lot of literature on the internet about it. The floating point calculations can be done with integer arithmetic if you know how - but simply replacing "float" with "int" will not work.

That is all I am willing to say. Good luck.

[italex33]

This is a VERY long thread to discuss the Analog inability of the ESP32. All kinds of USELESS things are listed here. Why bother too much with the ESP32 when you can use, for example, the MKR1010? It is way much better and VERY accurate. The ESP32 in my opinion is a work in progress. The ESP32 ADCs are basically useless!

[eos1d3]

It is because many use ESP32 chips or modules for productions, not just prototyping. The ESP32xx modules are just around $2.

It is true that ADC of all Espressif products are completely useless. But the way they handle ADC API is another big problem.

I even asked them in Espressif Developer Conference 2022 and none of them have courage to answer.

[DavidSG2020]

This is a VERY long thread to discuss the Analog inability of the ESP32. All kinds of USELESS things are listed here. Why bother too much with the ESP32 when you can use, for example, the MKR1010? It is way much better and VERY accurate. The ESP32 in my opinion is a work in progress. The ESP32 ADCs are basically useless!

Sure. 8x the price. A fraction of the memory. A fifth of the clock rate. A no-brainer, really. If I need a decent ADC I'll just add an external chip

My hobby would be unaffordable at the price.

Obviously the ADC in the ESP is rubbish. I am grateful to threads like this for letting me know before I have a faild design because of it. Matter of fact, my current project will use the ESP32 ADC, but I only need a very rough reading to autotune a detector circuit. If something comes up where I need north of 8 bits I'll now know I'll have to use an external chip. Or, if speed is not an issue, a PWM output and a 10 cent comparator.

[italex33]

My hobby would be unaffordable at the price.

Obviously the ADC in the ESP is rubbish. I am grateful to threads like this for letting me know before I have afield design because of it. Matter of fact, my current project will use the ESP32 ADC, but I only need a very rough reading to autotune a detector circuit. If something comes up where I need north of 8 bits I'll now know I'll have to use an external chip. Or, if speed is not an issue, a PWM output and a 10 cent comparator.

If money is an issue, and no ADCs are needed, the ESP32 is a good choice, I have a couple projects where the ADCs are not needed, my garage opener uses digital pins only, also my thermostat, but my Personal Weather Station where I have 4 analog devices is a different story, in this case, the ESP32 is useless. I added the ADS1115 but this makes the PWS more complex, more expensive, and more coding.

[michapr]

I added the ADS1115 but this makes the PWS more complex, more expensive, and more coding

I have used the ADS1115 in many projects with ESP32 last years and cannot confirm that solution is really more complex (of course depending on the project...) - and it is not more expensive than other solutions.

Anyway - everyone has their favorite processor and their favorite solutions - and that's a good thing given the variety of solution approaches ... :)

[krupis]

I came here because I have ESP32 ADC issues myself. From my experience, I can never achieve accuracy greater than 30mV on the ESP32 boards no matter what I do. For some applications its good enough but for others totally unacceptable.

I am very surprised that they did not improve this on their recent flagship ESP32-S3. The ADC is just as bad on this board as on the old ESP32.

I still have my hopes that they manage to improve the ADC on the device that they announced not so long ago: https://www.espressif.com/en/news/ESP32-P4

I am not a hardware or analog specialist but it makes me wonder what really is the reason behind their horrible ADC's? Why cant they just embed some analog IC on their SoC and solve all ADC problems?

[italex33]

I came here because I have ESP32 ADC issues myself. From my experience, I can never achieve accuracy greater than 30mV on the ESP32 boards no matter what I do. For some applications its good enough but for others totally unacceptable.

The ESP32 analog inputs are UNUSABLE to say the least, I have no idea how you can use these inputs with such inaccuracy. I am using one with 4 analog inputs, but I am using the ADS1115.