On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote:

On 3/11/25 15:15, wmartin wrote:

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.

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

On 3/12/25 17:52, john larkin wrote:

On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote:

On 3/11/25 15:15, wmartin wrote:

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!

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.

On 2025-03-12 23:20, wmartin wrote:

On 3/12/25 17:52, john larkin wrote:

On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote:

On 3/11/25 15:15, wmartin wrote:

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!

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

On Thu, 13 Mar 2025 11:17:18 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2025-03-12 23:20, wmartin wrote:

On 3/12/25 17:52, john larkin wrote:

On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote:

On 3/11/25 15:15, wmartin wrote:

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!

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.

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

On 2025-03-13 13:33, john larkin wrote:

On Thu, 13 Mar 2025 11:17:18 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2025-03-12 23:20, wmartin wrote:

On 3/12/25 17:52, john larkin wrote:

On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote: >>>>>

On 3/11/25 15:15, wmartin wrote:

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!

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

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

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

In article <817668f6-ea2b-0fee-7a4e-839c333aa8a4@electrooptical.net>,
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

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

On 2025-03-12 23:20, wmartin wrote:

On 3/12/25 17:52, john larkin wrote:

On Wed, 12 Mar 2025 08:48:41 -0700, wmartin <wwm@wwmartin.net> wrote:

On 3/11/25 15:15, wmartin wrote:

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!

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