# Reading a high rate (400 kHz) analog input with an ESP32 (or Arduino)

Tried Googling this but I'm not really sure what vocabulary to use.

I have a series of light sensors that will be detecting changes at the speed of 400 kHz (or 2.5 µs). I would like to use an ESP32 to receive this data, but according to my research, it can only detect analog inputs at the rate of 6 kHz (166 µs), much too slow.

Perhaps I have a fundamental misunderstanding of how the sensor works, but my assumption is the sensor looks for changes in light at the rate of 400 kHz and sends this signal (at the same rate?) to the micro-controller. Thus, the signal would need to be slowed down so the micro-controller is able to read it.

Goal: Determine when an object as small as a marble or large bug passes through a line of light at high rates of speed.

Circuit setup: A high powered LED that is pointed directly at a light sensor which will need to be activated upon an object passing through extremely quickly by determining when a shadow is cast on the sensor.

I looked in to using delays like this one, but it seems to only allow 1 fixed output and at \$1.66 a pop, this project would get really expensive, really fast.

Question: Is there a part that I'm missing that will allow me to detect a 400 kHz signal with my ESP32's 6 kHz analog input?

I'm fine with using some other device that has such analog capabilities and passing off the data to the ESP32, but all of the devices I have found (Arduinos) have too low of a poll rate for this.

Thanks in advance for any help/input!

Update: After all of your very helpful comments, I believe what I am needing is a method in which a sensor will respond to changes in light in at least a 5 µs intervals and only send a signal to the micro-controller when the light changes below a certain level (the object passes through the beam of light). I am still not sure how to go about this, however.

• What is the bandwidth of the signal raised up to 400 kHz that you are trying to detect. I.e. are you looking for slow amplitude changes in the 400 kHz waveform and hence you could use a precision rectifier or synchronized sample and hold? – Andy aka Apr 30 '19 at 18:05
• You want an ADC, I imagine. The platforms you're talking about have integrated ADCs, but they don't have the bandwidth you need, so you need an external ADC. – Hearth Apr 30 '19 at 18:09
• This scheme is most likely mistaken in its basic design. Use the 'edit' button to rewrite this as a description of the ultimate application problem you are trying to solve, and the architecture of the proposed solution. Then people can start helping you evolve that impractical idea into a related potentially practical one. – Chris Stratton Apr 30 '19 at 18:10
• Actually, I'm not sure I understand what you're doing. How would a delay line help? – Hearth Apr 30 '19 at 18:11
• You need to provide a lot more, basic information. How about how many sensors? How many bits of resolution do you need on each sensor? Basic ADC questions? What device is setting the 400 kHz sample rate? If the sensors are already "sampled" at 400 kHz, then what do you need an ADC for? What is the nature of the light? Is it on/off chopped light? Wildly flucuating? Slowly drifting? How the heck do you use "resistors" to make anything addressable? Your question is much too broad and makes almost no sense. Start adding a lot more information. – scorpdaddy Apr 30 '19 at 18:23

## 2 Answers

Your sensor uses an I$$\^2\$$C interface with a clock frequency of 400kHz. The actual conversion rate of the analog signal is much slower than that, but in any event you will receive your data through a digital I$$\^2\$$C connection rather than by digitizing an analog input.

If I understand the datasheet correctly, you must transmit the slave address and a register address, then the sensor responds with a 16-bit value for one channel of the input. That's going to take at least 36 clock cycles. Optimistically, you might be able to read register values at around 10kHz.

However, looking at the ALS_MEAS_RATE parameter it appears that the sensor requires 50ms to do an analog-to-digital conversion, so your fastest sampling rate is actually 20 samples per second.

• Thanks for your answer! So in other words, the signal that is passed from the sensor to the micro-controller is slower than the clock speed of the sensor? Where do I find the speed at which the info is transferred? I can't seem to find that in the datasheets. Also, is the clock speed of 400kHz the speed at which the sensor will collect data, 400,000 times a second? – PyFire Apr 30 '19 at 18:58
• Perhaps you would post the part number of the sensor so people can look at its datasheet. – scorpdaddy Apr 30 '19 at 19:03
• LTR-303ALS-01 is the manufacture part number. Sorry, I thought I had posted the link to the device in the main body. – PyFire Apr 30 '19 at 19:08
• @PyFire No, the device is much, much, much slower than you think. See my edits. – Elliot Alderson Apr 30 '19 at 19:43
• Ah, that's not what I expected. Thank you for pointing that out. It does have an interrupt, which leads me to wonder if this or any other device has the ability to sample at 400 kHz but only convert/send data once a change > X occurs? I was hoping to check for changes in light with at least 5 µs intervals, then alert the micro-controller. Is this even possible? – PyFire Apr 30 '19 at 20:17

According to the datasheet of your sensor (see page 11), the mentioned 400 kHz is the maximum clock frequency that the sensor can provide but you can also see that it can operate at frequencies as low as 1 kHz.

This means the 100 kHz (which seems to be the default for Arduino) of your master will work fine with the sensor.

• Right, but I would like to sample the sensor's light at 400,000 times per second (500 kHz). Thus, it will be using the max value. Is there a way to sample at 400 kHz, but only send data to the arduino at 1 kHz? – PyFire Apr 30 '19 at 19:19
• This is not an answer to the question which was asked, please delete – Chris Stratton Apr 30 '19 at 19:37
• @PyFire When I interpret page 16 of the datasheet correctly, then the fastest measurement you can make is 50ms, which correspond to about 0.02kHz/ksps - w/o doing any maths I would think reading that should be reasonable – Anonymous Anonymous Apr 30 '19 at 19:38