The circuit should work without either the resistor or the capacitor, however, the resistor limits the forward current in an important way. Without the resistor the LED flash would be soooo bright that there is danger of damaging either the stamp output pin or the LED itself.
Without the added capacitor, the circuit depends for its operation on the intrinsic capacitance of the LED itself (~50pF) , plus the capacitance of the Stamp or Prop input pin (~6 pF) , and other capacitance in the circuit (4 to 300+pF). In the latter category, if the circuit is built on one of those white protoboards, that will add at least 100pF to the circuit. Ditto if the sensor is mounted out at the end of a coaxial cable.
Notice that the program I posted keeps adding RC timout periods until one actually does return a non-zero value. That is important at low light levels, where it can take a long time, multiple RCtime periods, for the photodiode LED to discharge the capacitor down to the switching threshold.
On the other hand, in bright light, say outdoors in sunlight, the discharge happens so fast that additional capacitance may be called for. It is possible to attach the "ground" side of the additional capacitor to a second pin of the Stamp or Prop, and either float the pin for low light levels, or set it to output for high light levels. That can happen automatically when the program senses high versus low light levels.
Green LEDs are generally made from indium gallium nitride (InGaN), which has a high bandgap voltage and low leakage. That allows it to cover a huge range of light levels.
well thats good cause im pretty sure the leds i bought for the project are green. and the only leds i currently have in my stash are green. i will be placing an order to get a prop kit friday so i will be trying this very soon
well thats good cause im pretty sure the leds i bought for the project are green. and the only leds i currently have in my stash are green. i will be placing an order to get a prop kit friday so i will be trying this very soon
Just had a go with violet LED - very little response to white light(!). Red LED worked nicely with discharge times of 7ms in lowish artificial light, upto > 30ms with finger over it. (All at 5V, not with a Prop). Leakage from oscilloscope 10x probe (ie a 10M resistor) completely masks the effect until intense light is used - I calculate my LED had about 20pF (some of this was the CMOS input capacitance though).
NOT MY VIDEO. Another forum linked to this amazing demo by Jeff Han on an old web page which is no longer maintained. I was blown away and thought it deserved a wider audience on Youtube, so I uploaded it there with a similar description. Still a WOW 10+ years later IMO.
Wow, indeed!!! I wondered if those AMOLED displays could use this technique instead of having separate capacitive touch hardware...
Edit: I need to learn more about this technique. I just got those 8x8 LED boards in the giveaway. I wonder if I could do a simple touch test without modifying the hardware.
All Clock Loop content is covered under:
The TAPR Open Hardware License
Version 1.0 (May 25, 2007)
Copyright 2007 TAPR - http://www.tapr.org/OHL
TERMS OF USE: MIT License
Wow, indeed!!! I wondered if those AMOLED displays could use this technique instead of having separate capacitive touch hardware...
It all depends on HOW OLEDS are constructed down to the junction level.
Finally, the AM part in AMOLED stands in for Active Matrix, rather than a passive matrix technology. This tells us how each little OLED is controlled. In a passive matrix, a complex grid system is used to control individual pixels, where integrated circuits control a charge sent down each column or row. But this is rather slow and can be imprecise. Active Matrix systems attach a thin film transistor (TFT) and capacitor to each LED. This way, when a row and column is activated to access a pixel, the capacitor at the correct pixel can retain its charge in between refresh cycles, allowing for faster and more precise control.
So to sense using a display is possible with what I understand about AMOLED now.
But it would require a cpu fast enough and one that didn't multiplex its pinout to the AMOLED display.
The driver chip that controls each "capacitor at the correct pixel that retains its charge in between refresh cycles" needs to be able to switch its output to an input and run code that most likely needs to be VERY fast to detect ambient light.
And thats assuming the oled sandwitch dosen't affect the nearby AMOLED cells or refelction from the protective glass, ect..
This would require the AMOLED manufacturer to make the array with a chip that can do some seriously fast calculations.
I had proposed to a prior employee i worked with at the hard drive plant in rochester, mn,
to start making a HAMR based hard drive that uses laser junction falloff rate for read sensing.
I mentioned this in another thread here too along with display reading. (they use similar methods, gate falloff rate)
Heat-assisted magnetic recording (HAMR) involves heating individual magnetic grains, just a few nanometers long, with a precision laser to write data. According to TU Wien's simulations, the technique could be used to cram more than 13 terabits of data into a square-inch of material. The best hard disk drives used today have a storage capacity of about 1.3 Tb/in², or 10 times less. But if HAMR techniques can be used in manufactured hard drives, then we might see a storage sea change.
So when doing a HAMR burn on a hard drive platter spot, the time it takes for the laser gate voltage to fall, is determined by the light reflecting back into the laser from the the hard drive platter.
This laser gate fall time changes, depending on if the spot on the hard drive platter had been given a previous 1 or a 0 polarity.
So the time it takes to "heat individual magnetic grains" will change, depending on the beginning polarity of the magnetic grain.
Some writes will take less energy due to the grain state already in the desired polarity.
This is how you know the previous state of the grain, thus how you do a HAMR read.
BUT this also might require a specialized HAMR laser manufactured with a gate/excited state, sense pin.
This also means you REBURN each spot when you read it. This means also you must now reburn the data on that spot to what it was before you "read" it. So you must do a re-write to the spot you just read, actually its a 50/50 chance you need to reburn. (or refresh) Q.E.D. bro'
Edit: I need to learn more about this technique. I just got those 8x8 LED boards in the giveaway. I wonder if I could do a simple touch test without modifying the hardware.
The 8x8 board has multiplexed the leds anode and cathode with other leds in the array. This will affect your led sense, possibly to the point that it won't work.
VAR
blinkwait = 1_000_000 'time to wait to let led light stay on (CAUTION very high values will burn LED, and mess up program)
readwait = 4_000_000 'time to wait to read for LED state change.
Pub LedSense
dira[LedAnode] := 1 'set direction of fx led anode leg.
Repeat
'----bLINK led
dira[LedCathode := 1 ' make n pin an output
outa[LedAnode] := 1 ' p - high LED ON
outa[LedCathode] := 0 ' n - low LED ON
waitcnt(blinkwait + cnt) 'wait for time while led on
outa[LedAnode] := 0 ' p - low LED OFF
dira[LedCathode] := 0 ' turn pin output off
'---READ led-----
dira[LedCathode] := 1 ' make n pin an output
outa[LedAnode] := 0 ' p - low 'reverse bias led
outa[LedCathode] := 1 ' n - high 'reverse bias led
dira[LedCathode] := 0 ' n - make n pin an input
waitcnt(readwait + cnt) ' wait for pin to change state
LedState := ina[LedCathode] ' read state of n pin, and store it.
I have made code that is able to sense leds in a multiplexed setup, but I only tried it where the anodes were all connected to a single pin.
I was still able to sense the led states with the anodes on the same pin.
But I think if you have the cathodes merged too, you will have problems.
CON
_clkmode = XINPUT + PLL16X 'this chip gets its clock from the U2-PotReader prop.
_xinfreq = 5_000_000
VAR
blinkwait = 1_000_000 'time to wait to let led light stay on (CAUTION very high values will burn LED, and mess up program)
readwait = 4_000_000 'time to wait to read for LED state change.
'do not uncomment these pin definitions, they are in the DAT section, this is only for reference.
'Led1 = 00
'Led2 = 01
'Led3 = 02
'Led4 = 03
'Led5 = 04
'Led6 = 05
'Led7 = 06
'Led8 = 07
'Led9 = 08
'Led10 = 09
'Led11 = 10
'Led12 = 11
'Led13 = 12
'Led14 = 13
'Led15 = 14
'Led16 = 15
'AnodeBase+ = 16 Anode of all 16 leds + 100 ohm resistor
PUB LedMain | old, future
dira[Base] := 1 'set direction of 1-16 leds anode leg.
Repeat
If old <> BpmStep 'only run if step has changed
!outa[Green] 'toggle hearbeat led.
ledstate16[old] := 0 'make sure led state for last step is now off.
ReadLed(BpmStep, Base) 'read current step's LED for on state.
LightLed(BpmStep, Base) 'light up current steps LED
old := BpmStep 'store current step in old so we know we already ran for this step.
PUB LightLed (n, p)
'----bLINK led
dira[n] := 1 ' make n pin an output
outa[p] := 1 ' p - high LED ON
outa[n] := 0 ' n - low LED ON
waitcnt(blinkwait + cnt) 'wait for time to have led on.
outa[p] := 0 ' p - low LED OFF
dira[n] := 0 ' turn pin output off
PUB ReadLed (n, p)
'---READ led-----
dira[n] := 1 ' make n pin an output
outa[p] := 0 ' p - low 'reverse bias led
outa[n] := 1 ' n - high 'reverse bias led
dira[n] := 0 ' n - make n pin an input
waitcnt(readwait + cnt) ' wait for pin to change state
ledstate16[n] := ina[n] ' read state of n pin
DAT
Led byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Base byte 16
BpmStep byte 0'----------------------------------------------------------------------1
LedState16 byte 0, 0, 0, 0'-------------------------------------2-3-4-5-----------------4-5-6-7
byte 0, 0, 0, 0'-------------------------------------6-7-8-9-----------------8-9-10-11
byte 0, 0, 0, 0'-------------------------------------10-11-12-13-------------12-13-14-15
byte 0, 0, 0, 0'-------------------------------------14-15-16-17-------------16-17-18-19
When multiplexing the Anodes, my code to read the leds dosen't change at all compared to reading a led with its anode not multiplexed.
Because your cathodes are multiplexed, they will cause some bleedoff. Also I think you have ULN driver chips on that 8x8 matrix, making the control of the led state even harder.
If people have a hard time with this, I can make a demo program, schematic, and instructional on how to read leds using a propeller,
A demo that doesn't do anything else but sense with a led, and somehow indicate its state(using debug output, or even another led)
I have found that some leds (blue and green) especially smt parts, require PASM timing to detect led state, due to much different junction capacitance.
I have messed with the blue and green leds in smt parts for led sensing, I use red, because its been the most reliable.
This smt part has these values for VF.
Forward Voltage
IF = 8 mA
VF(avg)
Red-1.9v
Green-3.0v
Blue-3.0v
VF(max)
Red-2.4v
Green-3.6v
Blue-3.6v
So you can see that using a led with a VF of 1.9v or so helps out greatly.
This kind of led works in SPIN with its slower instruction timing, and why it works in a BS2.
Due to this lower VF, the capacitance falloff rate is slower than the leds with VF of 3v,
This is why PASM speeds are needed for higher VF leds.
This might explain why some have had issues with led sense, their VF is probably too high for the chip speed, or language instruction speed.
One of the requirements for led sensing, is that you have a light source that has the same wavelength for its emission as the wavelength for the led detector.
NOTE:
In this video demo, notice how the lights are OFF in the room.
This person is NOT detecting the light from the environment(ambient) to determine led state. (detect when the leds senses a lower light level, a.k.a. your finger blocking the light completely.
This demo shows sense of increased light due to the leds that surround it, the photons that are emitted from the leds surrounding the sense led bounce off the finger and into the leds currently in sense mode. (red works with finger because blood)
This means they didn't sense the entire array at once. And then emit light.
They did a sense sweep, like how a old crt tv drew its picture.
During this sense sweep, the other leds stay lit (through a pwm due to very low resistors, can't burn them long, low resistors for sensing[100 ohm])
For my black box and mims mirror, I detect using blocked light, because I don't have a dense packed led array.
THIS MEANS YOU NEED AN OVERHEAD SOURCE OF LIGHT. (or a very bright room light.)
When you block that overhead light (ambient), the led junction is completely dark.
In this picture, I use ccfl tubes to create the overhead (ambient) light.
But I don't like ccfl or el wire or the like, due to high voltage needs, I stick to low voltage light sources, leds, etc, for safety of self and circuit.
Heck two leds right next to each other might work, or a led surrounded by 4 leds, to make a reflective type sense.
Reflective doesn't work as well I have noticed, for finger applications, and almost won't work at all with green and blue and the finger(due to red blood reflection)
All Clock Loop content is covered under:
The TAPR Open Hardware License
Version 1.0 (May 25, 2007)
Copyright 2007 TAPR - http://www.tapr.org/OHL
TERMS OF USE: MIT License
Has anyone tried Bi-Colour LEDs for this, 3 terminal ones may be better, one as the emitter and one as the sense element ?
The problem is, you are using two DIFFERENT monochromatic devices, and each led is a different wavelength.
USUALLY, the emission and detection leds need to have identical wavelengths. (for the most part, this depends on the dope in the led die.)
You could use specialized devices, but i think people like the fact that leds are cheap, and with emission and detection using the same led, less i/o is used.
Comments
Without the added capacitor, the circuit depends for its operation on the intrinsic capacitance of the LED itself (~50pF) , plus the capacitance of the Stamp or Prop input pin (~6 pF) , and other capacitance in the circuit (4 to 300+pF). In the latter category, if the circuit is built on one of those white protoboards, that will add at least 100pF to the circuit. Ditto if the sensor is mounted out at the end of a coaxial cable.
Notice that the program I posted keeps adding RC timout periods until one actually does return a non-zero value. That is important at low light levels, where it can take a long time, multiple RCtime periods, for the photodiode LED to discharge the capacitor down to the switching threshold.
On the other hand, in bright light, say outdoors in sunlight, the discharge happens so fast that additional capacitance may be called for. It is possible to attach the "ground" side of the additional capacitor to a second pin of the Stamp or Prop, and either float the pin for low light levels, or set it to output for high light levels. That can happen automatically when the program senses high versus low light levels.
Green LEDs are generally made from indium gallium nitride (InGaN), which has a high bandgap voltage and low leakage. That allows it to cover a huge range of light levels.
Just had a go with violet LED - very little response to white light(!). Red LED worked nicely with discharge times of 7ms in lowish artificial light, upto > 30ms with finger over it. (All at 5V, not with a Prop). Leakage from oscilloscope 10x probe (ie a 10M resistor) completely masks the effect until intense light is used - I calculate my LED had about 20pF (some of this was the CMOS input capacitance though).
I think xanadu and Duane need to jump on this.
Edit: I need to learn more about this technique. I just got those 8x8 LED boards in the giveaway. I wonder if I could do a simple touch test without modifying the hardware.
All Clock Loop content is covered under:
The TAPR Open Hardware License
Version 1.0 (May 25, 2007)
Copyright 2007 TAPR - http://www.tapr.org/OHL
TERMS OF USE: MIT License
It all depends on HOW OLEDS are constructed down to the junction level.
So to sense using a display is possible with what I understand about AMOLED now.
But it would require a cpu fast enough and one that didn't multiplex its pinout to the AMOLED display.
The driver chip that controls each "capacitor at the correct pixel that retains its charge in between refresh cycles" needs to be able to switch its output to an input and run code that most likely needs to be VERY fast to detect ambient light.
And thats assuming the oled sandwitch dosen't affect the nearby AMOLED cells or refelction from the protective glass, ect..
This would require the AMOLED manufacturer to make the array with a chip that can do some seriously fast calculations.
I had proposed to a prior employee i worked with at the hard drive plant in rochester, mn,
to start making a HAMR based hard drive that uses laser junction falloff rate for read sensing.
I mentioned this in another thread here too along with display reading. (they use similar methods, gate falloff rate)
So when doing a HAMR burn on a hard drive platter spot, the time it takes for the laser gate voltage to fall, is determined by the light reflecting back into the laser from the the hard drive platter.
This laser gate fall time changes, depending on if the spot on the hard drive platter had been given a previous 1 or a 0 polarity.
So the time it takes to "heat individual magnetic grains" will change, depending on the beginning polarity of the magnetic grain.
Some writes will take less energy due to the grain state already in the desired polarity.
This is how you know the previous state of the grain, thus how you do a HAMR read.
BUT this also might require a specialized HAMR laser manufactured with a gate/excited state, sense pin.
This also means you REBURN each spot when you read it. This means also you must now reburn the data on that spot to what it was before you "read" it. So you must do a re-write to the spot you just read, actually its a 50/50 chance you need to reburn. (or refresh)
Q.E.D. bro'
The 8x8 board has multiplexed the leds anode and cathode with other leds in the array. This will affect your led sense, possibly to the point that it won't work.
I have made code that is able to sense leds in a multiplexed setup, but I only tried it where the anodes were all connected to a single pin.
I was still able to sense the led states with the anodes on the same pin.
But I think if you have the cathodes merged too, you will have problems.
CON _clkmode = XINPUT + PLL16X 'this chip gets its clock from the U2-PotReader prop. _xinfreq = 5_000_000 VAR blinkwait = 1_000_000 'time to wait to let led light stay on (CAUTION very high values will burn LED, and mess up program) readwait = 4_000_000 'time to wait to read for LED state change. 'do not uncomment these pin definitions, they are in the DAT section, this is only for reference. 'Led1 = 00 'Led2 = 01 'Led3 = 02 'Led4 = 03 'Led5 = 04 'Led6 = 05 'Led7 = 06 'Led8 = 07 'Led9 = 08 'Led10 = 09 'Led11 = 10 'Led12 = 11 'Led13 = 12 'Led14 = 13 'Led15 = 14 'Led16 = 15 'AnodeBase+ = 16 Anode of all 16 leds + 100 ohm resistor PUB LedMain | old, future dira[Base] := 1 'set direction of 1-16 leds anode leg. Repeat If old <> BpmStep 'only run if step has changed !outa[Green] 'toggle hearbeat led. ledstate16[old] := 0 'make sure led state for last step is now off. ReadLed(BpmStep, Base) 'read current step's LED for on state. LightLed(BpmStep, Base) 'light up current steps LED old := BpmStep 'store current step in old so we know we already ran for this step. PUB LightLed (n, p) '----bLINK led dira[n] := 1 ' make n pin an output outa[p] := 1 ' p - high LED ON outa[n] := 0 ' n - low LED ON waitcnt(blinkwait + cnt) 'wait for time to have led on. outa[p] := 0 ' p - low LED OFF dira[n] := 0 ' turn pin output off PUB ReadLed (n, p) '---READ led----- dira[n] := 1 ' make n pin an output outa[p] := 0 ' p - low 'reverse bias led outa[n] := 1 ' n - high 'reverse bias led dira[n] := 0 ' n - make n pin an input waitcnt(readwait + cnt) ' wait for pin to change state ledstate16[n] := ina[n] ' read state of n pin DAT Led byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Base byte 16 BpmStep byte 0'----------------------------------------------------------------------1 LedState16 byte 0, 0, 0, 0'-------------------------------------2-3-4-5-----------------4-5-6-7 byte 0, 0, 0, 0'-------------------------------------6-7-8-9-----------------8-9-10-11 byte 0, 0, 0, 0'-------------------------------------10-11-12-13-------------12-13-14-15 byte 0, 0, 0, 0'-------------------------------------14-15-16-17-------------16-17-18-19When multiplexing the Anodes, my code to read the leds dosen't change at all compared to reading a led with its anode not multiplexed.
Because your cathodes are multiplexed, they will cause some bleedoff. Also I think you have ULN driver chips on that 8x8 matrix, making the control of the led state even harder.
This code comes from my black box audio sequencer and fx box.
http://forums.parallax.com/discussion/115258/theblackbox-release-v2-0-propeller-hss-fx-sequencer-with-digital-audio-spdif
If people have a hard time with this, I can make a demo program, schematic, and instructional on how to read leds using a propeller,
A demo that doesn't do anything else but sense with a led, and somehow indicate its state(using debug output, or even another led)
I have found that some leds (blue and green) especially smt parts, require PASM timing to detect led state, due to much different junction capacitance.
I have messed with the blue and green leds in smt parts for led sensing, I use red, because its been the most reliable.
I am sure i could get blue and green working too if I tried my hand at PASM timing.
The leds I am currently talking about are cree smt leds.
http://www.digikey.com/product-detail/en/CLVBA-FKA-CC1F1L1BB7R3R3/CLVBA-FKA-CC1F1L1BB7R3R3CT-ND/2650499
The red does sense properly.
This smt part has these values for VF.
Forward Voltage
IF = 8 mA
VF(avg)
Red-1.9v
Green-3.0v
Blue-3.0v
VF(max)
Red-2.4v
Green-3.6v
Blue-3.6v
So you can see that using a led with a VF of 1.9v or so helps out greatly.
This kind of led works in SPIN with its slower instruction timing, and why it works in a BS2.
Due to this lower VF, the capacitance falloff rate is slower than the leds with VF of 3v,
This is why PASM speeds are needed for higher VF leds.
This might explain why some have had issues with led sense, their VF is probably too high for the chip speed, or language instruction speed.
One of the requirements for led sensing, is that you have a light source that has the same wavelength for its emission as the wavelength for the led detector.
NOTE:
In this video demo, notice how the lights are OFF in the room.
This person is NOT detecting the light from the environment(ambient) to determine led state. (detect when the leds senses a lower light level, a.k.a. your finger blocking the light completely.
This demo shows sense of increased light due to the leds that surround it, the photons that are emitted from the leds surrounding the sense led bounce off the finger and into the leds currently in sense mode. (red works with finger because blood)
This means they didn't sense the entire array at once. And then emit light.
They did a sense sweep, like how a old crt tv drew its picture.
During this sense sweep, the other leds stay lit (through a pwm due to very low resistors, can't burn them long, low resistors for sensing[100 ohm])
For my black box and mims mirror, I detect using blocked light, because I don't have a dense packed led array.
THIS MEANS YOU NEED AN OVERHEAD SOURCE OF LIGHT. (or a very bright room light.)
When you block that overhead light (ambient), the led junction is completely dark.
In this picture, I use ccfl tubes to create the overhead (ambient) light.
But I don't like ccfl or el wire or the like, due to high voltage needs, I stick to low voltage light sources, leds, etc, for safety of self and circuit.
Heck two leds right next to each other might work, or a led surrounded by 4 leds, to make a reflective type sense.
Reflective doesn't work as well I have noticed, for finger applications, and almost won't work at all with green and blue and the finger(due to red blood reflection)
https://hackaday.io/project/16788-mimsmirror
https://hackaday.io/project/16789-theblackboxsequencer
All Clock Loop content is covered under:
The TAPR Open Hardware License
Version 1.0 (May 25, 2007)
Copyright 2007 TAPR - http://www.tapr.org/OHL
TERMS OF USE: MIT License
Has anyone tried Bi-Colour LEDs for this, 3 terminal ones may be better, one as the emitter and one as the sense element ?
This one might be suitable ? Looks to have two separated die and small lens-domes,
Kingbright APBL3025ESGC-F01
A single dome one might have too much internal leakage ?
http://www.digikey.com/product-detail/en/kingbright/APBD3224SURKCGKC-F01/754-1647-2-ND
http://www.electronicsweekly.com/blogs/led-luminaries/blood-pulse-monitor-chip-3-leds-plus-photodiode-2014-10/
Not as cheap, seem ~ 80c in volumes, but much smarter...
It could allow Colour sense, for hidden menus and control ?
Or infrared reflective ? - use with a visible LED, if needed.
The problem is, you are using two DIFFERENT monochromatic devices, and each led is a different wavelength.
USUALLY, the emission and detection leds need to have identical wavelengths. (for the most part, this depends on the dope in the led die.)
You could use specialized devices, but i think people like the fact that leds are cheap, and with emission and detection using the same led, less i/o is used.