High Speed data aquisition design

Thread Starter

pyroartist

Joined Oct 9, 2015
98
I'm trying to design a LIDAR receiver that will digitize the amplitude of returned light from a photodetector every 100 nanoseconds.
This circuit needs to store the digitized value in a buffer (on-chip if possible) very rapidly and then automatically take another reading within the next 100 ns. window. Total number of readings will not exceed 50 so the buffer could be small. Then the controlling processor (probably a Teensy 4.0 @ 600 MHz.) will read and clear the buffer and store the values for processing later. The problem is the internal A/D on the Teensy is only good for 1 MSPS.
My question is does anyone know of a fast A/D that can internally store readings? Resolution should be 8 to 12 bits and speed about 20 million samples per second or better. If there is no such A/D maybe there is a better way to achieve the same result. Or does anyone have a link for an A/D evaluation website? I could just start visiting many manufacturers websites to see if they even make fast A/Ds with buffers but I thought I would ask here first in case someone was familiar with them. It would be nice if the A/D was available in a DIP package so I could use it in a breadboard. Thanks!
 
Last edited:

crutschow

Joined Mar 14, 2008
27,188
Don't know of specific devices.
Try the Analog Devices or Texas Instruments websites.
Google may turn up other sources.
 

andrewmm

Joined Feb 25, 2011
1,464
I'm trying to design a LIDAR receiver that will digitize the amplitude of returned light from a photodetector every 100 nanoseconds.
This circuit needs to store the digitized value in a buffer (on-chip if possible) very rapidly and then automatically take another reading within the next 100 ns. window. Total number of readings will not exceed 50 so the buffer could be small. Then the controlling processor (probably a Teensy 4.0 @ 600 MHz.) will read and clear the buffer and store the values for processing later. The problem is the internal A/D on the Teensy is only good for 1 MSPS.
My question is does anyone know of a fast A/D that can internally store readings? Resolution should be 8 to 12 bits and speed about 20 million samples per second or better. If there is no such A/D maybe there is a better way to achieve the same result. Or does anyone have a link for an A/D evaluation website? I could just start visiting many manufacturers websites to see if they even make fast A/Ds with buffers but I thought I would ask here first in case someone was familiar with them. It would be nice if the A/D was available in a DIP package so I could use it in a breadboard. Thanks!
typically, ADC's don't store data internally
An ADC is a complex, sensitive device, classically , the designers do all they can to get as little digital on the silicon that they can.

Your only sampling at 10 MHz,
That's not to fast, how many bits do you think you will need ( what SNR )
remember the clock to the ADC needs to be stable, you can't take constant samples using a clock out of the Arduino.
unless you only have very few bits.

Also remember , you need an anti alias filter on the ADC input. if your sampling at 10 MHz, thats going to be around 3 Mhz
 

Thread Starter

pyroartist

Joined Oct 9, 2015
98
I have not heard of an anti-alias filter on the input. What is the purpose of that if the input is DC?
I have seen somehwere an A/D with a small FIFO memory inside it so I thought that it might be more common.
I will probably want a 10 or 12 bit resolution.
 

MrChips

Joined Oct 2, 2009
23,515
Finding a fast ADC is half the battle. Finding an MCU that can interface with the ADC and acquire data at the required rate is the other half.

You may as well forget about finding one in a DIP package. And at that speed you will have to go with a proper multi-layer PCB with proper ground planes. ADS807 is a 53MHz 12-bit ADC.
 

Papabravo

Joined Feb 24, 2006
16,107
I have not heard of an anti-alias filter on the input. What is the purpose of that if the input is DC?
I have seen somehwere an A/D with a small FIFO memory inside it so I thought that it might be more common.
I will probably want a 10 or 12 bit resolution.
In any sampled data system, only frequencies between DC and one-half the sample rate can be resolved. frequencies in the input that are above the sample rate are reflected into the band from DC up to one half of the sample rate. This process is referred to as aliasing. An aniti-alias filter is an analog front end on a sampled data systems the limits the high frequency content of the input signal. This is something every embedded systems engineer needs to be familiar with.

Even a DC input can have noise and other high frequency content. It may be impertinent to ask but why are you sampling a DC signal at such a high rate?
 

crutschow

Joined Mar 14, 2008
27,188
I believe the mention of a "DC" signal is inaccurate.
Certainly the LADAR signal the TS wants to digitize wouldn't be DC.
 

Thread Starter

pyroartist

Joined Oct 9, 2015
98
Because the sensor vendor, ON Semiconductor, has a useless technical support team that does not answer questions I do not really know what the input to the A/D will look like when receiving real world background plus signal. I have read all of their documents and the only scope picture they show is of the dark count which is a series of pulses at a 2.6 MHz rate.
So if I have a fast A/D operating at say, 20 MSPS, that would sample the signal 8 times in the cycle. But in reality the signal from the SiPM sensor must first go through a transimpedance amplifier and then a logarithmic amplifier to compensate for distance-caused amplitude reduction. So I would guess that the A/D input signal would be a rapidly changing DC voltage. This saved data would be averaged mathamatically later during a post-processing operation. What do you think?

@MrChips : About a fast MCU, I am using the fastest, easy to work with machine I can find and that is the Teensy 4.0. It runs at 600 MHz which blows away most other small processors.
 

Papabravo

Joined Feb 24, 2006
16,107
I believe the mention of a "DC" signal is inaccurate.
Certainly the LADAR signal the TS wants to digitize wouldn't be DC.
I kinda had a feeling that might be the case.
Given the new information on the nature of the signal it is entirely possible that the anti-alias filter is already there. This could be confirmed with a spectrum analyzer.
Since when has it been the responsibility of a manufacturer to do an engineers job for him? Real engineers persevere, adapt, and overcome.
It might be in the TS's interest to setup an experiment and take some photos of the input signal just to have some reliable information in his files.
 

MrChips

Joined Oct 2, 2009
23,515
Don't be confused with the terms DC and AC. Think in terms of frequency and frequency spectrum.
DC refers to 0Hz frequency. There is no >0Hz component.
Changing DC is no longer DC. It has frequency components >0Hz.

In general, all electrical signals are DC + AC. In other words the frequency spectrum begins at 0Hz and goes up to infinity (or whatever maximum frequency).

A rapidly changing DC voltage, changing in the order of 100ns will contain frequencies that far exceed 10MHz. What you need to take into consideration is the rise and fall times of the signal. Another way of expressing this is in its slew, units of V/μs.

600MHz of Teensy refers to the clock frequency of the on-board i.MX RT1060 processor. This has nothing to do with the interface rate on the input/output pins. You still need to get the data into the chip somehow.
 

MrChips

Joined Oct 2, 2009
23,515
For LIDAR you are looking at light travelling at 3x10^8 m/s.
That is 3m in 10ns. Since you are looking at total time-of-flight, the reflection off an object 3m away will be received in 20ns.
Thus to achieve a resolution of 3m you have to have receiver resolution of 20ns. For 1m resolution you need better than 5ns timing resolution. This is best implemented with FPGA, not fast ADC.
 

MrChips

Joined Oct 2, 2009
23,515
You could possibly use a fast FIFO buffer for the A/D digital output.

How can a FPGA replace a fast ADC?
It doesn't. You want to measure the time interval between the transmitted signal and the received signal with pico-second resolution. The way to do that is with timing circuits, not voltage measuring circuits.
 

Papabravo

Joined Feb 24, 2006
16,107
For LIDAR you are looking at light travelling at 3x10^8 m/s.
That is 3m in 10ns. Since you are looking at total time-of-flight, the reflection off an object 3m away will be received in 20ns.
Thus to achieve a resolution of 3m you have to have receiver resolution of 20ns. For 1m resolution you need better than 5ns timing resolution. This is best implemented with FPGA, not fast ADC.
It is quite common to be overwhelmed with the implementation details of a project in an unfamiliar technology. In a career spanning half a century I can tell you that the most efficient strategy is to break things down into bite sized chunks and tackle each one until there aren't any left. When you ask sales reps and vendors for help, be sure always to be impeccably polite. It should be about building long term relationships.
 

crutschow

Joined Mar 14, 2008
27,188
The way to do that is with timing circuits, not voltage measuring circuits.
So how will you detect the voltage without a voltage measuring circuit?

Exactly what sequence and type of circuits do you envision from the LIDAR signal to the microprocessor?
 
Last edited:

Thread Starter

pyroartist

Joined Oct 9, 2015
98
About FIFO buffers: this was one of my initial ideas for rapidly collecting numbers from the A/D. But I have found almost NO information about how these chips work. Plus they all seem to have a very weird number of bits that they use (9 or 11 as I recall) and I have no idea why this is so. There must be some reason I am not privy to. Also, do I have to request a reading from the A/D every 100 ns. or will it just run by itself at the clock rate it is given? I have no experience with fast A/D. (Used to be called Video A/DI think.)

Oh, and I am not interested in Picosecond timing. Each window of timing is half of a 100 foot range bin return in increments of 100 ns. Total range of ~2000 feet. A 100 foot resolution is all I need. I am not measuring distance. I am looking at the signal variation between each range bin. Output of this system will be like an oscope X=time Y=amplitude.

I want to get some plans down on paper and some assurance this is going to work as parts are not cheap. The SiPM sensor board is $300+ at Mouser. The chip itself is so tiny it cannot be soldered by hand. 1mm square.
@Papabravo wrote
"It might be in the TS's interest to setup an experiment and take some photos of the input signal just to have some reliable information in his files."

Well because I am not going to spend over $300 on a part until I have a warm feeling that it will work for me I have not taken this step yet.

@MrChips I have the Teensy and I can assure you it is very fast on pin outputs.
 

andrewmm

Joined Feb 25, 2011
1,464
About FIFO buffers: this was one of my initial ideas for rapidly collecting numbers from the A/D. But I have found almost NO information about how these chips work. Plus they all seem to have a very weird number of bits that they use (9 or 11 as I recall) and I have no idea why this is so. There must be some reason I am not privy to. Also, do I have to request a reading from the A/D every 100 ns. or will it just run by itself at the clock rate it is given? I have no experience with fast A/D. (Used to be called Video A/DI think.)

Oh, and I am not interested in Picosecond timing. Each window of timing is half of a 100 foot range bin return in increments of 100 ns. Total range of ~2000 feet. A 100 foot resolution is all I need. I am not measuring distance. I am looking at the signal variation between each range bin. Output of this system will be like an oscope X=time Y=amplitude.

I want to get some plans down on paper and some assurance this is going to work as parts are not cheap. The SiPM sensor board is $300+ at Mouser. The chip itself is so tiny it cannot be soldered by hand. 1mm square.
@Papabravo wrote
"It might be in the TS's interest to setup an experiment and take some photos of the input signal just to have some reliable information in his files."

Well because I am not going to spend over $300 on a part until I have a warm feeling that it will work for me I have not taken this step yet.

@MrChips I have the Teensy and I can assure you it is very fast on pin outputs.

Can you send us links to the sensor your trying to interface to please.
 

Papabravo

Joined Feb 24, 2006
16,107
About FIFO buffers: this was one of my initial ideas for rapidly collecting numbers from the A/D. But I have found almost NO information about how these chips work. Plus they all seem to have a very weird number of bits that they use (9 or 11 as I recall) and I have no idea why this is so. There must be some reason I am not privy to. Also, do I have to request a reading from the A/D every 100 ns. or will it just run by itself at the clock rate it is given? I have no experience with fast A/D. (Used to be called Video A/DI think.)

...
FIFO buffers have a parallel interface. The reason for them being of an odd bit width is to accommodate a parity bit for 8 bit or 10 bit data. Thus 9 bit or 11 bit FIFOs. I used them often for data pattern generators in communication test sets. The ones we used had a depth of 512 or 1024 words (9 bits wide). A PC would load one up with a packet of data to be transmitted and since they are non-volatile, that packet could be repeatedly sent to to create eye-patterns or other conditions for checking a cable system.

The control is pretty simple with a read strobe (RD*) and a write strobe (WR*) that would guarantee valid data on the rising edge.
 
Top