What is the best way to powering down the CPU during AD conversion?

Projects Programming
1

Hi

I found some examples of code in the forums about shutting down the CPU to minimise noise. Those samples and posts were a bit old. From 2010 and earlier. What is the latest info about doing this.

My board is crowded and because of that PWB wiring is not optimal. We have got +-4,,,+-8 counts of noise in the results.

Regards
Leif

2

Those samples and posts were a bit old. From 2010 and earlier.

So? If it works, it works. Age doesn't cause code to rot, you know.

We have got +-4,,,+-8 counts of noise in the results.

Not likely caused by the CPU itself.

3

The problem is in "if it works". I would not like to test it here. Besides there will be new CPUs, they may use different registers and so on.

But I found this:
Sleep during ADC conversion

I hope it works.

4

PaulS:
Age doesn't cause code to rot, you know.

I disagree. :slight_smile:

I've got code written thirty years ago that I was distinctly proud of at the time, which hindsight reveals to be utter garbage.

5

fat16lib has been posting quite a bit about ADC noise and the "low noise" mode in the Storage section recently.

I suggest you have a read. Bottom line is it appears the low noise mode does not make an appreciable difference. Also if you're getting the sort of noise you suggest it's likely on your end , not the atmel.

fat16lib did some fairly rigorous testing and found noise <=1LSB.

I also have and external cct with 8 op-amp buffers feeding into a Uno and I don't even see movement in the last digit.

That's all rather good news because the ADC sleep mode takes out MPU for extended periods so it's a heavy performance hit. Also there's more you can do to fix your external circuit than you can do about the noise on the atmel ADC.

This is one aspect of the hardware I'm quite impressed with.

6

Interesting. It would be nice to test the ADC with interrupts but now it is not so urgent. Our PWB is too crouded and analog tracks are long.

Thank you
Leif

7

There are a number of things to look at beyond the obvious. I am making the assumption that your EE has done his homework properly and thus the various supplies are clean...

  1. Unintended noise from ground loops these can be both instrumentation as well as interfacing and both should be investigated before you spend a lot of time pounding the noise out of the data. For example, Do you use a Star ground layout if not perhaps you might re arrange the return leads from your analog I/O to make as near a star configuration as possible.
  2. Granularity of measurement. A voltage divider to measure a 25V supply with an Aref of 1V would present some counting issues and trying to measure a voltage close to either rail would also present issues.
  3. Concurrent processes or simply making a measurement at the wrong time, If you have just done something big... something that might impact the power supply, making any measurement immediately prior to or following the action might impact your measurements.
  4. Impedance mismatch. For best measurement accuracy the Analog input should never be driven from long wires external to the A/D input and an input should have a voltage follower driving it. The advantages of voltage followers cannot be over-stressed, Exceptionally high input impedances with very low output impedances make for an ideal low noise measurement.
    5, Time 1, is the quantity stable at the time of measurement? Are you trying to measure a varying voltage? attempting to smooth or average those measurements can be difficult. The results of techniques to combat this error will fail unless the periodicity is a part of the measurement equation.
  5. Time 2, does the measurement occur at some interval that is close or harmonically related to the signal?. measuring a voltage that can vary cyclically can produce results that are unintended, for example measuring a 60 Hz signal with a measurement cycle of 61 Hz can produce odd results. any other measurement where any time related variable must be measured should be examined for this condition. Variations due to over/under sampling are also an issue
    All of the above examples can produce results that look like analog noise in the measurements. It is very possible that your issues are a combination of several of the above.
    I am a retired EE and the things I mentioned above were mistakes I made at one time or another in a misguided attempt at driving my firmware engineer nuts or mistakes that my firmware engineer made that drove me batty, All are easily overlooked and all can be cumulative in nature.

Doc

8

PaulS:

Those samples and posts were a bit old. From 2010 and earlier.

So? If it works, it works. Age doesn't cause code to rot, you know.

No, but I've found some programmers can cause code rot, or is that just from my own programming efforts. :wink:

We have got +-4,,,+-8 counts of noise in the results.

Not likely caused by the CPU itself.

I would test with analog input pins first grounded and then wired to Vcc and see if there is any count variations. Always suspect external electronics causes first until proven otherwise when dealing with the analog world is my rule.
Lefty