Adapting the keypad from a Soviet mechanical calculator (Быстрица-2) to generate digital signals.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
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.
Create an account to leave a comment. Already have an account? Log In.
Agreed, a very cool way to add your own electronics to this. It's basically state of the art too, since optical-sensors on keyboards is a popular development in consumer keyboards: https://hackaday.com/2019/11/18/optical-keyboards-have-us-examining-typing-at-light-speed-ish/
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.
Become a member to follow this project and never miss any updates
By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies. Learn More
Good idea using the photointerrupters like that. Lucky break that those - shafts? - extend down like that.