Piccolo ADC accuracy/noise

Does the noise magnitude decrease substantially when you increase the number of cycles of sampling window settling time in the ADC configuration?

Does the noise magnitude decrease substantially when you reduce the ADC sampling frequency greatly?

Is the noise level worse when you're not sampling the temperature sensor but rather when you sample one of the external analog inputs? 

Does it matter if you measure an external signal differentially or single ended?

Does it matter if you measure a grounded ADC input or an ADC input tied to one of the power supply rails (1.8 or 3.3V) -- of course via a short physical connection?

Does the noise correlate with power supply ripple / noise on one of the chip's power supply rails?  Would adding more heavy power supply bypass capacitors help?

What is the frequency spectrum of the noise?  Is it random white noise?  Lots of energy at particular frequencies that may relate to the SMPS regulator operation on the card?

When increasing the number of cycles of sampling window settling time in the ADC configuration, the noise magnitude does not decrease; in the CCS graph, it even seems to increase.

There is no change when reducing the ADC sampling frequency.

There is no change when reducing the low speed clock frequency.

The noise level is worse when sampling one of the external analog inputs.

I have not measured differentially - this is no option since we need all ADC channels in our planned design.

Again: I am working on the bare F28035 Piccolo controlcard designed by TI, so I would expect no ideal, but fairly representative results.

So are you or somebody else working with the Piccolo ADC and experiencing the same noisy results?

I would not really bother about static gain and offset error since this reduces the ADC range, but can be calibrated.

This noise is really annoying since it requires sample-by-sample corrections like oversampling or additional software filtering.

Followe-Up:

When measuring the grounded ADC input on B5 (AdcRegs.ADCCTL1.bit.VREFLOCONV = 1), the noise is more or less the same, still approx. 15 digits, sometimes even more (up to 30 digits).

I can see how this level of AC ADC noise equal to 15 LSBs in a "best case scenario" would be a bit disconcerting since that is almost 4 bits out of the theoretical 12 bits; half of that noise level I would have fully expected in the real world without question, but the amount you are seeing does seem on the high side for a well laid out system.  Seeing 30 LSBs of AC error with a static signal as your new message indicates is truly a matter of concern in my opinion.

I don't have a theory/explanation of the nature of the problem.  I have been wondering how noisy the control card or other real world implementation's ADC channels would be.  Thanks for sharing your results.  I plan to be doing control card based R&D soon as well, but as of the moment I don't have the hardware to duplicate your results and share any local data.

* You might double check the source code of the sampling example code; it could be possible there is a subtle bug in there somewhere.  If a conversion channel multiplex / mode / timing setting was incorrect or a conversion was terminated prematurely that could cause the kind of problems you're seeing.  It is "almost" working right, except for the last few LSBs of settling.

* ESD degradation or a slightly defective device could cause such problems, but it wouldn't be my first guess, and isn't likely if you've tested more than one control card, especially if you've used one of the TI dock boards to attain the same results as your custom baseboard generates.

* EMI is always a concern, but that should not so much affect the sampling of internal channels like the temperature sensor or vreflo.  If you are using an external voltage reference that may be a source of noise or EMI susceptability depending on the layout.  Actually maybe it is not even possible / sane to use an external vref given the nature of the control card schematic and layout; I'd have to look at the schematic for it again to see.

* Power supply noise and bad PSRR noise rejection will cause some noise, but I wouldn't think it would be the amount of 15-30 LSBs unless something is quite wrong.

* The data sheet indicates that the first 1ms of ADC results after power-on are possibly meaningless:

td(PWD) Delay time for the ADC to be stable after power up 1 ms

* According to the ADC user's guide it is possible to sample VREFLO on Channel B5 single ended as another option -- maybe this would be a good test also:

VREFLOCONV   VREFLO Convert.
             When enabled, internally connects VREFLO to the ADC channel B5 and disconnects the ADCINB5 pin
             from the ADC. Whether the pin ADCINB5 exists on the device does not affect this function. Any external
             circuitry on the ADCINB5 pin is unaffected by this mode.
           0 ADCINB5 is passed to the ADC module as normal, VREFLO connection to ADCINB5 is disabled
           1 VREFLO internally connected to the ADC for sampling

* Some other C2000 parts I've been looking at have ADC errata listed relating to simultaneous sampling of channel pairs generating incorrect results for the first pair of results in a given conversion sequence. Though the '035 errata doesn't list that problem, it could be worth checking.  Similarly I'd investigate possible spill over cross-family errata of any other sorts relating to the ADC if you're having inexplicable problems.

* There is the following errata listed for the ADC, which I assume you're already accounting for.

Advisory             ADC: Initial Conversion
                     0
Revision(s) Affected
                     When the ADC conversions are initiated by any source of trigger, the first sample may
Details
                     not be the correct conversion result.
                     Discard the first sample at the beginning of every series of conversions. For instance, if
Workaround(s)
                     the application calls for a given series of conversions, SOC0→SOC1→SOC2, to initiate
                     periodically, then setup the series instead as SOC0→SOC1→SOC2→SOC3 and only
                     use the last three conversions, ADCRESULT1, ADCRESULT2, ADCRESULT3, thereby
                     discarding ADCRESULT0.
                     Each application should validate this as acceptable in their application.

It looks like SW3 on the control card lets you pick an internal or external voltage reference.

It might be worthwhile to firmly toggle that switch a few times across both positions to help ensure that any contamination of the contacts is removed and that a solid connection is being made.  If the reference still looks noisy you might try switching between the internal and an external one to see if the change improves anything.

I assume that your baseboard has each of the DIMM's +5V and GND contacts connected in parallel to a good solid power / ground net which is reasonably well designed for signal integrity.

You could write some code so that it executes without the PC being connected to RS232 / JTAG and it will simply take a moving window of the most recent hundred ADC samples and blink the control card LED it the variance between the high and low samples exceeds 10 LSBs or something like that, just to help eliminate EMI contributions from the PC or serial port system or JTAG.

Thanks for your detailed reply!

The initial conversion errata was a good tip - I did not take this into account.

Now when evaluating the second result and throwing away the first one, I get 5 digits variation when sampling VREFLO on Channel B5 single ended and 10 digits variation when sampling the internal temp sensor to channel ADCINA5.

Both at ACQPS=6; when setting it to max(63), it gets worse (really strange!).

So this is better although still not good.

I will try to evaluate and possibly reduce the noise further; any additional hints and Piccolo ADC experience is welcome!

Stephan,

By using the temperature sensor to measure the DC code spread (or digital variation), you are measuring the variation of both the ADC and temperature sensor output, instead of ADC output only. Since the temperature sensor will vary with junction temperature changes while running code, it should not be used to measure the ADC DC code spread. The VREFLO internal connection is a better choice over the temperature sensor.

To test it properly for best results, I would suggest using an accurate external VREF such as REF3225 as well as a low-pass filter to eliminate any high frequency noise causing the lower LSB bits to toggle.

Also, regardless of the method used, make sure to disconnect the JTAG emulator pod while observing the DC code spread as it can add noise to your system and affect the ADC DC code spread.

Regards,

Nicholas Smith

Nicholas,

okay, when using the internal temperature sensor, I measure the noise of the ADC and the temp-sensor.
I don't think I measure the variation of the junction temperature when measuring only a few seconds and also observing the result via CCS graph - junction temperature will slowly rise, but the temperature itself should not vary on a sample-by-sample basis.

I have tried to measure an external VREF, but the free-wire connection to the controlboard had too much noise. I will have to wait for a self-designed board and measure again.

Of course I can disconnect the JTag emulator pod for the measurement since it can add noise, but at least for the internal VREFLO and temperature sensor measurement, the Piccolo ADC design should be immune against such influence!?
It's hard to imagine what the ADC will do in a later real power-design if it is sensitive to JTag emulator pod noise when measuring completely internal VREFLO or temperature sensor...

What makes me wonder is that until now, there was no answer like "there must be an error in your measurement - I am observing a noise of only 1..2 digits for the Piccolo ADC here"....

Stephan,

Can you comment further on the 5 digits of variation when measuring VREFLO?  Is the variation Gaussian in nature or more box car shape; i.e. is the variation random noise or more deterministic?  The standard deviation of the data is important here, I would like to see 0.5LSBs - 0.7LSBs for this data. 

At this level of resolution there will be some amount of thermal noise that will show up in the conversions, but it should be gauss in nature; just trying see if that is what is giving you the spread or some other non-Gauss noise source.

Best,

Matthew

Okay, I made the test for the ADC Example, with VREFLO internally connected to channel ADCINB5, with an OFFTRIM value of 80 to see the negative values.

I recorded an array of 1000 values and summed them up in Excel with the following result:

This looks not really Gaussian, but somehow. Is this result what you would expect, Matthew?

Regards,

Stephan

Stephan,

I met the same problem when using F28035. The ADC accuracy exceeds the specification declared in data sheet of TMS320F28035(section 6.11.11). I got 10 digits variation or more also (in best cases). By using the experiment board came from TI and the target PCB designed by myself, the input signals are both internal temp sensor and a stable DC reference, I got the same results.

I wonder how to get rid of the noise of AD channel? Is it exist in normal?

I knew the noise is existed in F2812 always. Maybe it's one of bugs in F2812. At least it's difficult or uneconomical  to overcome the noise of ADC in F2812 within a general design. While in F2808, I can get a satisfaied accuracy of ADC. It's just has 3~4 digits variation in general design. F28035, as a new and a update DSC, its performance of ADC in accuracy is poor.

Does anyone get a better performance of ADC in F28035?

dear;

i need to ask about the ADC of 28035 in simulink? how can i determine Input Channels — Conversion channe and SOCx acquisition window? 

i use it with hvkit and in source code 

// Initialize ADC for DMC Kit Rev 1.1
ChSel[0]=1; // Dummy meas. avoid 1st sample issue Rev0 Picollo*/
ChSel[1]=1; // ChSelect: ADC A1-> Phase A Current
ChSel[2]=9; // ChSelect: ADC B1-> Phase B Current
ChSel[3]=3; // ChSelect: ADC A3-> Phase C Current
ChSel[4]=15; // ChSelect: ADC B7-> Phase A Voltage
ChSel[5]=14; // ChSelect: ADC B6-> Phase B Voltage
ChSel[6]=12; // ChSelect: ADC B4-> Phase C Voltage
ChSel[7]=7; // ChSelect: ADC A7-> DC Bus Voltage

and 

/******* CHANNEL SELECT *******/ \
\
AdcRegs.ADCSOC0CTL.bit.CHSEL = ChSel[0]; \
AdcRegs.ADCSOC1CTL.bit.CHSEL = ChSel[1]; \
AdcRegs.ADCSOC2CTL.bit.CHSEL = ChSel[2]; \
AdcRegs.ADCSOC3CTL.bit.CHSEL = ChSel[3]; \
AdcRegs.ADCSOC4CTL.bit.CHSEL = ChSel[4]; \
AdcRegs.ADCSOC5CTL.bit.CHSEL = ChSel[5]; \
AdcRegs.ADCSOC6CTL.bit.CHSEL = ChSel[6]; \
AdcRegs.ADCSOC7CTL.bit.CHSEL = ChSel[7]; \
AdcRegs.ADCSOC8CTL.bit.CHSEL = ChSel[8]; \
AdcRegs.ADCSOC9CTL.bit.CHSEL = ChSel[9]; \
AdcRegs.ADCSOC10CTL.bit.CHSEL = ChSel[10]; \
AdcRegs.ADCSOC11CTL.bit.CHSEL = ChSel[11]; \
AdcRegs.ADCSOC12CTL.bit.CHSEL = ChSel[12]; \
AdcRegs.ADCSOC13CTL.bit.CHSEL = ChSel[13]; \
AdcRegs.ADCSOC14CTL.bit.CHSEL = ChSel[14]; \
AdcRegs.ADCSOC15CTL.bit.CHSEL = ChSel[15]; \

thanks

i need the channel for read the phases currents?!!!!!! ADCINA0 to ADCINB7????

thanks