1
IR Pens / Re: New IR Pen Concept
« on: September 25, 2008, 06:43:34 PM »
Ok.. Dont get me wrong... I like his idea of using the connection with the mouse as the transfer of clikcs, but I think there's a better way to do it.
As a little background: Im a ham operator. Have been for 4+ years. I dont have my morse code license cause I dont use those frequencies, but I use the computer for translation of morse. I mainly use PSK31, a low bandwidth codec.
Well, I ask the question: Can we simulate "clicks" with ONLY irled, a switch, a few resistors, and a timing chip? I believe so.
Follow me on this: We dont need computer hardware like a mouse. We already have the wiimote camera that captures at X framerate. What if, instead, we turn the clicks to the computer, rather than the pen? After all, the computer has intelligence while the pen doesnt.
Lets say the FPS is 60, so 1 frame is .0167 seconds. Now, we keep the LED on and when a "button" is clicked, we turn off the led for X time.
Now, if we treat 1 frame off as l-click, we would get spurious l-click input. Instead, we need to do something like .05 s off (3 frames). This brings up a problem...
We either have the wiimote report 2-4 frames. So we could have 2-4 as l-click, 5-7 as r-click, and off-on-off-on-off intermittent pattern as middle. And by my numbers, 7 [email protected] 60 fps is .12 seconds, which is plenty acceptable for lag.
This would require a routine on input to catch on-off patterns with relevant pattern matching code, but this idea would shove the mouse clicking to where it needs to be: The processor.
As a little background: Im a ham operator. Have been for 4+ years. I dont have my morse code license cause I dont use those frequencies, but I use the computer for translation of morse. I mainly use PSK31, a low bandwidth codec.
Well, I ask the question: Can we simulate "clicks" with ONLY irled, a switch, a few resistors, and a timing chip? I believe so.
Follow me on this: We dont need computer hardware like a mouse. We already have the wiimote camera that captures at X framerate. What if, instead, we turn the clicks to the computer, rather than the pen? After all, the computer has intelligence while the pen doesnt.
Lets say the FPS is 60, so 1 frame is .0167 seconds. Now, we keep the LED on and when a "button" is clicked, we turn off the led for X time.
Now, if we treat 1 frame off as l-click, we would get spurious l-click input. Instead, we need to do something like .05 s off (3 frames). This brings up a problem...
We either have the wiimote report 2-4 frames. So we could have 2-4 as l-click, 5-7 as r-click, and off-on-off-on-off intermittent pattern as middle. And by my numbers, 7 [email protected] 60 fps is .12 seconds, which is plenty acceptable for lag.
This would require a routine on input to catch on-off patterns with relevant pattern matching code, but this idea would shove the mouse clicking to where it needs to be: The processor.