5 ms·
Lies, Damn Lies and Analog Inputs (Comparing ADCs on ESP32, Pico and Arduino)
- londons_explore 3y agoLots of things in the ESP32 series suggest they no longer have any decent analogue/RF engineers on staff. Or maybe they aren't licensing the (expensive) analogue silicon design tooling. For example, they have no 5Ghz model. The ADC performs really poorly. The RF capabilities don't seem to have changed for a decade. Etc.
- willemmerson 3y agoDoesn't seem like a very fair comparison, you're using a cheap, unofficial knock-off ESP32 board which only allows up to 1v, compared to official Rpi and Arduino boards which go up to 3.3v. Perhaps you should use an official ESP32 devkit (https://www.espressif.com/en/products/devkits https://www.espressif.com/en/products/devkits) and try running it again. I don't really understand why people bother buying other boards when the official ones are so cheap. Having said all that, I have heard the analogue inputs aren't that great on the ESP32.
- mordae 3y agoI did as well. From an espressif employee. It's hard for them to iterate. Every batch must sell so any improvements come really slowly.
- declaredapple 3y ago> Having said all that, I have heard the analogue inputs aren't that great on the ESP32. Yeah they have wide deadzones and just aren't great, they're really only useful for really coarse things, like reading a photoresistor to turn a light on/off
- JoeAltmaier 3y agoSingle-ended or differential? What kind of bypass? What kind of ground? Did the voltage being measured share ground with the ADC? Were hold times respected? So much you can do to improve ADC precision. Not sure what to conclude from this experiment.
- boznz 3y agoAnd no mention of the Vref for the analogue which is essential for accurate operation
- tuatoru 3y agoYeah, Simon Monk omits a great deal from his writing. But usual practice is to use the 10% to 90% range of the ADC anyway. Too many people are unwilling to learn about basic op amp circuits to buffer and condition the input signal.
- mordae 3y ago> learning that the analog readings for a Pico and ESP32 come at a massive 16 bit precision (a number between 0 and 65536) Sigh. No they don't. RP2040 ADC has output resolution of 12 bits with ENOB of about 8.7. MicroPython probably scales those up. Also, 65535. This is surprisingly low quality blog post for HN standards.
- deleted 3y ago[deleted]
- pclmulqdq 3y agoMost people on HN don't understand embedded systems. This blog poster is probably also a hobbyist given the choice of devices to measure.
- 05 3y agoBut the alternative is someone who's an embedded expert comparing MCUs you can't buy in quantities less than 10K or get hands on a data sheet without your company ordering a million and signing an NDA :)
- rasz 3y agoNah. Elecia is a world class embedded specialist and I dont get that component elitisms from here https://embedded.fm/episodes https://embedded.fm/episodes
- neltnerb 3y agoIt's not hidden very well [referring to "lies" in the title] when the ESP32's website about the ADC has a graph showing noise of ~10 LSBs normally, which with a proper input capacitor goes down to about 5 LSBs and down to 1 LSB with multisampling. Which is done transparently in hardware. https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-reference/peripherals/adc.html https://docs.espressif.com/projects/esp-idf/en/release-v4.4/... It even has almost the same graph showing the linearity and dead zone, none of this is a surprise. It's just not got the best ADC ever and I've chosen different parts because of it before. Other parts have better ADCs... and that Mega has a far lower sampling rate.
- zwieback 3y agoBe interesting to find out how the respective ADCs are programmed at the register level. Anecdotally we've also found that the ESP32 A/D aren't usable for precision measurements. It would also be useful to have a function generator hooked up and simultaneously digitizing the signal, that's usually how I do my comparisons but does require some more expensive tooling.
- the__alchemist 3y agoI had a not-so-fun troubleshooting session this week trying to figure out my ADC wasn't working on an STM32H7 board, but works fine on G4. It turns out there's a `boost` bit in on the registers that has to be set on H7, if the ADC clock speed is >20Mhz... which is is at most common settings. Other than that, the ADC config is the same as other STM32s. That was frustrating! RTFM and don't make assumptions. Another trap is that on H7, the ADC's default clock isn't enabled; requires turning on the second PLL, or re-configuring the first one.
- zwirbl 3y agoAh yeah, the STM clock forest is always fun to get lost in
- HeyLaughingBoy 3y agoDoesn't CubeMX take care of that or are you not using it?
- thenewwazoo 3y agoCubeMX reminds me of tax software, and the subjective experience of using it is the same. It encodes a huge number of complex rules that don't need to exist, and the output is completely inscrutable until you've really immersed yourself in it. The whole time, I'm thinking "there's gotta be a better way to (organize society|bootstrap a chip)".
- the__alchemist 3y ago
- declaredapple 3y ago> [ESP32 LOLIN32 Lite] Analog input maximum voltage 1.0V Where did this number come from? AFAIK all pins should operate at 3.3v, and I see no mention of a 1v maximum for that board, or the esp-chip either.
- pantalaimon 3y agoUsually you have a reference voltage for the ADC, that is the maximum you can measure. A 1V band gap voltage reference is common. You could also use 3.3V Vcc instead, but there is no guarantee that that’s actually 3.3V as it's provided by an external circuit. The band gap voltage is always 1V, so I see why it would be the default.
- gh02t 3y agoThe ESP32 usually uses a 1.1V reference, however (unlike the ESP8266), it has a variable attenuation setting that allows you to measure voltages higher than Vref. https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32/api-reference/peripherals/adc.html https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32/ap... The Micropython code the post has at the bottom initializes the ADC to the default, which I think 0 DB attenuation setting, which gives you a range of roughly 0.1-0.95 V. It'll be fine physically if you hook it up to 3.3 V, but the readings will saturate unless you use the higher attenuation setting. There's not much advantage to enabling the attenuator for this test regardless, it just adds more noise.
- westurner 3y agoIf these were better, those might be quantum computers. Except, you'd need a phononic representation of the signal pre/post ADC and/or better voltage quantization. Is this level of component variance the reason we can't do quantum computers with electron charge? Qubit > Physical implementations does list Electron spin and also Electron charge, which ADCs quantize: https://en.wikipedia.org/wiki/Qubit#Physical_implementations https://en.wikipedia.org/wiki/Qubit#Physical_implementations Compared to a $3 ESP32 and a $6 Pico without a RTC Real Time Clock, HiFiBerry DAC ADC Pro has a "Dedicated 192kHz/24bit high-quality Burr-Brown ADC" https://www.hifiberry.com/docs/data-sheets/datasheet-dac-adc-pro/ https://www.hifiberry.com/docs/data-sheets/datasheet-dac-adc... ADC: Analog-to-digital converter: https://en.wikipedia.org/wiki/Analog-to-digital_converter https://en.wikipedia.org/wiki/Analog-to-digital_converter : > In electronics, an analog-to-digital converter (ADC, A/D, or A-to-D) is a system that converts an analog signal, such as a sound picked up by a microphone or light entering a digital camera, into a digital signal. An ADC may also provide an isolated measurement such as an electronic device that converts an analog input voltage or current to a digital number representing the magnitude of the voltage or current. Typically the digital output is a two's complement binary number that is proportional to the input, but there are other possibilities. Integral linearity: https://en.wikipedia.org/wiki/Integral_linearity https://en.wikipedia.org/wiki/Integral_linearity
- rkagerer 3y agoI did some hardcore experimentation with the ESP32-S3 ADC's a while back. Rather than using the official libraries (which themselves contained a few bugs and hacks) I made a lot of headway by starting from scratch and setting up the raw peripheral registers myself. Actually prefer it that way, without all the abstraction underneath. Wrangled out some decent results at an impressive 80kHz sample rate in continuous mode, using DMA for near-zero CPU involvement. Here's a plot captured at the time (along with an analog probe for comparison): https://imgur.com/a/5zfy9LZ https://imgur.com/a/5zfy9LZ I'm not sure if [m]any other people have done this, and one day I'd love to get around to posting sample code along with a little writeup. It was a real uphill battle to get there. Discovered and reported dozen[s] of errata in documentation to EspressIf (most of which was acknowledged and queued for correction in their next Technical Reference Manual update, although I admit after a couple months I stopped checking to see if surfaced). Lots of undocumented bits had to be deciphered (including basic ones in SYSTEM_PERIP_RST_EN0_REG and SYSTEM_PERIP_CLK_EN0_REG to reset the ADC peripheral and enable it's clock, and power control bits in SENS_SAR_POWER_XPD_SAR_REG). ADC2 is write-off for anything high-speed, as the entire digi controller was 'dropped' from support due to bad silicon (there's some interesting history and trends if you read up on ADC errata across earlier ESP32 models - it's clear EspressIf really struggled with analog, but they're inching forward with progress as the lineup evolves). Unfortunately when they yanked the documentation for it, they went a little overboard and removed some whole sections that relate to the still-working ADC1 (e.g. all mention of APB_SARADC1_DATA_STATUS_REG, which stores the most recently sampled ADC1 result, was lost in collateral damage). Other minor documentation pains included mistakes in DMA descriptors, subtly incorrect command sequencing in the ADC Pattern Table (that one cost a couple evenings of debugging to track down), incorrect and sometimes senseless information referring to the use of a flag in GDMA_OUT_AUTO_WRBACK_CHn for a receive channel, ADC_ATTEN_DB_11 constant being used all over the place even though it's actually 12dB (granted that's a nitpick), unintuitive and undocumented behavior that seems in some circumstances to cause GDMA to not move onto the next descriptor until DMA_IN_SUC_EOF is generated, certain actions like pausing and resuming DMA (e.g. for diagnostic instrumentation code to retrieve a consistent snapshot of all the involved registers) seems to corrupt the descriptor pointer (that one might turn out to be by design), and other little mistakes like copy/paste errors or other ambiguities. That all said, it's still not the worst documentation I've seen. Hardware ADC calibration can significantly improve results, but it's unfortunately buried under undocumented ROM functions required to initialize and enable the feature (via an undocumented I2C configuration bus); without this my readings were off by ~50%. (There's something called an "Internal Calibration Bus" which sadly isn't mentioned once in the docs). All in all a fun project, though in retrospect it would have taken a lot less time to get up and running with a dedicated ADC chip in my BOM.
- JohnFen 3y agoThose built-in ADCs are notoriously suboptimal in many ways -- but for nonprecision applications, they're just fine. When I'm making something that requires precision, though, I never use them and go with a dedicated ADC instead.