rp2040 a2d?

It is know to be bad, far away from 10 bit ENOB expected from a 12 Bit A2D

I've been using one as an audio-frequency receiver for a ham-radio TNC project. Its quality is... well, meh.

The data sheet acknowledges that there are some very significant nonlinearities in its transfer curve, at several points in the range. This will add up to significant distortion, or other forms of illogical behavior.

Something about the Pi Pico (in particular) seems to cause a significant difference in ADC signal quality, from one board to the next. I built two TNCs, with Pico modules from the same tape-strip, identical PCBs, all other components out of the same packages. One board's packet-reception rate is a few percent better than the other's, quite consistently. I'm not sure how much of this is due to differences in the ADC linearity, and how much might be due to board-to-board variations in the switching-regulator noise (which looks as if it's quite significant on all of the Pico boards) or other factors I haven't identified.

I got significantly-better packet-reception quality (again, a few percent) on a cousin board I built using an STM32F411 module. How much of this might be due to the '411 having better ADC linearity, and how much might be due to the fact that the module uses a linear 3.3-volt regulator rather than a switcher, I do not know.

I think the answer to your question is going to be "it depends"... on how critical your measurement needs are, how many Bad Things can happen as a result of measurement error, and on whether averaging and calibration can work around the device's limitations. I suggest that you consider the RP2040's ADC to be a convenience, rather than a quality peripheral (after all, it's part of a $0.70 chip!).

You can probably get cleaner results from a discrete solution (a separate ADC, with a dedicated low-noise LDO to power it and provide a reference).

A big thank you to all who responded! External seems the safest bet...

-bill

One trick to improve a bad ADC is to add noise (or a triangle wave) to the signal and lowpass filter or average a lot of readings. That will pave over missing codes, but not help gross nonlinearity much.

You can make a triangle from a timer and a port pin into an RC.

An ADC inside a uP is tricky. There's too much noise, and the silicon process is optimized for digital, not analog.

I see how that goes, but I think I'm better served by going "outside" the micro in this case. The game is to monitor & record the position of a moving mechanical part, moving quickly & not in any kind of predictable periodicity, so averaging probably is out of the picture. I may ditch the a2d idea entirely & go with an encoder strip...if I can figure out where to put it!

Digitize at 100 KHz and lowpass to 100 Hz maybe.

Am 13.03.25 um 01:52 schrieb john larkin:

Some 20 years ago, I used an ADUC842 by Analog Devices ( 8051 + ADC + DAC + temp ). There was an ARM version, too. Nothing for severe complaints.

Cheers, Gerhard

Averaging doesn't have to be stroboscopic--you can just run the ADC N times faster and sum N adjacent samples.

A 500kSa/s ADC can average a lot of samples on the time scale of most common sorts of mechanical motion control. How fast is your control loop?

Cheers

Phil Hobbs

I like exponential smoothing, basically simulating an RC lowpass filter. DSP jocks sneer at this algorithm, for some reason. Too easy, I guess.

The RP2040 has two CPUs. We call them Alice and Bob. One could assign Bob to doing nothing but the ADC acquisition and filtering.

It's good news in general, I agree. Of course as with almost all IIR filters, you have to be careful to avoid limit cycle nuisances if the word length is too short and the time constant is long. FIR filters don't have that problem. (First order IIR filters eventually decay to a nonzero final value somewhere in [-0.5/decrement, +0.5/decrement].)

Yup. Or run the ADC from the DMA peripheral, with ping-pong buffers. Either way, you can arrange to get good repeatable hardware timing.

Cheers

Phil Hobbs

We're having Bob run an AD7699 8-channel ADC at its max rate. The SPI interface is a horror. My Pi guy used the programmable hardware state machine inside the RP2040 to talk to the ADC instead of using the SPI engine. I was impressed.

Yup again. I've got the ADC on the RP2040 Pico running at 500 kilosamples/second (as fast as it'll go), using two chained DMA buffers. Works like a charm and (with a sufficient amount of RAM for the buffers) keeps the interrupt and task-switch overhead down to a trivial minimum. I'm sure the same trick is possible if you decide to use an external ADC, using SPI or the PIO block to fetch the samples.

Just do read all of the instructions in the programming manual about how one must chain and un-chain buffers during the DMA-start and DMA-stop processes. I managed to get a situation where everything worked right the first time, but after stopping and starting acquisition again, both DMAs were active simultaneously and were doing a King Solomon number on the samples coming from the ADC. I found myself whistling "Chain Of Fools" while coding up a fix for my error :-)

Fun!

These days Simon doesn’t let me near the firmware, so I have to make stuff up. ;)

Cheers

Phil Hobbs

of an air cylinder connected to mechanical linkage on a sequential gearbox shifter. Current off the shelf systems just have a "guesstimate" delay factor plugged in to the computer that says when to shift, how long to kill the ignition during the shift. It has no idea if the mechanism actually did what was intended... which can make obnoxious noises & expensive scrap metal if you get too greedy minimizing the delay time. The hardest part of this exercise is coming up with a sensor mounting that doesn't get in the way or fall off from vibration, etc.