Hi,
does anyone know what the normal response time is of a LED? IE how long it takes to turn on and off after having the signal applied or removed?
The plan is to use a digital out pin to turn on a bank of leds in sucession, and be able to take a photo of the LED bank in order to determine how much time has passed since pressing the take photo button.
thanks in advance
Think a microsecond or so. Fast optocouplers run at 10's of ns delay, but they have
specially fast IR LEDs. Its not often given in the datasheet alas.
spruce_m00se:
Hi,
does anyone know what the normal response time is of a LED? IE how long it takes to turn on and off after having the signal applied or removed?
It's almost instantaneous. You start to get light as soon as the electrons start moving. Any delay is because of capacitance in the wires, etc.
Not quite that simple, Carrier lifetime - Wikipedia
Hi ,
For my test I would like to be able to measure 1/10th of a ms, do you think that will be feasible? Obviously I also need to bear in mind how long the signal will take to leave the arduino pin and light the LED;
Along with making sure the sketch is quick enough to efectivly work at that speed,
BW = = 1/ (9.11)
This yields a very important principle: An LED's modulation bandwidth is limited by the recombination lifetime of the charge carriers. The physics governing this result is as follows: Suppose you excite an electron at the conduction band. It takes ns for this electron to fall to the valence band and recombine. During this interval you cannot change its status, so that if you turn off the forward current, you must wait ns until radiation will actually cease. This ns interval is necessary to allow a charge carrier to reach its destination. In other words, you cannot stop an excited electron that is on its way from the conduction band to the valence band. Thus, lifetime puts a fundamental limit on the modulation bandwidth of an LED. (You can repeat this reasoning using a p-n junction model: While an electron is moving through an active region, you cannot stop it; that is, you cannot change its status until this electron recombines.)
Table 9.2 Typical characteristics of LEDsActive Material Type Radiating wavelength
(nm) Spectral
width
(nm) Output power into fiber (µW) Forward current (mA) Rise/fall time (ns)
AIGaAs SLED 660 20 190–1350 20(min) 13/10
ELED 850 35–65 10–80 60–100 2/2–6.5/6.5
GaAs SLED 850 40 80–140 100 —
ELED 850 35 10–32 100 6.5/6.5
InGaAsP SLED 1300 110 10–50 100 3/3
ELED 1300 25 10–150 30–100 1.5/2.5
ELED 1550 40–70 1000–7500 200–500 0.4/0.4–12/12Source: Lightwave 1999 Worldwide Directory of Fiber-Optic Communications Products and Services, March 31, 1999, pp. 58-61.
This is why LEDs are restricted by bandwidth in the range of hundreds of MHz. Such restrictions determine their applications in local area and other low-bandwidth networks.Power-bandwidth product is another important characteristic of an LED. It appears that the product of an LED's optical output power and its modulation bandwidth is constant:
BW P = constant (9.12)
In other words, you can increase an LED's bandwidth but only at the expense of its output power. Alternatively, you can increase output power but then bandwidth decreases.
Driving LED in a Nanosecond Regime by a Fast Operational Amplifier
Abstract
It is widely believed that the generation of high speed optical signals is
not the job for an LED. However this work is done to show that there are
techniques which can be used to produce nanosecond square pulses from
a diode. Rise and fall times of a typical 10ns long signal were 1-2 ns and
the intensity of the emission could be controlled by the supply voltage.
The wavelength of the radiation was 472 nm, which is blue in colour, but
any longer or even shorter wavelengths can similarly be used. The
consistency of the experiment and its theoretical model was analysed by
computer simulations using OrCAD and PSPICE.
WOW, completely out of my depth reading that,
should I understand from that, that the wavelength of the LED affects its reaction time also ? in which case I assume I can make my test rig quicker with different colour leds, I guess RED will be the fastest, just an iniformed guess mind you ,
The bottom line is that the data sheet should say how quickly the LED can respond.
And how you drive it will affect the response time, limited by other factors of the LED.
spruce_m00se:
For my test I would like to be able to measure 1/10th of a ms, do you think that will be feasible?
Yes.
We can argue all day over this but the true speed is definitely many orders of magnitude less than 1/10th of a ms
True. An LED should be able to blink on and off a lot faster than 10kHz.
I wonder how using a digital camera will affect this. I would think as long as things are bright enough that shutter speed is a far bit faster than 1/2 the time between LED changes, it would turn out OK.
So the idea is to have a row of LEDs counting up or down in binary?
polymorph:
True. An LED should be able to blink on and off a lot faster than 10kHz.I wonder how using a digital camera will affect this. I would think as long as things are bright enough that shutter speed is a far bit faster than 1/2 the time between LED changes, it would turn out OK.
So the idea is to have a row of LEDs counting up or down in binary?
Yes the idea is to have several banks of LEDs counting up, with four rows, 1/10th ms, 1ms, 10ms and 100ms,
The trigger the camera and the count sequence at the same time, and stop the count sequence when the FLASH signal leaves the camera and reaches the arduino. Then using millis and the photo, compare the time taken to receive the flash after the photo was taken. It is for a very time sensitive application. where 100ms of unknown time delay could render the application useless.
How fast is the shutter?
the shutter apparently takes 0.25 ms to cycle, so it may be neccesary to add another line for hundreths of a millisecond in order to catch the 0.05 part,
But any LEDs changing state -during- the time the shutter is open (is that what you meant by "cycle"?) will appear in the photo. If the shutter is open for a long time, you are going to have a very difficult time telling which LEDs were already on when the shutter opened, and how many of them turned on shortly after it opened.
I'm confused some things. I asked if you are going to have LEDs counting in binary, you said yes but then it sounds like you are talking about rows of LEDs counting in base 10. 10 LEDs counting up as a bar graph in 100uS each, another row of 10 counting up by 1mS each, etc. So that would be a no.
What do you mean by:
...when the FLASH signal leaves the camera and reaches the arduino.
Are you talking about the light from the flash traveling to a photodiode sensor on the Arduino? Or an electrical signal?
Is this a digital or a film camera? The flash is going to be sync'd to the opening of the shutter, so if you are using a digital camera, there may be a long and possibly unpredictable delay after pressing the button before the shutter opens and the flash fires. The flash may even fire -after- the shutter is open.
You need the actual button press. Isn't that what you want to know? How long between the time you press the button and when it takes the image? The important time, if you are always using a flash, is between pressing the button and the flash going off.
correct, base ten with rows of leds,
How would one go about counting in binary ? would that be an easier approach ?
The plan will be to leave all the lights on, then just count up the last led in each bank, add them and get a total time,
The camera is digital, all I need to know is the time that elapses between the iris opening and the flash signal being sent, the flash signal will be a pin that goes high (maybe low i have to check) when the camera considers it neccesary to take a photo,
I plan to set an integer from millis when the button is pressed and start the light sequence at the same time,
then I can let the camera take its photo and send the "flash" signal back to arduino. The moment in which the flahs volatage is received the code will set another integer from the current millis,
I can then deduct the first millis from the second to get the whole cycle time of the photo, and deduct the number calculated from the led banks in order to get the time taken to activate the flash.
the obvious problem being if the flash is activated right when the iris is opened, and it stays open for 0.25ms, i will alwyas have a 0.25ms error,
it would be good if i could access the iris signal and take a further open closed reading from that, but i think that may well be beyond me
Perhaps micros() would be better for this. Didn't you say you are going to have LEDs counting in 0.1ms aka 100uS timing? I'd have another row of LEDs counting at 10us intervals.
You need to be precise in your questions, precise in reading follow-up questions and answers, and precise in your answers.
I'm unclear about how the LEDs counting is going to tell you the time between the shutter opening and the flash going off. Or at least how a photo of the LEDs helps you.
So the button is pressed, you can access that signal.
Some unknown amount of time passes before the shutter opens. I guess you need this time.
Some unknown amount of time passes after the shutter opens, before the flash goes off. You need this time.
How about this:
LEDs all lit, every one. Just bright enough to show in the photo.
Send a button press signal from the Arduino, at the same time the Arduino starts turning LEDs off. It is NOT counting down, it is counting up but the count is in dark LEDs.
Some milliseconds later, the shutter opens. All the LEDs that are dark when the shutter opens show as dark. Stay with me... the LEDs that go out while the shutter is open merely appear dimmer, so the image shows an accurate time from button press to shutter opening.
Some (probably microseconds) time later, the flash goes off. A fast photodiode sensor or an electrical pulse detector signals the Arduino and it stops the LEDs from counting.
Now look at the time represented by dark LEDs in the photo and the dark LEDs on the display as it is now. The difference is the time between shutter opening and flash going off.
Why not have the LEDs simply start out dark and light up as it counts up? Shutter opens, all lit LEDs show. However, the shutter is open for 0.25ms so more LEDs will light up. They will look gradually darker the later they light after the shutter opens, but an LED that lights right after the shutter opens is going to be nearly indistinguishable from one that lit before the shutter opened.
I'm not sure counting by decades is going to work. Say it just counts from 1 to 2ms as the shutter opens. Well, then the 0.1ms LEDs all change state together and continue counting up. During a long 0.25ms shutter time, that is going to be ambiguous, no matter how you slice it.
It might be better to line up 50 LEDs to count (again, light to dark) by 0.05ms each. That's 2.5ms and your shutter time is only 0.25ms, should be long enough. The micros() timer has a granularity of 4us. Use it to time the LEDs.
If there is a long time from button press to shutter opening, figure out how constant the time is from button press to shutter opening, and delay counting a fixed time to put the shutter opening within that window of time.
spruce_m00se:
correct, base ten with rows of leds,
How would one go about counting in binary ? would that be an easier approach ?
You should really use gray code. That way only one LED can be in transition at any time.
Gray code won't help as long as the shutter is open for so long.
It will be less than 1/10th of a ms.