Hi all,

I'm currently working on a project where I have an image sensor which reads off the voltages associated with the pixels at a rate of 50 MHz when triggered. I have a CPLD to control the timings of this part of the circuit and send a stream of pixels to an ADC which I need to run at a bit depth of 16 bits.

I've picked out a nice TI ADC (http://www.ti.com/lit/ds/symlink/ads5562.pdf) Which can run at up to 80 MS/s and 16 bits. So far so good! This chip outputs the data in parallel LVDS (16 individual channels multiplexed) and I'd like now like to get this data off the board and into my PC for real time processing.

In less high performance applications I've seen USB interface chips used which come with a .dll driver on the PC end to grab the data, but I'm not sure If I can use this here, albeit my data rate of 800 Mb/s is well within USB 3 capabilities.

My understanding is that I need to serialise the data to send it over USB, and I've found this chip (http://www.ti.com/lit/ds/symlink/ds92lx1622.pdf) which appears to serialise 16 channels of data at 50MHz.

Is it possible to just send the data output from that serialiser to a USB interface chip?

Alternatively, if anyone has any better ideas for how I could get this data over to the PC, I'd be very glad to hear it! I'm relatively new to this side of the electronics.

Cheers,

Matt

 

Welcome to AAC!

You have a lot of technical challenges facing you. Read the datasheet carefully to understand these challenges.

1) The ADC input is differential.
2) The clock input is differential.
3) The PCB layout of any circuit of this nature is extremely critical.

It would seem to me that this calls for an FPGA solution or a fast MCU. With such a solution you can capture the entire image and then transfer it to a PC via a USB interface.

What is the image size in width x height in pixels?
Can you post a link to the image sensor?
Why are you not using a camera such as a USB camera?

 

Welcome to AAC!

You have a lot of technical challenges facing you. Read the datasheet carefully to understand these challenges.

1) The ADC input is differential.
2) The clock input is differential.
3) The PCB layout of any circuit of this nature is extremely critical.

It would seem to me that this calls for an FPGA solution or a fast MCU. With such a solution you can capture the entire image and then transfer it to a PC via a USB interface.

What is the image size in width x height in pixels?
Can you post a link to the image sensor?
Why are you not using a camera such as a USB camera?

Thanks for the warm welcome, much appreciated!

I was under the impression that differential inputs were what I wanted as this would cancel any noise aquired during the transmission to that component?

With regards PCB layout, do you mean organising it so that signal paths are perpendicular to power supply paths?

Ahhh I see, so use an FPGA to distribute the 16 parallel inputs into a buffer, and then some sort of USB interface chip which reads off each laser shot in 8 kbit (500 px * 16 bits) pulses?
I was planning on programming up an Intel MAX V CPLD to control the timings, but that's a relatively underutilised microprocessor, I guess I could get it to handle the buffer operation as well?

The sensor is a linear CMOS array (https://www.hamamatsu.com/resources/pdf/ssd/s11105_series_kmpd1111e.pdf). Note that the sensor is 512x1 pixels and at 50 MHz this results in a line rate of ~89 kHz. We need to run wtih a line rate of 100 kHZ (in order to sync with a broadband laser pulse which is delivered across the sensor with a 100 kHz rep rate) and the manufacture has onfirmed that you can run this sensor at 100 kHz and just lose the last 12 pixels by overwriting the shift registers before they're read out.

As far as USB cameras are concerned, the linescan cameras which run at this line rate all digitize at 12 bits maximum but with higher resolution. I did contact a variety of vendors to see about having a custom camera made but the only quote I got back was for a cool $1,000,000...

 

This is a top-level design challenge.
I would take a pause and really talk to some experts before embarking on this.

There are so many pitfalls for the unwary in this land of high-performance electronics.

Why do you think that the company was asking for a megabuck to do a camera design?
Because the guys that do this are very expensive, and it takes a lot of them, for a long time.

 

This is a top-level design challenge.
I would take a pause and really talk to some experts before embarking on this.

There are so many pitfalls for the unwary in this land of high-performance electronics.

Why do you think that the company was asking for a megabuck to do a camera design?
Because the guys that do this are very expensive, and it takes a lot of them, for a long time.

I appreciate the warning about the complexity of the challenge. This is part of my job though, so it's not optional if I want to keep paying my rent! I'm a postdoc at a university so it's common to be assigned a challenge which isn't in my direct field of interest (I'm a physicist/chemist by training).

I should add, my initial plan is to just feed the output of the linear array and feed into a relatively high end DAC PCI board (50MHz 16 bit runs abot $3.5k).

 

Ok! just so you understand it's not like fiddling with an Arduino and a bunch of kit boards.

I have been designing electronics for 30 years, I would be nervous about taking this project on myself.

Getting a fast 16 bit ADC to resolve the least significant bits is brutal, a casual approach to the layout will drown it in noise, making the 16 bits about 12. (A LSB is about 50 uV!)
You have the worst situation: fast digital combined with noise critical analog.
You really need to understand all the tricks of low-noise, high-speed design - ground planes, supply bypassing are all super critical to success.

Design mistakes set you back weeks and hundreds of dollars- re-spinning a PCB because it doesn't work, etc.

Ouch.

 

I am in nuclear physics and build gamma-ray spectrometers. I may be able to help you. I already have a high speed digitizer.
It would be interesting to know exactly what you are doing. If you prefer to keep your work confidential you can contact me via PM.

 

Your goals need to be clearly stated -

1) Required T & V stability and accuracy of power supplies.
2) Resolution required over T & V
3) Absolute or relative accuracy design
4) Sampling rate, latency

If you do a signal path error analysis, complete with noise, offsets (V and Ibias), PSRR, T, V
its very tough to do a 16 bit design to 1/2 LSB.

Its very instructive to do this, tedious, easiest method is convert all values to PPM or
LSB or some common measure so easy comparisons can be made.

Regards, Dana.

 

I am in nuclear physics and build gamma-ray spectrometers. I may be able to help you. I already have a high speed digitizer.
It would be interesting to know exactly what you are doing. If you prefer to keep your work confidential you can contact me via PM.

Ah brilliant, thanks for the offer! I'll give an overview here, I did try and PM you as well, but I couldn't find where to do that?

The broader project is that I'm working on ultrafast transient absorption spectroscopy to look at photochemistry. This involves using two laser pulses, one in the UV and one which is a broadband white light pulse. The UV pulse interacts with the sample and, after some time delay on the order of a few femtoseconds, the white light source interacts with it. The white light source is then dispersed in a prism or on a grating and then onto the linear array. Each pixel then represents the intensity of each wavelength. The signal is then digitized at as high a bit depth as possible and transferred to the computer.
In the next laser shot the UV pulse is blocked and only the white light pulse interacts ith the sample.

The crucual information is in the difference between the two pulses, and the differences are quite small due to a few limitations of the physics, hence why the accuracy of digitization is so important.

People have been doing this experiment at a 1 kHz laser rep rate for a number of years, but with new laser technology we'd like to do it at 100 kHz.

 

Sounds good. I will have to digest what you wrote and perhaps we can come up with a workable system.

 

I did this sort of stuff for a living. For the PC interface, I suggest looking here to get started:

https://www.visiononline.org/vision-standards.cfm

Over the years, the AIA interfaces have been a go to. The key words are "Camera Link". This has evolved over the years to keep up with PC architectural evolution. Check it out. You are in a rarefied atmosphere but seem up to the challenge.

If not imaging but just general high speed data acquisition, an sFPDP interface is the easiest to build in a custom interface to an off=the=shelf PC interface. Search "sFPDP".

https://www.intel.com/content/www/u...ologies-pvt--ltd-/ip/serial-fpdp--sfpdp-.html

 

I did this sort of stuff for a living. For the PC interface, I suggest looking here to get started:

https://www.visiononline.org/vision-standards.cfm

Over the years, the AIA interfaces have been a go to. The key words are "Camera Link". This has evolved over the years to keep up with PC architectural evolution. Check it out. You are in a rarefied atmosphere but seem up to the challenge.

If not imaging but just general high speed data acquisition, an sFPDP interface is the easiest to build in a custom interface to an off=the=shelf PC interface. Search "sFPDP".

https://www.intel.com/content/www/u...ologies-pvt--ltd-/ip/serial-fpdp--sfpdp-.html

I actually have a little bit of experience with the CameraLink standard from an end user standpoint. Mostly using the National Instruments Framegrabber to interface with a Linescan camera (12-bit). Seeing as I already have the NI Framegrabber available, it makes a lot of sense to extract the data over this interface. The framegrabber already accepts a TTL pulse in so synchronising it with the experiment should be a little easier.

Thanks for the sFPDP recommendation. I'll do some reading around this.

 

I did this sort of stuff for a living. For the PC interface, I suggest looking here to get started:

https://www.visiononline.org/vision-standards.cfm

Over the years, the AIA interfaces have been a go to. The key words are "Camera Link". This has evolved over the years to keep up with PC architectural evolution. Check it out. You are in a rarefied atmosphere but seem up to the challenge.

If not imaging but just general high speed data acquisition, an sFPDP interface is the easiest to build in a custom interface to an off=the=shelf PC interface. Search "sFPDP".

https://www.intel.com/content/www/u...ologies-pvt--ltd-/ip/serial-fpdp--sfpdp-.html

This was extremely helpful! I've read through the Standard specification for CameraLink and this looks rather perfect. It looks like I can run it at 50MHz and just set each 16 bit pixel one at a time with and only use 16 of the 24 available data bits. I realise this is quite an inefficient approach but it's simple and it allows me to stick with CL Base configuration.
There seem to be commercially available Channel Link I serialisers which will take in the 24 potential data bits and compress this into 4, 8 bit channels as dictated with the CameraLink standard. (Looking at this for example http://www.ti.com/lit/ds/symlink/ds90cr287.pdf)

However, this accepts single ended signals, while the ADCs that run with this precision and sample rate seem to, sensibly, output differential signals. Not only that, the ADC that I had picked out before also multiplexes the data so that the 16 bits are transmitted in pairs out of 8 differential output pins.
That's in LVDS mode of course, it is also capable of running in CMOS mode where it outputs 16 single ended bits.
The simplest approach would, I guess, be to run it in CMOS mode and feed it directly into the serialiser via a buffer but I may be missing some benefit of using the FPGA to disentangle the LVDS mode information.