the A/D rabbit hole

[kjm1102]

When I read this I was not surprised to see him do what we all do when confronted with piss poor hardware, over sample & hope for the best. It's a great technique, I ran his Pico program 10 times and got readings that ranged from 10883.1 1818.504 to 10765.28 1133.918 a spread of (10883-10765)/10824=1% which is OK considering the massive standard deviations (the second number) in the raw readings. But 100 readings at 50ms intervals takes 5s and that's a long time to wait for a battery voltage. I wondered if optimising the number of readings & their spacing might give a better result in less time.

What followed was a 2 day odyssey full of counter intuitive results, take more readings more widely spaced & get a worse spread. You can go a bit crazy staring at 10x10 arrays of numbers, imagining patterns that aren't really there. But I'm pretty sure there is some aliasing between noise & sampling frequency that made 2ms the sweet spot for the sampling interval. I have no explanation for why 39 is a good number of samples but try changing n to the 38 or 40 in the program below & presumably you'll see what I saw, a spread increase.

Herewith my testing program

from machine import ADC, Pin; from time import sleep, ticks_ms as ms
print('picoadc3.py'); p=0.002; n=39
for g in range(10):
  t0=ms(); medians=[]
  for h in range(10):
    means=[]
    for i in range(3):
      total=0
      for j in range(n):
        total+=ADC(28).read_u16(); sleep(p)
      mean=total//n; means.append(mean)
    median=sorted(means)[1]; medians.append(median); print(median, end=' ')
  diff=max(medians)-min(medians); [var=100*diff/sorted(medians)[5]; print('p', p, 'n', n, 'spread(%%) %.2f'%var, 'in', ms()-t0, 'ms')

and a sample set of results

picoadc3.py
12723 12719 12728 12725 12727 12727 12726 12727 12728 12722 p 0.002 n 40 spread(%) 0.07 in 2401 ms
12717 12725 12721 12732 12727 12728 12727 12732 12734 12738 p 0.002 n 40 spread(%) 0.16 in 2398 ms
12726 12730 12732 12729 12727 12734 12736 12733 12734 12735 p 0.002 n 40 spread(%) 0.08 in 2398 ms
12736 12732 12740 12742 12740 12742 12745 12752 12745 12743 p 0.002 n 40 spread(%) 0.16 in 2398 ms
12739 12746 12746 12739 12732 12741 12738 12741 12740 12746 p 0.002 n 40 spread(%) 0.11 in 2399 ms
12737 12732 12731 12740 12738 12737 12742 12740 12743 12752 p 0.002 n 40 spread(%) 0.16 in 2399 ms
12751 12748 12739 12734 12730 12743 12743 12736 12735 12747 p 0.002 n 40 spread(%) 0.16 in 2406 ms
12733 12739 12740 12754 12740 12740 12735 12737 12743 12741 p 0.002 n 40 spread(%) 0.16 in 2398 ms
12730 12735 12748 12737 12743 12738 12741 12732 12745 12747 p 0.002 n 40 spread(%) 0.14 in 2398 ms
12755 12740 12748 12724 12727 12736 12746 12737 12748 12734 p 0.002 n 40 spread(%) 0.24 in 2398 ms
>

Which is either less spread in less time or I've goofed off somewhere. Curious to see if this is reproducible on another Pico if someone has the time & the inclination to try it out. If the results are legit & you want to use the mean/median technique in your own program, just use the core of the testing program.

from machine import ADC, Pin; from time import sleep, ticks_ms as ms
p=0.002; n=39; t0=ms(); means=[]
for i in range(3):
  total=0
  for j in range(n): total+=ADC(28).read_u16(); sleep(p)
  mean=total//n; means.append(mean)
median=sorted(means)[1];  print(median, 'in', ms()-t0, 'ms')

[robert-hh]

The ADC of the RP2040 has some limitations. If you look at the rp2040 data sheet there is a section about it's errors. Folliwing that, the effective resolution of the ADC is 8-9 bit, meaning that you can discard the lower 8 bits of a read_u16() result.

There is another hidden property in the RP2's implementation of machine.ADC(). If you use the raw channel numer 0-4 of the Pin number 26-29 as argument, the pin will not be initialized. That has to be done by the user code. When using a Pin object like Pin(28) or a Pin name like "GP28" as argument, the pin will be initialized to high impedance. When not initialized after reset, Pin's of the RP2040 seem connected to an internal current sink of 50-60µA, with that current having a large temperature drift. Since you use ADC(28) in your code, you will have that problem. So either use ADC(Pin(28)) or set Pin 28 to input mode before calling ADC(28).
See e.g. issue #10947, dicussion #13488 and PR #13509 and #10947. SO different people found a problem and tried a fix.
About your sample code:
a) The sampling time of the ADC is 2 µs, and the conversion takes <2µs. So you do not have to wait 50ms between two samples.
b) I found it good practice to add a small low impedance capacitor (1-10nF) between ADC input and GND as close as possible to the ADC pin. That lowers the source impedance and suppresses RF noise.
c) Use ADC(PIN(28)) instead of ADC(28), or call Pin(28, Pin.IN) somewhere at the start of your code.

[GitHubsSilverBullet]

All good advice.

I'd like to add that it's almost always a good idea to read the datasheet first, then a second and then a third time. Then (and only if absolutely necessary copy some code from somebody somewhere on the Interweb)
This ›Doctors‹ site is a very good reason to consult the datasheet again and again.

[kjm1102]

Tnx for heads up on the ADC Rob, but after reading #10947

Honestly, I think the original behaviour is correct and gives the most flexibility:
you can specify low channel numbers to get access to the raw channel without any configuration, eg ADC(2)
you can specify high channel numbers to initialise the GPIO, eg ADC(28)
you can pass in a Pin to use ADC on that pin, eg ADC(Pin(28))
it seems that high pin numbers like 28 should give the initialised pin

I'm confused, Damien seems to say that ADC(28) and ADC(Pin(28)) are equivalent. You're sure that's not the case?

Also re your comment on ADC conversion time. I noticed if I reduced sleep from 2ms to 0 in the ADC loop the readings steadily increased during the run instead of being more or less random. Wondering if you have any insight on why that might be?

[robert-hh]

I'm confused, Damien seems to say that ADC(28) and ADC(Pin(28)) are equivalent. You're sure that's not the case?

That may have been the intention, but the code is different, and it works different. I just made again a test with a RPI Pico, 1.23.0 preview and a DC source of 1.65 V, connected through a 47k resistor to Pin 28. The expected reading for read_u16() should be in the range of 32000. Using ADC(28), read_u16() returns 10946, using ADC(Pin(28)), read_16() returns 31783. Once the Pin has been switched e.g. to Input mode, the reading with ADC(28) is fine too.
You did not tell whether you have a voltage divider between battery and ADC input. I guess you have one, because the battery exceeds the range of the ADC. These dividers resistors have usually a large value like 1MOhm, meaning that the source impedance for the reading is high, making it subject to all kind of interference, not only the Pin behavior.

I reduced sleep from 2ms to 0 in the ADC loop the readings steadily increased during the run instead of being more or less random.

The internal resistance of an non-initialized Pin is highly temperature dependent and and increases with the temperature. So the reading do. That will go away if you use ADC(Pin(28)).

About the difference between ADC(28) and ADC(Pin(28)): I made a PR #13509 to close this gap and to document the behavior using raw channels numbers. Maybe it will be merged sometime.

[kjm1102]

I can't reproduce your result with the 47k & a 1.6v battery on pin28 Rob (I get 30k+ count both ways) but then I'm running old v1.17 firmware.

Also when I checked the source to see what size resistors they used in the battery voltage divider I find it's actually on pin 29 so I've been wasting my time all this week reading the wrong pin!.

[robert-hh]

That's an easy solution. And I see that they have a capacitor to GND, reducing the noise and the impedance. With the 200k/100k divider the expected reading is about 33000 for VSys = 5V.

It's interesting that you see no difference between ADC(28) and ADC(Pin(28)). That part of the code is not changed since the initial port. But maybe you board is a newer one. And this behavior shows up at my side only after hard reset. As soon as you once called Pin(28), setting the Pin to input mode, the difference disappears.