ADC result is quite noisy

Fanx,

Are you using a controlCARD, TI kit or a custom PCB?

Are you using TI example code from controlSUITE?

Regards,

Adam

Hello!

1 I would recommend you refer to http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/264395/932865.aspx#932865 & http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/268446/937894.aspx#937894

2 How did you connect analog ground?

Regards,

Igor

Separating analog from digital ground always helpful - as is matching the output impedance of your voltage source to the input impedance of the ADC's input. 

ADC chapter of MCU manual and ADC spec listing should properly detail.

Test method and framing of your question may both benefit from further investigation - serious review...  Unlikely that the ADC is, "broken..."

Hi Fanx,

The sampling frequency should not matter at all. Please check the adc values using an external dc supply; also keep varying the sampling frequencies. Prepare a table and you'll observe that there's no effect on adc values!

Regards,

Gautam

Fanx,

Depending on how you have your ADCINA connected to both signals (I am guessing via jumper wire?) you may acquire some noise as that wire can act like an antenna.  

Do you have access to a DC power supply?  If so, try using that to drive the ADCINA.  

Regards,

Adam

Gautam Iyer said:

The sampling frequency should not matter at all.

Or not!

Should multiple ADC channels be in play - and should the channel scanned just prior to the "channel of interest" be of a sufficient voltage difference - I would bet that the sampling frequency very much does intrude. 

Our group works w/many ARM MCUs (yet not yours) and should your ADC implement an internal, ADC input capacitor - its ability to charge/discharge is indeed influenced by sample/scanning rate.  Quite easy - and quick - for you to test this theory and see just how (or if) this suspicion proves correct.  (and - to be fair to poster Gautam - he urged that you test & chart results - but we believe his conclusion is incorrect) 

Silent is your attempt/understanding of impedance match - your voltage source and MCU's ADC input circuit requirement.

One possible "work-around" (we've found - works across multiple vendors) is to "disallow" grave signal level differences during successive channel conversions. And - surely devil lurks that detail - and earns "big bucks..."

All,

The frequencies stated in this thread are well under the max sampling rate for this device.

Fanx,

Please let me know if you were able to use a DC power supply to drive the input and the results.

Regards,

Adam

Adam Dunhoft said:

frequencies stated in this thread are well under the max sampling rate

Thus - can those very reduced frequencies serve as the proper basis for, "channel cross-talk and or bleed" during more usual, higher frequency ADC usage?

We find that a broader solution - covering greater user spectrum - is often of far greater value than one so limited...

Thanks cb1 for the detailed info on effect of sampling rate on ADC values. As Fanx was using a single channel, I ignored the fact but thanks for the valuable input.

Regards,

Gautam

You are quite welcome - mon ami.  We've worked w/multiple ARM7, then M3, now mostly M4.  (many vendors - try to choose best "fit" for the Ap)

This ADC issue is not confined just to this vendor!  (we note it often)  Thus - "kitchen sink" school of MCU design may not always yield best performing - most robust MCU peripherals.  And - as you/others have noted - signal mix between MCU's (mostly digital) and sensitive analog circuitry is quite demanding and hard to fully achieve/tame.

When best possible analog performance is the goal - valuable to look @ how real "pros" solve (i.e. scope makers, serious data-acq products).  Rarely - if at all - will an "all in one" MCU be tasked with such serious analog performance.  Again - no knock upon this esteemed vendor - this ADC limitation flows "across the board" - all vendors suffer.

Independent hi-res ADC, magnificently isolated, guard-banded against intrusive digital - and then mechanically shielded - seems to be, "state of the high-performance ADC art..."  Lesser analog requirements - where cost/size dominate - employ MCU "solution" - and user should be aware of any/all engineering "trade-offs."

To try and provide a little more detail about what cb1 said about signal bleed and dependence on frequency (cb1 - I would be interested if you disagree with anything below):

With an ideal signal driver, the sampling rate should not matter; even with minimum acquisition window, the ADC is designed such that the RC time constant of the internal sampling circuit will allow the capacitor to charge to within 0.5LSBs of the final value during the minimum acquisition window.  

Things get more interesting when the signal source impedance is not perfect.  In this case, the difference between the actual signal value and the sampling capacitor's final value may not be below the quantization threshold of the ADC, so some error is introduced based on the previously converted signal level. The farther apart the previous signal level and the current signal level, the more potential error.  This can be mitigated, as cb1 pointed out, by avoiding sampling two signals back-to-back if they may have very different signal levels. Failing that, setting the conversion order such that critical signals follow quiet signals and low priority signals follow rail-to-rail signals may help.     

One other way this can be mitigated is by increasing the acquisition window, which in some sense decreases the sample rate.  Each sample takes longer to process, so the maximum possible sampling rate is reduced (for this device, it will start to get lower than the 4.6MSPS max rate that Adam quotes above). However, the scan rate should be unaffected (the 100-200 kHz number from above) and it shouldn't determine if the issue occurs (unless it does something like mask signal swings in the other input, if they are synchronous).  

Another way to mitigate the issue is to add an external capacitor to the ADC channel.  This allows the external capacitor to charge through the source impedance at the scan rate   - giving something like 1/100kHz = 10us to charge, vs the acquisition window duration which could be as low as 7 ADCCLKS = 0.166us. As long as the external capacitor is sufficiently larger than the internal capacitor, the charge transfer from external to internal cap happens mostly independently of the source impedance.

A final way to mitigate the issue is to sample ground in-between each conversion.  In this way, since the sampling capacitor will always start near ground, any errors due to excessive source impedance or insufficient acquisition window duration will show up as signal attenuation and not bleed from the previous signal.  Some TI ADCs actually have a mode where the sampling capacitor is discharged in-between conversions (at a cost of a somewhat reduced maximum sampling rate).

Fanx,

One other thing to look at for debug is the initial conversion erratum.  If you are running at 60MHz, not throwing away the first conversion from each scan can cause some strange behavior in that first conversion.    

@Devin:

Believe yours is a most excellent - fully on topic - instructive writing.  Great job - you really have (imho) covered all of the key points. 

Again - our group notes this, apparent ADC "cross-talk, bleed issue" - across multiple vendors' ARM M3's, M4's & earlier ARM7's.  As you now - and my earlier post note - issue really is the internal sampling C w/in the MCU.  And we've never found an M3 or M4 which could meet their listed sample rate and avoid signal bleed.  (across multiple ARM MCU vendors!)  Thus - we've developed strategies similar to those you list - creativity in the managing of the ADC (never/ever even "hinted" @ in any MCU manual we've seen) may yield greatly improved ADC conversion accuracy. 

The external capacitor - introduced prior to the MCU's ADC input is inviting.  But - most often it serves to limit the dynamic responsiveness of the analog signal external to the MCU!  Thus - we've likely moved the error source/response location - possibly more than really improving. 

Might it be that the single internal ADC capacitor - "shared" among multiple MCU ADC channels - is the real issue?  Answer likely lies in the internals of "serious," dedicated, ADC chips - and their methods to achieve high accuracy @ speed.  (doubt we'll find single C charged for such job - therein)

And - if we, "start/sample from ground" - and our very next channel is at/around ADC max input V - might the admitted "signal attenuation" be very much, "signal bleed" - but rebranded?  (I mean - renamed {apologies to imaginatively conceived tiva})

The mixed signal capability of today's MCUs is best yet - but cannot reach the speed, accuracy and isolation benefits provided by a dedicated ADC chip...

@cb1

Sure, an external capacitor can admittedly cause issues too, since it is effectively a low pass filter.

Yes, the attenuation from sampling ground is exactly the same signal bleed. This is trading attenuation for less noise (assuming the bleed from the previous signal looks like noise to the new signal).

I agree that accuracy definitely isn't the advantage of integrated ADCs.  The main advantages are cost (The whole Piccolo MCU is similarly priced to standalone >4MSPS 12-bit ADCs), sample-to-output latency (once the conversion is complete, the results are memory mapped with no additional latency - no need to transfer via some communications interface), and simplicity (less ICs on the PCB, plus its easier to interact with on-chip memory-mapped peripheral than through some external communications interface).  

It was very interesting...

But there are times when all the problems are solved by correct grounding scheme...

Igor

Igor Gorbachev said:

Are times when - all the problems are solved by correct grounding scheme

But not this time - and not this problem!  Best grounding in the world will not solve single capacitor's ability to charge/discharge - @ too rapid rate! 

Grounding - while indeed vital - plays little part in this issue.  Thus assertion that all problems solved - via grounding - is severe over-reach...

Sampling w/test signal at the extremes of ADC input is not, "normal/customary."  It is likely that the ADC will saturate - thus limiting the max value you'll record @ 3V3 and the min value @ ground.  Mid range voltage test - with some attempt to match your voltage source impedance to ADC's specified input impedance - is far more, "text-book."

If you've read "back/forth" vendor fellow and myself - different results from different channels is not ridiculous.  Much depends upon the treatment of other ADC inputs - as those likely "bleed" into your channel of interest. And "floating" ADC inputs (unless anticipated by MCU design team) may degrade other channels.

Human implantation - or Space Shuttle use (RIP shuttle) not in the cards for any MCU based ADC.  While the marketing department claims 12 bits - real world measurement will be hard put to avoid "bounce" w/in 2, and sometimes even 3, least significant ADC bits.  Again - ADC w/in any MCU is compromise at best - you may wish to adjust your expectations to better match real-world - engineering reality. High performance ADCs are available from this vendor/others - far better designed & equipped as they're designed for very focused, singular purpose.  (which is not the case w/"kitchen sink" school of MCU design...)

Fanx,

Just to confirm, the way you are sampling looks something like:

*running at 60MHz, using internal reference, sampling with ACQPS = 6
*ePWM creates a trigger at a rate around 1kHz
*for each trigger, SOC0 and SOC1 are triggered (and maybe some more SOCs)
*Once all SOCs are finished converting, SOC1 is moved to an array and SOC0 is discarded because of erratum (SOCs greater than 1 may also be saved)
*Once sufficient samples of SOC1 are moved into the array, they are plotted in above graphs

And the results you are getting are summarized as:

First event (I am not clear on what the difference between events is)

ADCINA4 connected to analog ground via wire; DC codespread = 6, offset = 31
ADCINA2 connected to VDDA?; DC codespread = 1 (saturated ADC)
ADCINA4 connected to DC power supply; DC codespread = 80 (major spurs), center = 1895
ADCINA2 connected to DC power supply; DC codespread = 70 (major spurs), center = 1895

Second event

ADCINA4 connected to analog ground via wire; DC codespread = 7, offset = 38
ADCINA2 connected to VDDA?; DC codespread = 1 (saturated ADC)
ADCINA4 connected to DC power supply; DC codespread = 25 (minor spurs), center = 1890
ADCINA2 connected to DC power supply; DC codespread = 25 (minor spurs), center = 1895

Third event

ADCINA4 connected to analog ground via wire; DC codespread = 8, offset = 21
ADCINA2 connected to VDDA?; DC codespread = 1 (saturated ADC)
ADCINA4 connected to DC power supply; DC codespread = 20 (very noisy), center = 1885
ADCINA2 connected to DC power supply; DC codespread = 20 (very noisy), center = 1895

Additional experiment

ADCINA4 connected to analog ground; DC codespread = 14 (some spurs), offset = 9
ADCINA4 connected to VDDA; DC codespread = 1 (saturated), center > 4095
ADCINA1 connected to analog ground; DC codespread = 1 (saturated), offset < 0
ADCINA1 connected to VDDA; DC codespread = 18, center = 4088

The concerns are:

(1) the large DC code spread, especially for the DC power supply
(2) changing events seems to change the results
(3) different channels seem to have different offsets

Some thoughts (once you confirm above, we can probably do some additional debug)

(1) The code spread of 6-8 LSBs for VDDA and analog ground aren't too surprising. Usually the signals are a bit noisy, which is OK for the ADC performance (the ADC will have some power supply rejection).  The codespread of 14-18 is a little worrying, but I haven't ever used the particular board you have; this may be OK.

The code spread of 20-25 or more with spurs for the DC power supply is also actually not surprising.  DC power supplies tend to be a bit noisy, they aren't designed as precision source.  In the past, I have seen pretty similar things using an Agilent E3631A. What instrument are you using?  A better choice would be a function generator (set to DC, or a small amplitude sine wave).  I typically use something like an Agilent 33522A.

If you use a function generator, precision DAC, or precision DC reference, plus an OP-amp with a little bit of low-pass filtering, you should be able to get a codespread of 3-4LSBs.

(2) The closest thing I have seen to this have been related to the first sample erratum. 
(3) This is pretty strange and may require additional debug.  We spec' a channel-to-channel offset error of +/-4LSB in the datasheet, and I am pretty confident that devices should always conform to this.

Fanx,

Depending on what particular instrument you are using, I think it may be possible that the codespread is caused by the instrument; it appears as if you see the worst codespread when using that source.  Can you confirm what source you are using?  Do you have something more like a function generator, DAC, or precision DC source?

I know you mentioned it was an OLIMEX development board, but can you let me know exactly what board it is so I can hunt down the schematics and layout?

I don't suspect that the ePWM itself is causing any issues, unless you are driving the ePWM to a pin, and then to some high-power FETs or something? More likely changing the ePWM rate changes the timing between samples, which is causing some issue.  You could try triggering at the same rate, but use a CPU timer instead to confirm this.