LED Based User Input
groggory
Posts: 205
Here's my problem...
I'm building these devices that will be easily user configurable. This means the boxes they're in (standard project boxes) will potentially have 4 or 5 3-way toggle switches and some indicator LEDs.
I was thinking if I could use a momentary toggle switch to pick what thing they're doing and another toggle to choose states, I could use less pins. And same goes for indicator LEDs. I was thinking something along the lines of a shift register or something.
Can you guys think of the best way for me to deal with this state stuff with the lest number of panel mount switches and the least use of propeller pins?
Here's a picture of what I would like to make (I think).
(the two black things are momentary toggles)
I'm building these devices that will be easily user configurable. This means the boxes they're in (standard project boxes) will potentially have 4 or 5 3-way toggle switches and some indicator LEDs.
I was thinking if I could use a momentary toggle switch to pick what thing they're doing and another toggle to choose states, I could use less pins. And same goes for indicator LEDs. I was thinking something along the lines of a shift register or something.
Can you guys think of the best way for me to deal with this state stuff with the lest number of panel mount switches and the least use of propeller pins?
Here's a picture of what I would like to make (I think).
(the two black things are momentary toggles)
Comments
http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/rotary/List/0/SortField/4/ProductID/681/Default.aspx
Whether you use these, or momentary return-to-center-open SPDT toggle switches (another control input that I really like) you can generally apply them the same way: have one cog monitoring the control input, and accumulating the position into a variable in hub ram which the other cogs can read at any time. (the accumulation would simply reflect the total number of "up" clicks minus the number of "down" clicks, or cw/ccw clicks in the case of the rotary encoders).
What the toggle switches would allow you to do that the encoders wouldn't is to have an automatic-repeating case where the switch is held down. I have used a device which employed a single up/down momentary toggle switch to set a value with four sig figs. You could click the switch momentarily up or down to change by 1. If held down, it would change the value by 1 every 1/4 second, then if held down longer than 3 seconds or so would start incrementing by 10 every 1/4 second, then finally if still held down would start incrementing by 100. This requires a little bit of extra code but would allow you to do detailed input with just two pins.
You could also do the above with two encoders. I wrote an object which allows you to set a numeric value digit by digit, or a string, character by character: one encoder selects which digits place or character position you are setting, while the other encoder adjusts said digit/character. All the while the number is shown to you on the LCD, with a caret pointing to the digits place you are adjusting, to make it super intuitive. You could also combine a toggle/rocker with a rotary encoder, or even use a 5-position switch, etc. Figure out which combination best suits the types of inputs you'll be doing.
Right now the guy I'm working with is doing the coding and I'm doing the hardware. He basically does a closed loop.
repeat {
myVar=pin[5]
if myVar = 1 then
eventHandlerFunction(myVar)
}
that's his closed loop (pseudocode).
What's the best, fastest, most time senstive way of doing this? I'm sure this is a very very very common problem. Are there any interrupt-ish ways of handling changes in pin states?
The Parallax encoders look like they are higher quality than the SparkFun ones.
The shafts on the SparkFun encoders are too short to have them stick through an eclosure and still get the knobs on. I had to cut holes wide enough for the entire knob. The ecoder object that comes with the Propeller tools works great with these.
Duane
I don't know of any IP67 rated rotary encoders.
I could also do capacitive touch sensor rotary wheels I guess...but that'll increase the cost alot.
Use the LED's themselves as the switch!
http://forums.parallax.com/showthread.php?t=87566
....an excerpt from that PDF cited in this thread.
"Because LEDs are so commonly used as light emitters it is easy to forget that they are fundamentally PhotoDiodes, and as such, are light detectors as well."
I foresee your system could be controlled by simply touching the LED for the desired mode. That would simplify the panel design, and may have other unseen benefits.
I should do some experimenting on this...
The LED as button is not a good thing to use in conditions other than bright environments.
One could make a program that allows the user to "calibrate" the device so when in different lighting conditions, the difference between, no finger over the led, and having a finger over the led, could be identified.
I used leds as buttons in my black box sequencer, but I do not calibrate the leds to the lighting conditions that its currently in. I use CCFL tubes mounted above the leds.
http://forums.parallax.com/showthread.php?t=115258
If the lighting conditions change, like in sunlight, you might find that using leds as buttons is not a good idea, my device, uncalibrated, saw indirect light as a LED activation.
The encoder mentioned at sparkfun, is something similar to what I use, but I use a cheaper encoder that dosen't click when rotating, its from the same manufacturer and is cheaper. .49 cents a piece, the description says they are not also push switches, but the part# says they are (and they are, i ordered a bunch) These encoders also work fine with 3.3v.
http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=EN12VS20AF20BITECH7908585
But might random drops of water be interpreted as a finger activating the device?
Mayyybe. LOL. This thing would act crazy in the rain.
On a sidenote, it'd be awesome to have a disco-floor like thing out in the rain and watch it randomly light up as the rain came down on it.
Maybe we just invented a new kind of rain gauge.
Hah, this is actually a not so bad idea.... Kinda neat..
Due to reflection and refraction of the falling and changing rain drops, I would imagine it would kinda act nuts in the rain. It would have to be calibrated for the light available during that time of the day, or you could tweak it until you found its average sweet spot. (this is what I did)
Try it.
Or you could also run a photosensor to find out the current ambient light and then compensate in software for the known (and tested and accounted for) ambient light.
:-) Yay for feedback loops.
Huzzah!
http://www.youtube.com/watch?v=KzQW6qlGneg