Glitches on ADC

Neat post - I believe 2 (additional) items will "add value:"

• have you tested for similar upon other boards?   (avoiding single-board anomaly)
• You note a separate supply for VREF+ and VDDA.  If that's distant from the MCU it must be properly decoupled.  (wise to decouple - anyway)
• Firm/I always employ small ferrite bead + small & large value filter caps (close) to VDDA.
• You note a resistive divider - but not your attempt to "match" the input impedance of the MCU's ADC input.

It would be appreciated if you'd identify that graphing program AND how you imported the MCU's ADC data.   Thank you.

-good point in testing on more boards- Just did, same story, see picture.

-Power supply is a few mm from the MCU pins (LP2980-3.3)

-Small ferrite and large filter caps are in place (1uH, 10uF/100nF)

-The resistor are simply two 2k6 dividing the 3,3V VDDA supply. 100nF in parallel with lower resistor.

-good idea to extent sampling time - tried 64 clocks, same result

We are performing uDMA transfer to some big arrays into a combination of internal RAM and external RAM. An internal transfer generates raw wave files (true data) to output through a web interface as download and direct view as shown here.

Hi Peter,

Have noticed similar with EK-TM4C1294-XL launch pad ADC noise is quiet high +vRefA directly tied to +3v3. The odd thing is a good part of the sample noise was coming from +5 feeding +3v3 LDO assume the MCU internal 2v0 LDO.

The launch pad was powered from computers USB port and +3v3 LDO regular regulator has a 2uf ceramic on the output seemingly was not enough decoupling. The scope revealed 200mv saw tooth wave on +5 feeding the +3v3 LDO. Adding a 47uf electrolytic +5v stopped most all sample noise mostly present in the ADC internal temperature sensor and bleeds into the channel samples. BTW acquisition of stray pulses exiting out the channel from the internal ADC capacitors of SAR type ADC can be coupled to ground via resistor and setting the RC time constant to match expected acquisition times can remove a lot of that noise.

TI-Analog precision ADC seminar.pdf

@BP101, the slides from the old TI seminar was very useful and gave inspiration how to make a better drive circuit for the ADC inputs.

By having a drive of the ADC input of a voltage divider made by two 2K6 resistors and a 100nF low side capacitor we can clearly see the effect of the internal switching capacitors sending charge back to the external circuit. By changing the voltage division resistor to just 330 ohm the influence from the internal circuit disappeared.

We have tried to split the VDDA and VREFA+ by having a bead to the VREFA+ and a 100nF capacitor to GNDA. It did not make any change.

We have tried to switch off the ethernet connection while sampling, but no effect was observed.

We are using the AIN2 pin (pin 14) so no digital pins nearby.

We still see these spurious spikes. Obviously anyone can average the result, but we need the actual individual samples at full speed.

So the question is still open, is this something we will need to accept as normal behavior ?

Hi Peter,

Sorry to get back later so lately tied in fight with my own demons and have turned a few mile stones - hurray!!

That divider can also be trade off pulling ground noise so we are using 510 ohm versus your 330 ohm. Calculated a 20pf (.02nf) provided the proper acquisition RC time constant for LM3S SAR ADC but it also caused edge roll off and slows down the step response. It often requires more than 1nf to remove glitches but 100nf sets the record like that's 0.1uf. Perhaps an internal 3/4 filter can remove even more undesired low level noise.   

You stated to have isolated +VREFA from VDD  via ferrite bead, inferred a high resistance as no mention of adding series resistor for noise rejection. Perhaps try to isolate GNDA with ferrite bead if it is very low resistance 0.02mOhm or less. You noted 10nf filtering +VREFA and .01uf to 1.0uf ceramic capacitor TM4C suggested values (2 parallel capacitors) or 2uf 1uf typical, see note (c) ADC electrical section.   

ADC samples (not sure if posted yet) ADCCTL REG 38 configuration (+Vref ) internal or external,  default internal reference.

// Configure both ADC0/1 VREFP external VRefA 3v3 
ROM_ADCReferenceSet(ADC0_BASE, ADC_REF_EXT_3V);
ROM_ADCReferenceSet(ADC1_BASE, ADC_REF_EXT_3V);

Thank you all for your ideas and inputs.

Latest test have been:

- Use of small battery in parallel with 100nF and 2n2F as input to the ADC - no change in signal noise:

- Adding bead in series with digital supply for the processor - no change

It seems as if some internal noise is disturbing the conversion. The noise seems without a specific frequency. It might be in the SAR itself as an increase in sample/hold time-clocks does not make any change to the issue.

It could be of interest if anyone have made a similar setup and having good results ?

Then at least we could try to replicate such conditions.

Peter Johansen said:

- Use of small battery in parallel with 100nF and 2n2F as input to the ADC - no change in signal noise:

That was a bit of a long shot but worth the check.

Peter Johansen said:

- Adding bead in series with digital supply for the processor - no change

I wouldn't have expected much from that

Peter Johansen said:

It might be in the SAR itself as an increase in sample/hold time-clocks does not make any change to the issue.

That's why I keep suggesting investigating the reference.

This is almost certainly a capacitive based SAR. As such it needs to charge and discharge the comparison capacitors multiple times for each conversion (once per bit). So if it takes 1uS for conversion (it's actually faster) you can expect bandwidth requirements on the order of 100MHz for the reference input. And since it is charging and discharging capacitors it is a high current requirement.

Robert

Robert - would not an even larger, paralleled cap (in addition to those listed) assist the delivery of those, "high peak currents" you well noted?

Always two questions

1. Is this within spec? You can't depend on exceeding the spec.
2. How well can I do?  But the spec is usually conservative so you may do better. So, how much time do you want to spend improving a result you cannot guarantee?

Only TI could answer the spectrum issue with any definiteness. And I think the real question is, Am I missing something I should be doing? I don't think I've any other suggestions but I'll ponder a bit, maybe someone else does.

Robert

BP101 said:

Hardware averaging is said to reduce through put ...The result is a much cleaner sample range with reduced precision

I think it's mathematically impossible for averaged values to be less precise than the originals. The range of the averaged values will be no more than the range of the originals. In practice it will usually be less although degenerate cases are at least a theoretical possibility.

How did you determine otherwise?

Robert

Perhaps (surely) time for cb1's (famed) "reach reduction:"

Our poster claimed, HW averaging "is said" - to reduce throughput - beyond "said" - that IS the case.  (averaging by "n" requires "n" samples to be required & processed - which (clearly) takes longer than individual samples.)

He then (reaches) with, "...sample range with reduced precision."  The distribution (bell-curve) above illustrates the futility of that reach...

Note the power of the diagram and the (inspired) language - which "startle" - then assuredly, "drive home the point!"

BP101 said:

For instance the ADC temperature sensor readout and other digital readouts of analog samples are more stable around a central value versus the large swings in the output values otherwise with out hardware averaging enabled.

That would be increased precision (reduced variation) and it's a good thing. Unlike your implication that it was a bad thing.

BP101 said:

Plausible the sample rate average period constrains the range of the SAR stepping capability

Um, no

Robert

BP101 said:

BTW: Notice the value curve goes vertical for accuracy and broad spectrum for precision.

No

Robert

BP101 said:

BTW: Notice the value curve goes vertical for accuracy and broad spectrum for precision.

Oh my - No and No!

Here's the curve (again) for ease of reference.

The curve (absolutely) does NOT "go vertical" for accuracy - as you state.   Instead - Accuracy is (properly) defined as the "Difference" between the "Reference Value" and "Measured Value."   There is NO, "Going Vertical!"

As to "broad spectrum" for "Precision" - that's not true either!   Precision represents the, "Clustering of values" around some central, measurement point.  It is the relative "repeatability" of these measures which dictates precision.   Recall my diagram's title, Measurements may be "Precise" but NOT "Accurate" or vice versa - or neither - or both.   Again - there is NO, "Going Vertical."

That accuracy span ray is a bit ambiguous unless the vertical line (center bell curve) represents the probability density increases as the bandwidth narrows around the reference value. Again the precision density is reduced yet the band width widens around the reference value at the very bottom of the precision span.

Lots going on in that bell yet where is both precision and accuracy existing together in the bell at the same band width? Seems to me there is a trade off being elaborated in the illustration since probability density is never equal at either end of top or bottom of the curve.

My friend - do you not (most always) "shape-shift" and add complexity - where there is little? (or none)

My drawing delivers exactly as its title states - it (clearly) illustrates the difference between Accuracy & Precision.

You claim that, "Lots going on in that bell (curve)" yet fail (completely) to list and/or identify a single event! (going on) That bell curve represents the collection of measurements - nothing more - nothing less - thus is (hardly) representative of, "Lots going on!"

No "bandwidth" - as you introduce - is presented w/in this curve - its entire intent is to address the (almost) chronic "misuse" of accuracy & precision!   (in a memorable and highly illustrative (i.e. educational) manner.)

If we don't understand (basic) definitions it becomes difficult (if not impossible) to fully/properly/effectively communicate - such deserves (some) consideration - and motivated this cb1 presentation...

BP101 said:

Peter it seems you/others completely ignore claimed external +VREFA capacitor 2n2f//100nf. That value does not meat the minimum required 1uf // 0.1uf and will not filter the internal ADC properly. The +VREFA you have stated was installed 2n2F (0.0022uf) // 100nf (0.1uf).

I don't have a data sheet  for a device with a reference, good catch. It would appear the current requirements of the comparison caps are higher than I suspected.

BP101 said:

Not many engineers work specifically in Farads when describing small value capacitance

Using fractional uF to describe small capacitors is a North American convention. Others are more sensible than us.

It's also fairly common as well to use the SI prefix as a decimal separator. That not only sidesteps the issue as to whether , or . is the appropriate separator but also eases reading printed schematics where otherwise a fading print and the unfortunate activities of a meandering insect could totally change the meaning.

Robert

Some interesting news:

(@BP101) Applying a 1uF cap in parallel to the 100nF and 2n2F cap on VREFA+ made no significant change (maybe marginal).

Changing from ADC1 to ADC0 made significant change giving much lower spikes. Any good explanations ?

Peter Johansen said:

- It is all the same layout, as it is a software feature to choose between ADC0 and ADC1

That suggests some sort of internal difference and maybe back to process variation. If that is the case there may not be much you can do about it.

Have you tried other channels on the different A/Ds?

Robert

May I suggest that ALL analog signals input (other than the channel under test) be set to equal values - across (both) ADC0 & ADC1.  

Further - have you thought to monitor (all) key/critical MCU voltages (along w/your ADC data logging)  to see if your ADC spikes may be "power related?"

Poster Robert's suggestion, "Repeat such test upon a different ADC Channel" receives my strong second!

>>Any good explanations ?

So VDA is again coupled to +VREFA and is quiet on the oscilloscope during sampling?  If not why not try adding a 3.3k series resistor (remove ferrite) or even double the 1uf capacitance if the filter is not sufficient to keep the ADC peripheral quiet. That might give clues to what is really going on as it seems your intuition (gut) is telling you something isn't quite right.

Suspect you have so far rang out all adjacent pins checked for crosses, shorts and verify proper grounds on ADC/GPIO ports.

The plating process is not always fool proof and past had via missing any platting or very high resistance top to bottom of PCB. It takes time to find odd things like that and very high visual inspection under 8 diopter or better magnification lens. The good thing is often the very same issue can or may exist in all PCB's.

Odd thing recently stumbled across POR sets a default 14 ADC channels and can be programmed for less may quiet things down much more effectively. Another thing might be to review the formula used to calculate sample hold time and series resistance is uniquely different for 2MSPS versus 1MSPS. BTW: Tivaware expects us to configure the sample hold time separately from the sequencer configuration. We do that prior to configuring the sequencers. Past had added the hold value to end of sequencers configuration and compiles without error but later found that does not actually set the hold time register as expected it should include.