I purchased a VROOM-32 from EzSBC on Ebay. So far, I have a web server with web socket implemented via FreeRTOS and am working on some data acquisition code. I'm using mainly ESP-IDF for development am debugging with printf statements to the terminal. Eventually, I will get the whole package into Eclipse.
The main issue I've seen so far is an extremely noisy ADC. I'm aware of the linearity problems, but this is far beyond that. I've tested a couple of the inputs using a 1.6 volt battery and scoped the input to ensure that no spikes are present there (it is, after all, a battery). I've used all of the attenuation and bit-width parameters and there are spikes as much as +/- 40-50% that appear random. In addition to the spikes, there is a constant +/- 20 counts of ongoing noise. I've posted this on the ESP-32 forum. An older post on that forum mentioned the input source impedance as a possible problem. Hopefully, there is a sample/hold circuit as part of the ADC, which would completely eliminate source impedance as a cause. If there is no s/h, then signal slew will cause significant errors.
I've also noticed that occasionally the WIFI radio will quit working. Is anyone aware of pending fixes for these issues?
I think this ESP-32 will be a great product once the problems are fixed. There is also a pressing need for updated documentation.
Frank
ESP-32 Noisy ADC
Re: ESP-32 Noisy ADC
From your post I can't decide if you bought the module or the PCB with the module installed. I do all my testing on the PCB with the module installed so if you bought the module only it may not apply directly.
When I do an AD-conversion with a simple Arduino program I get good readings and an static offset of around 5 counts for a zero input. I did the tests with a variable resistor connected between the 3.3V pin and ground pin on the connector with the wiper going to the ADC input. I used a 2k potentiometer and the readings are stable to withing 3 counts on the 12-bit setting. Having said this, there are many ways to break the resolution and accuracy of the ADC. The first and easiest to overlook is ground noise from the host PC getting into the system via the USB connector. Using a galvanically isolated USB connection gets around this. http://www.usbgear.com/USBG-M4160.html is the least expensive version that I can find that works well.
Another excellent way to break the analog signals is to have the radio banging away while doing measurements. The radio signals will couple into the wires and the radio draws large current spikes that disturbs the 3.3V which directly affects the ADC since it is the reference voltage for the ADC. If the measurements are broadband and ratio-metric its not catastrophic but if the output being measured is filtered then the phase shifts between the reference and the measured signal will show up directly as errors. Your battery measurement will directly suffer from this issue.
It is hard to tell if there's a real S/H in front of the ADC because the documentation is not clear. But even a S/H can contribute to breaking the signal from a high impedance source due to the peak current drawn by the hold capacitor during the (short) sample window. Without the S/H the charge redistribution as the ADC performs the conversion will disturb a high impedance input source. The only solution to a high impedance source connected to an ADC is to have a buffer amplifier between the source and the ADC and/or S/H. There are many 3.3V op-amps with rail to rail inputs and outputs on the market suitable for driving the input of the ADC.
There is a mode where the radio can be silenced for a short while while a conversion takes place. It is described under the sleep modes in the documentation.
I've seen some reports of radio issues when the USB cable is long or of poor quality. It is best to use a USB cable designed for a battery charger because they don't skimp on the wire diameters. It helps if you place a capacitor between the Vin pin and Gnd on the PCB connectors. A 100uF tantalum seems to be the popular choice.
I hope this helps.
Daniel
When I do an AD-conversion with a simple Arduino program I get good readings and an static offset of around 5 counts for a zero input. I did the tests with a variable resistor connected between the 3.3V pin and ground pin on the connector with the wiper going to the ADC input. I used a 2k potentiometer and the readings are stable to withing 3 counts on the 12-bit setting. Having said this, there are many ways to break the resolution and accuracy of the ADC. The first and easiest to overlook is ground noise from the host PC getting into the system via the USB connector. Using a galvanically isolated USB connection gets around this. http://www.usbgear.com/USBG-M4160.html is the least expensive version that I can find that works well.
Another excellent way to break the analog signals is to have the radio banging away while doing measurements. The radio signals will couple into the wires and the radio draws large current spikes that disturbs the 3.3V which directly affects the ADC since it is the reference voltage for the ADC. If the measurements are broadband and ratio-metric its not catastrophic but if the output being measured is filtered then the phase shifts between the reference and the measured signal will show up directly as errors. Your battery measurement will directly suffer from this issue.
It is hard to tell if there's a real S/H in front of the ADC because the documentation is not clear. But even a S/H can contribute to breaking the signal from a high impedance source due to the peak current drawn by the hold capacitor during the (short) sample window. Without the S/H the charge redistribution as the ADC performs the conversion will disturb a high impedance input source. The only solution to a high impedance source connected to an ADC is to have a buffer amplifier between the source and the ADC and/or S/H. There are many 3.3V op-amps with rail to rail inputs and outputs on the market suitable for driving the input of the ADC.
There is a mode where the radio can be silenced for a short while while a conversion takes place. It is described under the sleep modes in the documentation.
I've seen some reports of radio issues when the USB cable is long or of poor quality. It is best to use a USB cable designed for a battery charger because they don't skimp on the wire diameters. It helps if you place a capacitor between the Vin pin and Gnd on the PCB connectors. A 100uF tantalum seems to be the popular choice.
I hope this helps.
Daniel
Re: ESP-32 Noisy ADC
I'm using the module mounted on the PCB. I don't use Arduino. All of my programs are in either 'c' or 'c++'.
I've run the board on an external power supply and sent data to the browser via web socket to eliminate the USB as a problem, but the spikes are still there. I've also run with the radio disabled and viewed the data via the com port with the same results. In each test, sample interval is 3 seconds and only one channel is sampled
I'll try the tantalum cap on Vin. Can you tell me where in the documentation it describes how to disable the modem for short periods?
Thanks.
Frank
I've run the board on an external power supply and sent data to the browser via web socket to eliminate the USB as a problem, but the spikes are still there. I've also run with the radio disabled and viewed the data via the com port with the same results. In each test, sample interval is 3 seconds and only one channel is sampled
I'll try the tantalum cap on Vin. Can you tell me where in the documentation it describes how to disable the modem for short periods?
Thanks.
Frank
Re: ESP-32 Noisy ADC
After visiting the esp32.com forum to find how to put the modem into sleep mode--and digging through some *.h files:
After making the appropriate call, a subsequent status check indicated that the modem was indeed in sleep mode. However, this is not the case. I am still able to make http requests and send data via the web socket. For now, that is a minor glitch.
I thought I had some 100uf tantalums on hand (for filtering Vin), but apparently I don't. A quick test with a 10uf value made no difference. I will get some 100uf pieces and try that.
Frank
Code: Select all
.....
// typedef enum {
// WIFI_PS_NONE, /**< No power save */
// WIFI_PS_MODEM, /**< Modem power save */
//} wifi_ps_type_t;
esp_err_t wifistat;
wifi_ps_type_t modemstate;
// set modem power to 'sleep'
wifistat = esp_wifi_set_ps(WIFI_PS_MODEM);
// read modem power status
esp_wifi_get_ps(&modemstate);
printf("modem status = %d\n", modemstate);
.....
I thought I had some 100uf tantalums on hand (for filtering Vin), but apparently I don't. A quick test with a 10uf value made no difference. I will get some 100uf pieces and try that.
Frank
Re: ESP-32 Noisy ADC
The modem not being in sleep mode is probably a documentation issue, maybe a chip bug. I recommend that you post a question on ESP32.com on how to put the modem to sleep.
I'll try to reproduce the issue at my work place and see if I can come up with a solution.
I'll try to reproduce the issue at my work place and see if I can come up with a solution.
Re: ESP-32 Noisy ADC
Thanks Daniel. As I stated, the modem problem isn't a show stopper for now. Someone in the esp32.com forum posted the method to disable the modem. I used that approach, but it doesn't work.
As for the adc noise, I did the following:
1. resolder mounting tabs and leads on USB connector.
2. use shorter leads on breadboard.
3. use 8.4v battery pack for Vin.
4. 100uf tantalum on Vin.
5. 100uf tantalum on 3.3v.
6. use 5-sample sw deglitch.
In all tests, the ai source was either a 1.5v (nominal) battery or a 2K pot.
(2) helped with the radio going offline problem.
(3) reduced the spikes on Vin and 3.3v by probably 20% or so. Also, radio stays online much longer.
(4) helped a little, but spikes still exist on 3.3v. same with (5).
(6) helped with acquiring adc values more than anything, holding the scatter on readings to about 20 counts. The unfiltered scatter is over 130 counts, which is unusable and appears related to the adc process, as disabling all adc activity greatly reduces these spikes. I have removed the 100uf cap on 3.3v, uncertain of its effect on the regulator(s) output behavior. There doesn't appear to be much noise contributed by the radio.
I'm not sure if the problems I am seeing are common, but there are certainly problems with this particular WROOM-32; mostly with the voltage spikes on the 3.3v pin. It appears that the adc strategy/circuitry needs some serious attention.
Frank
As for the adc noise, I did the following:
1. resolder mounting tabs and leads on USB connector.
2. use shorter leads on breadboard.
3. use 8.4v battery pack for Vin.
4. 100uf tantalum on Vin.
5. 100uf tantalum on 3.3v.
6. use 5-sample sw deglitch.
In all tests, the ai source was either a 1.5v (nominal) battery or a 2K pot.
(2) helped with the radio going offline problem.
(3) reduced the spikes on Vin and 3.3v by probably 20% or so. Also, radio stays online much longer.
(4) helped a little, but spikes still exist on 3.3v. same with (5).
(6) helped with acquiring adc values more than anything, holding the scatter on readings to about 20 counts. The unfiltered scatter is over 130 counts, which is unusable and appears related to the adc process, as disabling all adc activity greatly reduces these spikes. I have removed the 100uf cap on 3.3v, uncertain of its effect on the regulator(s) output behavior. There doesn't appear to be much noise contributed by the radio.
I'm not sure if the problems I am seeing are common, but there are certainly problems with this particular WROOM-32; mostly with the voltage spikes on the 3.3v pin. It appears that the adc strategy/circuitry needs some serious attention.
Frank
Re: ESP-32 Noisy ADC
At Daniel's suggestion, I replaced the two 0603 .1uf caps, C1 and C2 with 0805 47 uf ceramic caps. These caps are at regulator
input and output, respectively. All tests were conducted with power supplied by an 8 volt Li-ion battery pack to Vin. Most tests
were brief, since the 8 volt supply pushed the regulator past its max dissipation limit.
The results are mixed. However, in my limited testing, there was slightly less scatter (noise) in the raw adc input data and much
less tendency for the adc counts to go to max (1023 counts) after the change:
Nominal adc input counts: 763
count range (raw input)
old caps: 744 - 785
new caps: 753 - 783
With the old caps, steady noise was about -50 to +40 mv with spikes approaching -1 volt to +800mv when transmitting. Unless
noted, the following was observed after installing new caps:
Most of the severe spikes on the 3.3v occur when the radio is transmitting. In the setup, data is transmitted via websocket every
200ms. When there is no data transmitted, the steady noise (with new caps) is +/- 15mv with spikes around 80-100mv. When
transmitting, steady noise is +/- 100mv with spikes around -500mv to +300mv. In some tests, the noise spikes were -800mv to
+600mv. It is difficult to capture on my scope, but occasionally, the 3.3v will drop 800mv or so for (guessing here) about 200ms
or longer. These rather prolonged drops in 3.3v also seem to occur even when not transmitting. These are most likely the times
when the adc values are severely in error. If these droops are reflected in the ADC reference, then it is conceivable that the adc
converted value will go to max counts. I recorded this value many times with the old caps, but not since installing the new caps.
This droop will sometimes cause the chip to stop operation or impair radio operation.
Overall, the cap change is a worthwhile mod, decreasing the severity and time duration of voltage spikes and fluctuations, but I
feel there is still an urgent need for change in the WROOM32 module and/or the ESP32 chip itself.
Frank
input and output, respectively. All tests were conducted with power supplied by an 8 volt Li-ion battery pack to Vin. Most tests
were brief, since the 8 volt supply pushed the regulator past its max dissipation limit.
The results are mixed. However, in my limited testing, there was slightly less scatter (noise) in the raw adc input data and much
less tendency for the adc counts to go to max (1023 counts) after the change:
Nominal adc input counts: 763
count range (raw input)
old caps: 744 - 785
new caps: 753 - 783
With the old caps, steady noise was about -50 to +40 mv with spikes approaching -1 volt to +800mv when transmitting. Unless
noted, the following was observed after installing new caps:
Most of the severe spikes on the 3.3v occur when the radio is transmitting. In the setup, data is transmitted via websocket every
200ms. When there is no data transmitted, the steady noise (with new caps) is +/- 15mv with spikes around 80-100mv. When
transmitting, steady noise is +/- 100mv with spikes around -500mv to +300mv. In some tests, the noise spikes were -800mv to
+600mv. It is difficult to capture on my scope, but occasionally, the 3.3v will drop 800mv or so for (guessing here) about 200ms
or longer. These rather prolonged drops in 3.3v also seem to occur even when not transmitting. These are most likely the times
when the adc values are severely in error. If these droops are reflected in the ADC reference, then it is conceivable that the adc
converted value will go to max counts. I recorded this value many times with the old caps, but not since installing the new caps.
This droop will sometimes cause the chip to stop operation or impair radio operation.
Overall, the cap change is a worthwhile mod, decreasing the severity and time duration of voltage spikes and fluctuations, but I
feel there is still an urgent need for change in the WROOM32 module and/or the ESP32 chip itself.
Frank