Better ADC-Accuracy below the lowest recommended ADC clock frequency for XMEGA A

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question: Why would the accuracy of the ADC conversions improve by going below the recommended lowest clock frequency for the ADC (ATxmega128A3U @12Mhz)?

 

- This is exactly what is happening on a project where the voltage of a LiPo battery is being constantly checked

- Now, the recommended values given by Atmel are the following:  

 

  • APPLICATION NOTE: Atmel AVR1300: Using the Atmel AVR XMEGA ADC 

1.8 Conversion Speed (Page 13)

...Lowest ADC clock frequency for both XMEGA A and XMEGA D devices are 100kHz. See device datasheet for more information. 

  • DATASHEET: ATxmega256A3U / ATxmega192A3U / ATxmega128A3U / ATxmega64A3U

Table 36-9. Clock and timing. (Page 79)

...ADC Clock frequency -> Min. 100 kHz

 

- Working close to the lowest limit (12MHz / 128 => 93,75kHz) was giving me an error of -0,2v

- I increased the frequency by reducing the prescaler to 12MHz / 64 => 187,5 kHz  which in theory should improve the accuracy but I was getting a bigger error of -0,4v

- Finally, changing into the other direction  12Mhz / 512 => 23,43kHz I finally got the exact value, no errors!!!

- This is nevertheless in theory not recommended, then why is it improving all meassurements? Even on the ADC-conversions of an external power supply. No errors going this slow. 

- On posts like "Atmel Xmega ADC Problems & Solutions" from "Frank's Random Wanderings" I've seen that other people also see that the performance improves by going below 100kHz. In his case 62 kHz. But nowhere have I seen any explanation

- Any ideas? 

 

Any hint would be greatly appreciated!

 

Tools and Controller used:

 

  • AVR Studio 5.1
  • AVRToolchain: AVRGCC\3.3.1.27
  • Controller: ATxmega128A3U

 

ADC Configuration:

 

		ADCA.CTRLB		= ADC_RESOLUTION_12BIT_gc;
		ADCA.REFCTRL		= ADC_REFSEL_INT1V_gc;			// 1V
	        ADCA.PRESCALER		= ADC_PRESCALER_DIV512_gc;		// 12Mhz / 512 => 23,43kHz
		ADCA.CH0.CTRL		= ADC_CH_GAIN_1X_gc | ADC_CH_INPUTMODE_SINGLEENDED_gc;

		ADCA.CALL = ReadSignatureByte(PRODSIGNATURES_ADCBCAL0);
		ADCA.CALH = ReadSignatureByte(PRODSIGNATURES_ADCBCAL1);

 

This topic has a solution.
Last Edited: Fri. Jan 13, 2017 - 02:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr_ivan wrote:
On posts like "Atmel Xmega ADC Problems & Solutions" from "Frank's Random Wanderings" I've seen that other people also see that the performance improves by going below 100kHz. In his case 62 kHz. But nowhere have I seen any explanation
Just to say that Frank's notes related to the original xmega128a1 which, like a lot of the early Xmega had serious faults in the ADC. However Atmel phased out all the afflicted devices and replaced most with a similar device that also had the bonus of USB added. As you mention 128A3U I think it's a fair bet you are using a "modern" Xmega so some/all of what Frank wrote no longer applies to your device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr_ivan wrote:
- Any ideas?
Excessive source impedance

What's the impedance (R, C) before the XMEGA?

Reasons :

  • AVR1300, 1.12.10 Source Impedance
  • XMEGA AU, 28.10 ADC Input Model

http://www.atmel.com/devices/ATXMEGA128A3U.aspx?tab=documents

...

Atmel AVR XMEGA AU Manual
(file size: 7.2MB, 478 pages, revision F, updated: 04/2013)

http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf

...

Atmel AVR1300: Using the XMEGA ADC
(file size: 879KB, 27 pages, revision I, updated: 06/2013)

This application note describes the basic functionality of the Atmel® AVR® XMEGA® ADC with code examples to get up and running quickly. A driver interface written in C is included as well.

http://www.atmel.com/Images/Atmel-8032-Using-the-Atmel-AVR-XMEGA-ADC_Application-Note_AVR1300.pdf

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I certainly agree with the above.

 

Do you have a cap on the input signal to ground, perhaps a 0.1 uF cap?

Batteries don't change voltage quickly, so a big cap isn't a problem.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies.

 

  • The battery is connected to a battery-management-chip with a Capacitor in parallel: 4.7µF
  • The battery voltage (LiPo nominal 3,7v), is divided with: 470kOhm and 130kOhm (the second one connected to the ADC-Pin)
  • The LiPo's impedance 65mΩ (datasheet)

 

So from "Figure 1-15. Schematic" in "Atmel-8032-Using-the-Atmel-AVR-XMEGA-ADC_Application-Note", this means that the 130kOhm is connected in parallel to the RC circuit (100k and 1n)? Way larger than recommended? How low should it stay?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr_ivan wrote:
The battery voltage (LiPo nominal 3,7v), is divided with: 470kOhm and 130kOhm (the second one connected to the ADC-Pin)
470K // 130K for a source resistance of 102K

avr_ivan wrote:
this means that the 130kOhm is connected in parallel to the RC circuit (100k and 1n)?
320K // 100K for a source resistance of 76.2K to the 1nF

avr_ivan wrote:
Way larger than recommended?
Yes per the ADC sample rate but the 1nF is 200 times the 5pF ADC sampling capacitor (200x is well more than enough); no per battery drain.

avr_ivan wrote:
How low should it stay?
Depends on requirements and design.

  • Make no change; if it ain't broke don't fix it wink The longer than spec ADC sampling time duration may be a concern due to leakage from the ADC sampling capacitor at high temperature.
  • Add, or increase, the charge storage capacitor per DocJC's recommendation.  Switched capacitor SAR ADC need significant charge transfer to be accurate enough.
  • Change from singled-ended to differential and use Gain Stage Impedance mode
  • Reduce from high impedance to low impedance via an operational amplifier.  Common op amps have about 5mV max of offset that's a match for the ADC's estimated max offset; next step up in op amps reduces the max offset to about 1mV.
  • Move from xmega128A3U to xmega32E5 for a more precise ADC with variable sampling time duration though slower ADC, loss of USB, greatly reduced program memory space, less data memory space.

http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf 

(page 350)

28.10.1 Gain Stage Impedance mode

To support applications with very high source output resistance, the gain stage has a high impedance mode. In this mode

the charge on the S/H capacitor is kept after each sample, and the S/H capacitor can be fully charged by doing multiple

samples on the same input channel. When low impedance mode is used, the S/H capacitor charge is flushed after each

sample.

http://www.silego.com/products/opamp.html

http://www.atmel.com/devices/ATXMEGA32E5.aspx

 

Edit : 2 more URL

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jan 11, 2017 - 05:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And just to be clear, the 0.1 uF cap connects from the ADC pin to Ground.

The cap on the battery management chip is great, but that isn't the cap were talking about for this issue.

 

The 0.1 uF cap is probably larger than needed, but one usually has a bunch of them around as the standard by-pass caps, so it becomes an obvious choice when the input signal is DC, and the filtering by the R-divider and the cap just doesn't matter.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr_ivan wrote:

Question: Why would the accuracy of the ADC conversions improve by going below the recommended lowest clock frequency for the ADC (ATxmega128A3U @12Mhz)?

 

Often items like lowest clock spec are from a testing time viewpoint, - they can save time with specs of only a couple of values.

 

Unless it uses capacitive dividers,  SAR hardware usually has no lower clock limit.

 

ADC's will change noise with sample speed, as the processor activity noise crosstalk window is different.

Can you try IDLE during ADC convert, to see if that  improves errors ?

If you cannot idle, a sweep of ADC rates can fine a tolerated minimum, or, sample many times, and average.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
470K // 130K for a source resistance of 102K
 

 

These resistors are in series as a voltage divider, why do you calculate the result in parallel? I think I'm missing something...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because to evaluate the effective source impedance of your high voltage resistive divider you have to look back at the junction of the two resistors and replace the voltage source with a short circuit, thus putting the two divider resistors in parallel. Haven't you heard about Thevenin's Theorem?

 

Ross McKenzie ValuSoft Melbourne Australia

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thanks a lot for all the replies. I will mark this post as the answer because I wanted to resume all the info, but all the credit goes to gchapman for pointing out the source impedance and to valusoft for reminding me about Thevenin's Theorem. I immediately got out the good old "The Art of Electronics"...page 9 ... forgot about this little detail... :) or actually :( 

 

  • Basically, the source impedance of my voltage divider (calculated using Thevenin's Theorem) was giving a fADC < 103 Khz ,using the formula shown below
  • This is very close to the lowest frequency recommended by Atmel for XMEGAs A  (min=100kHz)
  • Nevertheless, on the same Application Note (see below) they mention that 

Having a fast ADC clock gives a short propagation time for each sample, but does not mean that you cannot sample a signal at a much slower rate. For instance, an application could sample at a rate of 10kHz even if the ADC clock is 2MHz.

  • I went all the way down to 23.4kHz and the whole application seems to continue working fine (here the ADC conversion is exact). Nevertheless the design will be changed. The 13 ADC cycles used for the conversion represent a way larger time than when using >100Khz

 

From: "Atmel-8032-Using-the-Atmel-AVR-XMEGA-ADC_Application-Note"

 

  • 1.8 Conversion Speed

 

 

  • And: