ADS8568: Missing codes when device is cooled

Hi Robert,

Thanks for your post and welcome to our forum.

The "no missing codes" resolution is a minimum spec that we guarantee through our final test program and that spec is valid across the entire operating temperature range. Do you have access to the raw codes directly from the ADC output that you can share in an Excel file?

Best regards,

Gee, Ryan, thanks for answering. Are you familiar with imaging technology using ADCs and CCD and CMOS sensors?

Our company supplies state of the art imaging equipment to astronomers, physicists, medical researchers, and pretty much any scientist who is involved in state of the art photonics. And has done so for over 20 years.

I am well aware of the specs on your ADC. But trust me, we can image single photons. When I tell you you have missing codes when your devices are cooled, it is something you can count on. Wish we could "count" on yours.

We just replaced another failed ADC on an instrument for one of our national lab customers. This is really annoying. We had to break the vacuum on it, hack off the ADC and solder in another. That requires another week of pump and bake to get the instrument shippable.

Do you sample test these parts below room temperature before shipping them? Perhaps you could put us in touch with a Quality representative who can detail your low temperature testing regime. That would be appreciated. Have a nice day.

Hi Robert,

Thanks for the background, I do understand how frustrating and time consuming it can be to handle customer returns. Providing some raw data will allow us to dig through our characterization backlog and possibly make some comparisons to understand the root cause. We can also show this to our Quality team and discuss any historical or existing returns for similar issues.

In addition to raw data that shows the missing codes, could you also specify which device package you are using?

The DNL for the 16-bit variant of this device is significantly larger than the other two. It's very possible that the combination of these error terms causes the width of some codes (i.e. the input voltage range which produces them) to be longer or shorter than others. This can be especially true at multiples of 4 or 8 near what are known as "byte boundaries". 

Could you provide some histogram data for the same dark image test at -25 C and 0 C?

Regards,

Thanks for your understanding.

We are using the 64 pin LQFP package. We use two per sensor.

I have histograms from one channel of each device at 20C, 0C, -10C and -20C. I also have a histogram of the failing ADC channel at -20C that comes from subtracting two images taken a few seconds apart. This histogram is normal, and shows that whatever is screwy in the part is at least consistently so.

You will notice that down to 0C both devices, while not exactly generating smooth histograms and showing some issues, do not obviously merge adjacent codes into one code.

The good device never does, but at -10C the bad device merges three codes into one, the correct code and the next two every 16 counts.

This is the first time we've seen a device do this on 16 counts, all bad devices we saw before (maybe 10 devices) showed this behavior on 8 counts.

Device #1 (good ADC) @ +20C

Zoomed section of above:

Device #2 (bad device) at +20C

Zoom of above

Device #1 (good device) @ 0C

Zoom of above

Device #2 (bad device) @ 0C

Zoom of above

Device #1 (good device) @ -10C

Zoom of above

Device #2 (bad device) @ -10C

Zoom of above

Device #1 (good device) @ -20C

Zoom of above

Device #2 (bad device) @ -20C

Zoom of above

And finally Device # 2 (bad device) @ -20C. Two images taken seconds apart and then  the second subtracted from the first. This is the histogram of the difference.

Hi Robert,

Please excuse the delay, we have had a couple internal discussions about the possible causes of this issue.

I did have the chance to talk with our Quality team, but we did not find anything related to this issue in the device's quality return history.

I believe the root cause to be the DNL of the ADS8568, producing wider or shorter codes and possibly shifting one way or the other over temp. Would you consider dropping down to the 14-bit variant (ADS8548), which has significantly better DNL? This would be the only pin-for-pin compatible option. By averaging back-to-back samples, you could improve the resolution of the measured results as the cost of sacrificing overall sample throughput.

Let me know your thoughts on an alternative approach.

Best regards,

Well, while the specs are better in terms of LSBs, the 14 bit converter is actually a little worse than the 16 bit converter divided by 4.

We have in the past used multiple converters in parallel to increase precision, but sensors can only be read once.

Our current plan is to test every device at temperature in a socket before putting it on a circuit board. Those that show the 2 code substitution will be scrapped, or returned. We estimate that over the past several years about half the parts we bought were scrapped. Perhaps we'll find a lucky date code or your recipe will improve...