I am struggling to understand why our AD7276 fails to resolve data ending in 010 or 101.
AD7276 (6 pin version)
Host processor: Atmel SAMG55 J19
Host firmware: Atmel ASF 3, SPI through DMA
In the examples below, we ran a 0.5 to 3.0V DC ramp into the ADC input at 0.01Hz.
We sampled 100,000 rows of data, with the ADC SPI clock running at 10MHz,
Each sample consists of 14 consecutive ADC conversions.
The purpose of the above setup was to make certain that, for a given input, we have reliable conversions, as the AD7276 used in our pulse-height-measuring instrumentation reportedly has missing, or highly-attenuated data within a given 14-conversion read sequence.
We have been able to reproduce this artifact and it is illustrated below.
Figure 1 is a screen shot of our analysis chart. It clearly points out the missing conversions.
Figure 2 shows that as we enter a lower ADC input voltage region, the number of missing conversions reduces
Figure 3 shows a fairly solid appearance, but there are still missing conversions and these appear within the 010 and 101 endings.
These diagrams were produced by populating each of the 14 reads (from an array) into the appropriate binary code (row). The number in each of the 14 columns is the number of "hits" (raw data conversions) reported.
Figure 1: missing code analysis. 2.86 to 2.91 volts. Black areas represent binary states in which no data was registered.
Columns (l-r) missing count, binary, decimal, volts, reads 1-14.
Figure 2. 1.72 to 1.77V. The number of missing rows reduces, however we can see a "spillover" effect to adjacent binary conversions.
Figure 3. 0.16 to 0.20V. A few rows highlighted for emphasis. We note that the 010 and 101 codes are still bothered, in that these are almost always greater in hit count than adjacent binary conversions.
I've examined everything we can think of within our immediate control. This includes the SPI bus, the SPI setup, and settings in the SPI driver which allow us to change (a) DELAYBS, the delay from CS going low to the start of the SPI clock (from high to low), (b) DELAYBCS, the delay between each CS (controls the data rate by pausing between each CS), and DELAYBCT, which is a delay between consecutive transfers. All timing measures well within specifications.
We definitely do not believe this is a problem in the device, but rather a problem either in our driver or hardware setup.
Seeking ideas, comments, critique, ect.
Thank you all.
[edited by: @skowalik at 3:55 PM (GMT 0) on 21 Nov 2019]