ESP32 ADC voltage drop after some hours

[kevinkk525]

Ok so I'm done with the ESP32 adc.. It is getting ridiculous. Take a look at this:

Unbenannt2.PNG (112.86 KiB) Viewed 4578 times

The ADC stays completely stable in section 1 which goes on for days, the ESP reset itself about every day due to some weird CPU exception or something but regardless the ADC stays the same. It is connected through rshell and I can see the output on my PC that I often put in standby.
Then I rebooted my PC and section 2 happened. I didn't reconnect to the board with rshell anymore and just let it do its thing. It still resets itself because of said problems about once a day but the ADC still stays stable, just measuring a higher voltage (graph drops because its PPM and not voltage).
So after a while I decided to reconnect rshell and check it out and section 3 happened.. We're back at the voltage levels of section 1 and it stays there stable again.
Next day I rebooted my PC again because of windows updates and didn't reconnect rshell. Voltage rose again and PPM in the graph dropped..

So my conclusion is that there's either some circuits or temperature changes that screws with the ADC accuary introducing some weird offset. But it makes it impossible to use the ADC on my board correctly unless I stop using rshell and hope that by using only webrepl to check things out, the ADC is then stable in all environments. But how can I trust the ADC to be stable when I put the board outside and not have some other weird flaws after all that?

tl;dr: Never use Esp32 ADCs for more than just having some fun..
I might need to use an Arduino for my use-case or buy a pyboard D but they are so expensive..

[Roberthh]

While I fully agree to your rant about the ESP32 ADC, you did not explain why you are sure, that not the signal you are taking, had these variations and why it could not have been affected by the activities you made.

Besides that I use to recommend using an external ADC for the ESP32.

[kevinkk525]

you are right, the signals I read are basically just a simple voltage divider with a cable in the water to measure the electroconductivity of the solution (according to this: https://hackaday.io/project/7008-fly-wa ... er-arduino).
That setup should see no change in behaviour from me connecting through rshell. The water solution is still the same and the temperature doesn't change. The ESP power supply is still the same and even stays stable when the PC is in standby so i don't think that plays a role.
The connection through rshell was the only external reason I could find and was the only thing that changed within more than 7 days during which the readings were consistent.

[Roberthh]

Did you do like in the linked site: switch on the power to the resistor divider for a short time and then switch if off? Meaning your supply into the chain is the output voltage of an ESP32 GPIO pin.

[kevinkk525]

yes.
but maybe there is something else going on too.. I just connected a real resistor instead of the cable and it got me ~100R, which is correct. So after a while I connected rshell and it still shows me 100R for that resistor. So either something with that cable is immensly strange and somehow connected to being conntected through rshell, or the ADC has different behaviour depending on the voltage. Wouldn't be the first time, another kind of esp32 board I tested first was behaving very erractically in a higher (i think, maybe it was lower) voltage range and I couldn't even find a correct formula to correct the readings.
I'm a bit confused. Maybe I need more extensive testing with real resistors of different sizes. The ADC is calibrated to read correctly while connected by rshell using resistors: 100, 200, 300, 500, 1000
Maybe I'll find out if it acts up again without rshell connected.

[dhylands]

When rshell is connected, the serial port is open. On some ESP32 boards (and most arduino boards), the act of opening the serial port will reset the board.

Open circuits will capacitively couple to traces nearby on the board (which can cause all kinds of weirdness).

Many ADCs require the use of low impedance signals and will trying to read high impedance signals will give sporadic results.

[pythoncoder]

A few random thoughts

There are several possible sources of error. As Dave says, the ADC may need a low impedance source. Also the voltage source for the resistive divider is a digital I/O pin. These aren't guaranteed to provide a precision voltage source.

The system seems to exist in two possible states. In each of those states I'd measure the voltage out from the digital I/O pin, the voltage on the ADC pin, and the actual ADC reading. If you haven't got a scope you might need to replace the liquid with a resistor so you can do static DC measurements.

This piece of code hints at something:

Code: Select all

digitalWrite(ECPower,HIGH);
raw= analogRead(ECPin);
raw= analogRead(ECPin);// This is not a mistake, First reading will be low
digitalWrite(ECPower,LOW);

The reason his first reading is low is probably because it takes time for the ADC to acquire data. I would check the specification for the ESP32 ADC and make sure that the voltage is applied for long enough for it to take a reading.

[kevinkk525]

Thank you both for your thoughts!

I might have to think about the low impedance a bit more. However it seems strange that it would only have an impact in certain situations but always stay stable within these "situations".
That's why I also think that the I/O pin as power source shouldn't be the culprit because it stays stable within that situation. However, it might not be impossible that there is an offset in the provided pin voltage in certain situations. I might have to change my measurement to a static DC one but that would only proof half of the use-case.

The explanation about open circuits makes sense to me and could be the reason I experienced that behaviour.


The arduino code is for an Arduino Uno and they can read very fast, therefore the 2 calls to the ADC. it is not required in micropython on the esp32 because it is orders of magnitude slower. I tried measuring with different length between switching the gpio to power and reading the voltage and the esp was so slow that I even tried to make it as fast as possible using registers and native code. Currently switching the gpio to power and reading the adc takes 180-260us. But it stays stable at that point and exceedingly long readings are discarded because those generate wrong readings in liquid (but of course not with DC voltage on real resistors). I have double checked the readings with real resistors and DC current. So if there are no unknown variables I didn't consider, the ADC readings should be consistent.

But for argument's sake and for my understanding lets assume the readings are too fast for the ADC. Shouldn't I then see more obvious fluctuations in voltage? And if the reading time always stays the same, how can such big drops happen but the reading otherwise still stay stable?

[pythoncoder]

It sounds like you've fully explored the timing issue.

It would be interesting if you could replicate this with real resistors and a static DC measurement. Easier to debug.

[rpr]

I'm curious about this behavior.

I have hooked up a precision voltage reference AD584 chip set to output 2.5 V. This is connected to one of the adc inputs of the ESP32 (set to 12 bit width and atten_11db). Taking adc data every 1 second which is published via MQTT (using the mqtt_as) to a broker. A second computer on the same network subscribes and writes this value to a file every second. No data averaging is done. I'll try to keep the recording going for a while (at least over the weekend) and try to post the results.