I have an IR LED emitter and receiver. The emitter is always on so the receiver notices when something blocks the emitters beam. I have this connected to my ESP32 board and it reads about 300 (units of some kind) when the light beam is unbroken, and 0 when it is broken, as it should.

If I block the beam slowly it works fine, if I block the beam with say, the speed of a bullet, the microcontroller can't catch the 0 being passed to it.

I think this is because the microcontroller 8Mhz GPIO read speed is too slow. What I'm looking to do is make it so the 0 stays 0 for longer once the receiver notices a blocked beam. After extending the 0 signal for around 1 second, I want it to return to business as usual until the next 0 comes along.

What kind of simple circuit design do this?

 

A monostable multivibrator also known as a "one-shot".
ETA: I don't think your analysis is correct with respect to the ESP32 board.

 

Like this:
Pin 2 is your negative-going trigger to start the timer. You may want to insbert the output pulse or take care of it in the firmware.



a CMOS version of the ‘555 is the LMC555 from Texas Instruments and it can work down to 1.5 vots

 

A monostable multivibrator also known as a "one-shot".
ETA: I don't think your analysis is correct with respect to the ESP32 board.

As to which part? I did a lot of rabbit-holing so it very possible I got something wrong. But the ESP32 board I'm going to use has 30 GPIO pins, and I don't think they are fast enough to catch the quick signal once the IR LED sends a capture by breaking the beam.


Now, I do use Arduino IDE to program the board, maybe using C or something would make the GPIO's more responsive?

 

I have an IR LED emitter and receiver. The emitter is always on so the receiver notices when something blocks the emitters beam. I have this connected to my ESP32 board and it reads about 300 (units of some kind) when the light beam is unbroken, and 0 when it is broken, as it should.

If I block the beam slowly it works fine, if I block the beam with say, the speed of a bullet, the microcontroller can't catch the 0 being passed to it.

I think this is because the microcontroller 8Mhz GPIO read speed is too slow. What I'm looking to do is make it so the 0 stays 0 for longer once the receiver notices a blocked beam. After extending the 0 signal for around 1 second, I want it to return to business as usual until the next 0 comes along.

What kind of simple circuit design do this?


View attachment 300047

Speed of a bullet? The LM555 has a minimum trigger pulse width of about 1 µs. For a 1" long bullet traveling at the speed of sound (~1100 ft/sec), it takes about 75 µs for it to pass a point. That's a long, slow bullet. A half inch bullet traveling at mach 4 is going to be under 10 µs. While that's nominally an order of magnitude above the minimum, it assumes that the receiver is going to be completely blocked from the time the bullet's nose reaches the receiver until the tail has passed. Those are poor assumptions.

The numbers say that you are in the range of something workable, but that the devil is in the details. Do you have access to an oscilloscope? It would be very handy for you to know just what the waveform out of your receiver looks like.

 

I think this is because the microcontroller 8Mhz GPIO read speed is too slow.

What commands are you using to monitor the GPIO pin. An interrupt command or maybe a SR Latch?

 

Speed of a bullet? The LM555 has a minimum trigger pulse width of about 1 µs. For a 1" long bullet traveling at the speed of sound (~1100 ft/sec), it takes about 75 µs for it to pass a point. That's a long, slow bullet. A half inch bullet traveling at mach 4 is going to be under 10 µs. While that's nominally an order of magnitude above the minimum, it assumes that the receiver is going to be completely blocked from the time the bullet's nose reaches the receiver until the tail has passed. Those are poor assumptions.

The numbers say that you are in the range of something workable, but that the devil is in the details. Do you have access to an oscilloscope? It would be very handy for you to know just what the waveform out of your receiver looks like.

My use case will likely be below 2000fps, but I am interested in what your (point) unit is? Is that a millimeter? I wanted to do the math myself but I wasn't sure what 1us translates into for distance.

I still think my break-point is the microcontroller gpio pin, but I suppose it could be the IR Receiver not being fast enough to pick up the bullet. The IR LED Emitter/Receivers work on a 940nm wave length, and of course at the speed of light. I don't see why it would not pick up a break in beam.

I do put the sender and receiver in little tunnels, so it shouldn't experience enough ambient IR to ignore a bullet under 2k fps. My assumption of course. I'll drop a pic of the unit - the little blue holes are where the LED's will go. One side emitter, the other side receiver.

 

300 (units of some kind)

I take it you did not write the code.

GPIOs read 0 or 1, not 300. I suspect it is using the analog input, which is way slower than a GPIO.

I don’t think you need to extend the pulse, I think you need to make it a logic level, so that it can be read by a digital input. You can then use it to trigger an interrupt, and you will not miss it.

What does the receiver circuit look like? You may need only to change the value of a resistor.

Please post a schematic for the detector, so we can help you fix it.

 

What commands are you using to monitor the GPIO pin. An interrupt command or maybe a SR Latch?

So far just a dead simple Arduino IDE Sketch to recognize the hit.

This code was not fast enough to catch my finger crossing the beam when flicking it as if to snap a bug off my shoulder fast - it does catch if I move my finger slowly. I suspect the Serial.println might cause some slowdown, but it's just my finger not even the speed of a bullet or pellet I wouldn't think

The Sketch:
__________________________________________

int ifRead;
int hashit = 0;
const byte InputPin = 12;
void setup() {
Serial.begin(9600);
pinMode(InputPin, INPUT);
}
void loop() {
ifRead = analogRead(InputPin);
Serial.println(ifRead);
if( ifRead == 0 ){
hashit = 1;
}
if(hashit == 1){
hashit = 0;
Serial.println("You have a hit!");
delay(2000);
Serial.println("Starting Again");
}
}

 

Circuit I used for a chronograph years back. This converts the drop in ambient light of the receiver to a digital pulse.

 

My use case will likely be below 2000fps, but I am interested in what your (point) unit is? Is that a millimeter? I wanted to do the math myself but I wasn't sure what 1us translates into for distance.

I still think my break-point is the microcontroller gpio pin, but I suppose it could be the IR Receiver not being fast enough to pick up the bullet. The IR LED Emitter/Receivers work on a 940nm wave length, and of course at the speed of light. I don't see why it would not pick up a break in beam.

I do put the sender and receiver in little tunnels, so it shouldn't experience enough ambient IR to ignore a bullet under 2k fps. My assumption of course. I'll drop a pic of the unit - the little blue holes are where the LED's will go. One side emitter, the other side receiver.

View attachment 300049

The units I used are specified.

Calculating how long it takes an object to pass a point is very simple.

When the leading edge of the object reaches some point, you start a clock. You stop the clock when the trailing edge reaches that same point.

The distance that the trailing edge must travel in that time is L, the length of the object. The speed it is traveling at is S. The classic equation relating time, T, to speed and distance for objects traveling at constant speed is

L = S·T

In this case, L is, at most, the length of the bullet. It's probably less than that in practice because the tip of the bullet likely has to actually travel a bit further than the reference point before the beam intensity falls enough to detect and the beam intensity likely goes above the threshold before the tail of the bullet reaches the reference point. But those can be ignored, at least for now.

You have other potential problems. You have an array of emitters on one side and an array of detectors on the other. The idea, pretty obviously, being that the bullet is going to have some uncertainty in terms of exactly where it goes through the frame. But this means that each receiver is going to be getting illuminated by multiple LEDs and the bullet is only going to block one or two of them -- or possibly only part of a couple of them. So how much will the received energy at the detector actually fall? If you are counting on it falling as much as when you put your hand in between them, you are likely in for a huge disappointment.

This is why it would be very useful to actually capture the waveform that the detector puts out when a bullet passes by.


At 2 kfps, you are taking a picture every 500 µs. In that time, a bullet traveling at the speed of sound will more than half a foot, while a bullet traveling at mach 3 (very common for many rifle calibers) will move about 20 inches.

 

Just as I thought, you are using analog input, which is indeed too slow!

Again, please post the schematic of the detector.

As usual, my guess was dead on, and ignored.

Everyone wants to solve the problem the TS thinks he has instead if the real problem. Using a digital input is the right solution, even if the detector does need some additional pulse shaping, and we have no way of knowing yet whether that is needed or not.

 

What is the minimum pulse width on the GPIO when configured at a digital input?

 

No more than 1 instruction cycle.

 

No more than 1 instruction cycle.

Which on a 38MHz Arduino is (if I don’t have a math error) is 26μS. Should be fast enough for your finger flick. Maybe fast enough for a bullet. Are you trying to detect a bullet?

 

Just as I thought, you are using analog input, which is indeed too slow!

Again, please post the schematic of the detector.

As usual, my guess was dead on, and ignored.

Everyone wants to solve the problem the TS thinks he has instead if the real problem. Using a digital input is the right solution, even if the detector does need some additional pulse shaping, and we have no way of knowing yet whether that is needed or not.

Why do you think your guess was ignored? I just didn't have time to get back to you yet and I need to figure out how to draw you a schematic but it's pretty basic, 2 IR Leds facing each other with a 200ohm resister, and the Reciever gets a 10K ohm resister from positive side to ground and a signal wire from positive to the GPIO.

I'll draw it when I can. Changing to digital did solve my finger snap issue.
We'll wait to see if that's enough to handle a bullet (months away).

So, pat on back, good catch, not ignored.

I will get to the other comments as I can - ignoring nobody just time issue.

 

Which on a 38MHz Arduino is (if I don’t have a math error) is 26μS. Should be fast enough for your finger flick. Maybe fast enough for a bullet. Are you trying to detect a bullet?

No, 1/38,000,000 26nsec.

But he is using an ESP32, which goes up to 240MHz. I cannot find a figure for the ESP32, but for the 70MHz PIC24 I use, the min pulse for an external interrupt is specified as 20nsec.

I think the limiting factor is going to be the response time of the IR detector. I can’t find a definitive answer on that either.

 

So, pat on back, good catch, not ignored.

Thank you. I was reacting in part to several other threads that went the same way. I was chastising the other responders more so than you. I have seen a pattern where people post solutions before we have enough info to propose one.

2 IR Leds facing each other with a 200ohm resister, and the Reciever gets a 10K ohm resister from positive side to ground and a signal wire from positive to the GPIO.

Don’t see how two LEDs make a photo detector???

 

No, 1/38,000,000 26nsec.

But he is using an ESP32, which goes up to 240MHz. I cannot find a figure for the ESP32, but for the 70MHz PIC24 I use, the min pulse for an external interrupt is specified as 20nsec.

I think the limiting factor is going to be the response time of the IR detector. I can’t find a definitive answer on that either.

That’s why I should never attempt math after 10pm!

 

Please post the complete schematic for the circuit you have now. It is entirely possible that a simple component change will solve the problem.

ak

19 posts and counting . . .