# Analog -Digital Conversion is poor

In one of my Photon applications I monitor a 12 v power source. The power source is connected to A5 through a voltage divider consisting of two resistors (1k5 and 4k7) that takes care that a voltage on pin A5 of 3v3 corresponds to an input voltage of 14v max.
The result of the conversion is however very poor: it is inaccurate (it swings up and down for about 200mV on 12v) and the resolution is very poor: discrete steps of about 100mV on a total scale of 12v, while you would expect around 3mV (in this case 14V/4096).
I think something is going wrong in the ADC process, but I donâ€™t have a clue what. Whatâ€™s worth mentioning perhaps is that I am using the system in Manual System mode, and I thought that maybe the sample frequency of the ADC conversion somehow interferes with Particle.process frequency tat is determined by the applcation software.
Does anyone has a clue what a logical step would be to investigate this problem?

Can you show your physical setup and code?
Have you got common ground between the 12V source and your Photon?
What is your 12V power source?
â€¦

1 Like

It really is rather â€śrock-bottomâ€ť:
the power source is a 12v accu, that is connected through a 4k7 resistor to A5 of the photon. A5 is connected to ground through a resistor of 1k5 and there are two capacitors in parallel to this resistor: an alco of 100uF and a ceramic cap of 22nF. Thatâ€™s all.
There is a common ground between the 12v source, the Photon and all other hardware (incl a power supply for the Photon (5v derived from the same 12v supply).
All electronics are mounted on one board (euroformat: 10x16cm) so the wires are short, except for the supply wires that connect to the accu (and that are rather thick. (Whatâ€™s more I compare the result from the AD conversion to the voltage measured with a digital multimeter connected to that same board.

Also the code is rather basical; here are te relevant parts:

``````STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY));
SYSTEM_MODE(MANUAL);
.
.
int VCCAVG = 0;
.
.

void setup()
{
.
.
Particle.variable("Accuspanning", &VCCAVG, INT);
.
.
pinMode(A5, INPUT);
.
.
}

void loop()
{
.
.
VCC = analogRead(A5) * 13.86 * 3.3 / 4096;//Note: all those added factors are resulting from my attempts to calibrate the system
VCCAVG = 1.02 * VCC * 11950 / 39;
.
.
///somewhere in the loop is a Connection module that starts either through a manual system reset (a pulse switch connected to RST) or
as a result of a timed action that occurs every hour when Time.minute() == 58.
The timed action switches off WiFi after 40 seconds.
///
.
.
}
``````

This is outdated syntax - nowadays it's just

``````Particle.variable("Accuspanning", VCCAVG);
``````

For `analogRead()` you shouldn't set `pinMode()`.

Iâ€™ve adapted the syntax; my first impression is that this didnâ€™t improve the situation, but in order to be sure Iâ€™ll have to test for a longer period of time; will do that tonight.

Could you also comment on my question as to whether it is possible that somehow the sample frequency of the AD process might interfere with switching between loop and particle.process?

`analogRead()` is a synchronous call and will not return unless the multi-pass sampling has finished. While `SYSTEM_THREAD(ENABLED)` can potentially squeeze inbetween individual passes but shouldn't impact the sampling.

However, the onboard radio might cause some interference with long wires and unfortunate placement of the antenna.

I'd also suggest you make some test sketch with a simple potentiometer 3v3 to GND sampling the position and see what that reports.

1 Like