I’m good to english ,sorry.

- Screenshot from 2016-04-23 14-08-47.png (21.98 KiB) Viewed 2424 times
1. on the voltage at your voltage regulator (it serves as the adc reference voltage)
2. on the formula you use for the conversion of adc output to float
3. on the error of the adc converter (see datasheet)
4. on the adc clock frequency
5. on the impedance of the voltage source
6. on the temperature
7. on the level of noise.
How do you convert the 12bit adc output to the float? Show us the formula.
In case your conversion formula is using the actual Vdd (you measured exactly) as the Vref, and the calculation itself is ok, I would expect max +/- 8mV difference against fluke.
I doubt your Fluke meter is inaccurate, but measurement to 10mV is probably not guaranteed unless its brand new.
The issue is that you have to calibrate the ADC values against a known reference.
To make matters worse, you would need to run your MCU from a calibrated supply, as the ADC value is a proportion of the analogue reference voltage, and on most cheap STM32’s this is just connected to the 3.3V supply, which comes from some cheap linear regulator.
Probably the best you can achieve is to determine how accurate and stable your analog reference voltage is, (for a variety of input voltages), then calibrate your display voltage from your Fluke DVM (assuming your DVM is correct), by doing some simple maths.
You should also check the linearity of the STM32F1 ADC, and if necessary build yourself a lookup table to correct for non-linearity. There is plenty of flash space even on the STM32F103C8 to have a calibration table all adc values.
I doubt your Fluke meter is inaccurate, but measurement to 10mV is probably not guaranteed unless its brand new.
The issue is that you have to calibrate the ADC values against a known reference.
To make matters worse, you would need to run your MCU from a calibrated supply, as the ADC value is a proportion of the analogue reference voltage, and on most cheap STM32’s this is just connected to the 3.3V supply, which comes from some cheap linear regulator.
Probably the best you can achieve is to determine how accurate and stable your analog reference voltage is, (for a variety of input voltages), then calibrate your display voltage from your Fluke DVM (assuming your DVM is correct), by doing some simple maths.
You should also check the linearity of the STM32F1 ADC, and if necessary build yourself a lookup table to correct for non-linearity. There is plenty of flash space even on the STM32F103C8 to have a calibration table all adc values.
My money is on the Fluke… even after aging.
Many tech colleges have student labs that have voltmeters with tracable certifications… as do some well-equipped “makers” shops. An evening instructor or a student TA has been known to run a quick test of a DVM agsinst an outside meter… just ask nicely.
Ray
I very much doubt the problem is the Fluke DVM.
I was just trying to point out that people should not have blind faith in their measurement equipment.
People have blind faith in digital measuring, being accurate to the last decimal place.
Very often this faith is totally misplaced.
I find domestic digital thermometers are the worse offenders, I find that they are often up to 1 dec C in error.
But they show the temperature to 1 decimal place, which makes people think they are accurate to 1/10 of a degree, with “absolute” accuracy.
Where as the 1/10 deg is only really usable as a relative measure.
In the case of the OP. The Fluke is probably correct to 2 DP’s, but possible not to 3 DPs
<..>
I find domestic digital thermometers are the worse offenders, I find that they are often up to 1 dec C in error.
But they show the temperature to 1 decimal place, which makes people think they are accurate to 1/10 of a degree, with “absolute” accuracy.
Where as the 1/10 deg is only really usable as a relative measure.
1. As I remember there is one (or more?) ADC-Channels or pins to avoid on the STM32F1xx (there is an errata from STM)?
2. We don’t know which board weravech is using. As example: The maple mini clones lack (in opposite to the original ones) from a secondary LDO which is for the analog inputs only.
just found this library on github using noise reduction algorithm, i tested it based on new fluke dmv and found only +/- 2mv
just modify the lib as “ResponsiveAnalogRead.h” to work with stm32arduino on Blue Pill / 72mhz. and much stable on 48mhz.
https://github.com/dxinteractive/ResponsiveAnalogRead
“ResponsiveAnalogRead::ResponsiveAnalogRead(int pin, bool sleepEnable, float snapMultiplier)
{
pinMode(pin, INPUT_ANALOG ); // ensure button pin is an input
// digitalWrite(pin, LOW ); // ensure pullup is off on button pin”
#include <ResponsiveAnalogRead.h>
ResponsiveAnalogRead analog_v(PA4, true);
ResponsiveAnalogRead analog_i(PA5, true);
ResponsiveAnalogRead analog_volt(PA0, true);
ResponsiveAnalogRead analog_p(PA1, true);
void setup() {
analog_v.setAnalogResolution(4096);
analog_i.setAnalogResolution(4096);
analog_volt.setAnalogResolution(4096);
analog_p.setAnalogResolution(4096);
// begin serial so we can see analog read values through the serial monitor
Serial.begin(9600);
}
void loop() {
// update the ResponsiveAnalogRead objects every loop
analog_v.update();
analog_i.update();
analog_volt.update();
analog_p.update();
Serial.println(” start = “);
Serial.println(map ((analog_v.getValue()),0,4095,0,3273)); //3.273v is the VCC measured with fluke dmv
//Serial.println(analog_v.getValue());
Serial.println(analog_i.getValue());
Serial.println(analog_volt.getValue());
Serial.println(analog_p.getValue());
Serial.println(” raw = “);
Serial.println(map ((analog_v.getRawValue()),0,4095,0,3273));
delay(50);
}
well seems to work well but did anybody make calibration tables for the adc to see how linear is the conversion graph?
Also use vref if possible.
Thank you for mentioning the Vref and calibration on specific chips, i got also STM32F103ZET6-ARM-Development also have few stm23f4 board coming will check it it out to see the difference
it will add some accuracy and it is valuable thought to consider such algorithm to reduce the adc noise not jsut basic averaging ancient concepts , maybe integrating some interpolation will fix the adc debates without sacrificing the speed.
