I've salvaged a fully-mechanical keypad from a 1970s Soviet calculator (Быстрица-2) and am modifying it to generate digital signals. I've created a baseplate for the keypad with an array of photo interrupters that are activated by the mechanical keys when pushed. These signals will travel to analog inputs on an Arduino, which will then use them to control an array of addressable LEDs (Adafruit NeoPixels). The correct combination of depressed keys will trigger a solenoid.
The end goal is to make an 1980s-style door passcode unit with an LED display. This project is inspired principally by the security keypad tech we saw in so many films of that era (Wargames, et al.).
I've finally got a prototype up and running using an ATmega. The LEDs are behaving well, but as you can hear in the video, the tones sound very garbled when responding to button pushes (they sounds fine in the power-on test sequence). I'm 95% percent sure I know what's happening: the unit is scanning many times per second to see if a button is engaged. When a button IS engaged, it's playing that tone many times a second, which leads to audio distortion. The solution lies in the code, which is my weak area. I'm fairly certain the solution involves proper use of buttonState.
I'm currently waiting for parts to arrive (shipping to Tbilisi, Georgia, from the US takes a few weeks) and while staring at the project on my workbench I had a small "aha" moment. I realized that my method for connecting the keypad to the Arduino was absurdly primitive: I was using an analog input for each key. That would be like having a computer keyboard with sixty wires coming off it. I see no reason I can't use the method that nearly all modern keyboards use, where rows and columns of keys form a matrix. This would take me from using 11 wires (one for each sensor) to seven wires (one for each row and column). But instead of the keystroke trigger being high, with my design it would have to be be low (the photo interrupters stop sending a signal when they are interrupted).
This would involve a small hardware modification from my current layout, which is no problem, but the code would be substantially different. Coding has been the biggest challenge for me on this project, so for now I will push ahead with my original strategy (one analog input per key). Once I have a working prototype I'll evaluate ways to improve it for Mk II.
Still stumbling a bit with the Arduino code. I had a breadboard prototype working last week with two sensors, two LEDs and a buzzer. But when I expanded the prototype to include 11 sensors and LEDs, the code no longer works as intended. Most notably, the buzzer appears to be trying to play more than one note at a time.
Digging through one of my bins I found a good candidate for the "screen" that will show the LEDs when keys are pushed: the translucent front plate that went over the CRT on an old oscilloscope. It's the perfect size and I've decided to expand the matrix of LEDs to an 5x4 array to make it seem more natural.
Thank you! The physical properties of the shafts immediately suggested a photointerrupter solution, though I don't want to celebrate too early, as we haven't still yet seen a test run. Before I landed on the photointerrupters I was looking at ways to build in a physical contact point for each shaft—a variation of the "mechanical" keyboards we use today. But this would be less optimal as that mechanism would likely fatigue or corrode over time, especially given this project's low budget character.
I'm a bit surprised that keyboard technology hasn't incorporated optical sensors more widely before now. That's not to say opto sensors can't also fail, but at first glance they seem like a much more elegant solution.
Good idea using the photointerrupters like that. Lucky break that those - shafts? - extend down like that.