rp2040 a2d?

[wmartin]

Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

[Uwe Bonnes]

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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

[Don Y]

Anyone have experience using the a2d in an RP2040? I've heard some negative
opinions, would like to check against actual user experience... in particular
with the Pi Pico hardware. I'm using one as a plug-in subsystem on a simple
controller now, but not using the a2d just yet. Question is: Use it or put an
external a2d on the spi bus?

I guess that depends on your specific requirements: resolution, accuracy and
bandwidth.

If you need "as advertised", you will be sorely disappointed!

[Dave Platt]

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?

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).

[wmartin]

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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

[john larkin]

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

[wmartin]

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

[john larkin]

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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.

Post by wmartin

Post by john larkin
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.

[Phil Hobbs]

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user
experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

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

[john larkin]

On Thu, 13 Mar 2025 11:17:18 -0400, Phil Hobbs

Post by Phil Hobbs

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user
experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

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.

[Phil Hobbs]

Post by john larkin
On Thu, 13 Mar 2025 11:17:18 -0400, Phil Hobbs

Post by Phil Hobbs

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

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?

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

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].)

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

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

[john larkin]

On Thu, 13 Mar 2025 17:11:56 -0400, Phil Hobbs

Post by Phil Hobbs

Post by john larkin
On Thu, 13 Mar 2025 11:17:18 -0400, Phil Hobbs

Post by Phil Hobbs

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

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?

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

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].)

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

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.

[Dave Platt]

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

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 :-)

[Phil Hobbs]

Post by Dave Platt

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

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

[wmartin]

Post by Phil Hobbs

Post by wmartin

Post by john larkin

Post by wmartin

Post by wmartin
Anyone have experience using the a2d in an RP2040? I've heard some
negative opinions, would like to check against actual user
experience...
in particular with the Pi Pico hardware. I'm using one as a plug-in
subsystem on a simple controller now, but not using the a2d just yet.
Question is: Use it or put an external a2d on the spi bus?
Thanks,
Bill M.

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.

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!

Post by john larkin
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.

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
There isn't really a control loop, I'm just measuring the motion profile

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.

[Gerhard Hoffmann]

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

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.

<
http://www.hoffmann-hochfrequenz.de/project_gallery/project_gallery.html
2nd picture from bottom. Maybe I should update the web site in
the next years. ;-)

Cheers, Gerhard