TMS320F2812: ADC noise floor in 4-5 bit range

Ray,

When the customer states 4-5 bits or 3 bits, I assume they mean 2^4-2^5 or 16 to 32 LSBs/codes of variation vs 2^3 or 8 codes of variation under the different scenarios above.  Let me know if this is incorrect, but will work on that for now.

I think in the scenario of ACQPS = 15 and 8 codes of variation is getting to something reasonable for this ADC; I'd want to understand the standard deviation of the 8 codes a bit more.  They should be seeing a std deviation on the order of 0.9LSB or lower.  If the std deviation is higher than this then the signal is still limiting the noise floor vs the ADC.

I'd also like to verify how the customer is setting up the ADC to get sequential samples; are they converting more than one signal on each ADC trigger(SOC).  i.e. MAXCONV >0?  Many times the issue with noise is that the ADC's sample and hold cap can't charge to the external value in time on the first sample from idle.  This is where increasing the ACQPS will help, as it give the sample and hold cap longer to charge and match the external voltage.  We can also try to sample the same channel back to back using MAXCONV to keep settling the sample and hold cap.

For instance let's set the MAXCONV = 3(which should do 4 samples).  Ask the customer to only take the 4th sample from each SOC and see if this improves the distribution.  If that's the case then we are still dealing with the input signal limiting the SNR/code spread.

Due to the nature of the eZDSP using pin headers to connect the voltage, we also need to limit the physical distance from the source as much as possible.  The customer may find it necessary to place some small capacitance to help buffer the signal which will improve noise.

Here is a link to a newer app note discussing proper driving of the ADC input,  this will help derive the best balance of the above settings.

Best,

Matthew

Hi Matthew,

Good Day. Please see below the feedback of our customer to your last response. Thank you very much.

When the customer states 4-5 bits or 3 bits, I assume they mean 2^4-2^5 or 16 to 32 LSBs/codes of variation vs 2^3 or 8 codes of variation under the different scenarios above. Let me know if this is incorrect, but will work on that for now.

Mark – Yes, this is the correct assumption.  When I mention 3 bits, I mean 3^2 or 8 LSB as mentioned in the example.

I think in the scenario of ACQPS = 15 and 8 codes of variation is getting to something reasonable for this ADC; I'd want to understand the standard deviation of the 8 codes a bit more. They should be seeing a std deviation on the order of 0.9LSB or lower. If the std deviation is higher than this then the signal is still limiting the noise floor vs the ADC.

Mark – confirming seeing much higher than 0.9 LSB. I was expecting a performance to be less than <4 LSB but seeing much higher in the 60 LSB realm.

I'd also like to verify how the customer is setting up the ADC to get sequential samples; are they converting more than one signal on each ADC trigger(SOC). i.e. MAXCONV >0? Many times the issue with noise is that the ADC's sample and hold cap can't charge to the external value in time on the first sample from idle. This is where increasing the ACQPS will help, as it give the sample and hold cap longer to charge and match the external voltage. We can also try to sample the same channel back to back using MAXCONV to keep settling the sample and hold cap.

Mark – MAXCONV = 0.  Reading the same ADC channel continuously using CONT_RUN.  Reading 114 samples of the same ADC channel and randomly distributed.  Some side questions as a result

• Is it beneficial to set MAXCONV > 0 and use SEQ to read the same channel multiple times?  If yes, this leads to a secondary question.  My application is sensitive to timing.  How can I use MAXCONV > 0 while being able to time accurately read in the sequence?
• If sample and hold cap is taking a “while” to charge, is there anything that can be done on the external electrical circuit to reduce S&H time?

For instance let's set the MAXCONV = 3(which should do 4 samples). Ask the customer to only take the 4th sample from each SOC and see if this improves the distribution. If that's the case then we are still dealing with the input signal limiting the SNR/code spread.

Mark - MAXCONV = 0.  Application does not take advantage of sequencing capability.  Application is to digitizing a 10-us window at > 10MSPS. Time accuracy of acquisition is critical.  Currently the ADC is running at 11.25 MSPS (PLL of 45 MHZ).  Bumping the acquisition rate to 22.5 MSPS is an option for averaging or to read every other acquisition, I’ve read guidance is to keep ADC < 18MSPS to limit noise.

Due to the nature of the eZDSP using pin headers to connect the voltage, we also need to limit the physical distance from the source as much as possible. The customer may find it necessary to place some small capacitance to help buffer the signal which will improve noise.

Mark – reference and signal lengths have been minimized, although adding a small capacitor can be added as a extra layer of noise suppression. I’m using the ezDSP to crosscheck target hardware design which I expected to have a better then performance.  First cut target hardware for integration is receiving comparable performance to the ezDSP. Sequence of event is as follows setting up for acquisition:

                SEQ 1.bit.CONV00 is set to the channel desired

                CONT_RUN is set to 1

                RST_SEQ1 and SOC_SEQ1 is set to 1

                Delay of 1 us

Two assembly instructions to grab data from ADC and save to memory repeated continuously for 10 us.

Here is a link to a newer app note discussing proper driving of the ADC input (https://www.ti.com/an/spracv0), this will help derive the best balance of the above settings.

Mark – the provided link does not work.  I receive a Error 404 not found.

Best Regards,

Ray Vincent

Ray,

Here is the corrected link for the app note

Since the customer is using CONTRUN this resolves my concern about mutli-sampling.  If there were cap charging issues that would resolve itself with the initial sample and not be present through the remaining samples.

I would suggest the following:

For the eZDSP let's make sure that the the jumper from ADCLO to VSSA is present, I think the data would be much worse if it was not, but want to make sure of this.

I would also recommend disabling XCLKOUT, by setting bit 3 high in the XINTCNF2 register.  This is enabled at reset and can add noise to the system.

Can the customer also comment on the DC source that is being sampled?  Is it from a DAC, external generator, etc?  I'm looking for the expected accuracy of this source so we can level set the expectation on the ADC conversion.

Best,

Matthew

Hi Matthew,

Good Day. Please see below the latest response of our customer to your reply. Thank you very much.

Between the information in the app note and disabling XCLKOUT has helped in the accuracy of the ADC reads. That and the combination of rework has improved the performance within 3 bits (8 LSB) which is a big step forward. As for the ezDSP, I’m still having issues there. Unless you have an idea where the remaining noise source may be, the case can be closed. Thank you.

Best Regards,

Ray Vincent

Hi Matthew,

Good Day. Please see the latest response of our customer to your reply. Thank you very much.

Understand concern of relying on the ezDSP platform for development and noise.  The JTAG interface is not source of additional noise in case of my measurements as its all done off debugger where I queue all results to RAM and then output capture buffer over serial interface.

I read online some basic rules for best ADC performance such as keeping sample rate under 18 MSPS.  Are there ground rules of chip setup for lowest noise performance?

Best Regards,

Ray Vincent