Hey everyone, its been a minute since I posted anything, but since I got some free time I want to show a failed mod I tried doing on a AT101W keyboard. I've taken up a lot of interest in learning more about building my own circuits and messing with keyboard hardware so I wanted to see if I could get the pro micro to work with this keyboard directly, not as a converter. I'm basing this mod off a previous (successful) mod I did on my IBM Pingmaster, you can see what that looks like
here. I used the pro micro specifically since I have quite a few of them and because of their price, but also since the pro micro doesn't have the right amount of pins to interface with the rows/columns of the keyboard directly, so it seemed challenging. Some of you may be able to guess why this didn't work right off the bat, but I didn't (and still don't) have a good idea about how a lot of stuff in hardware works, so it made me want to write about what I did and got wrong. Note that I did not look anything up on the AT101W before doing this, I may have done stuff that has already been done before but honestly I have no idea. All I know about the keyboard is that its easy to signal convert, which was not of particular interest to me.
TL;DR
Lets start off at how I began and what I thought
could work:
First I figured out what lines went where; the labels with the dots next to them are rows / columns I have checked.
Then I did some wiring so I could use the connections on a bread board.
This is where it gets complicated. The AT101W uses 17 total rows, 8 columns for each row. The way I was thinking, I thought it was best to figure out a way to expand the amount pins the pro micro can use to scan the rows and have the 8 columns be read directly by the pro micro. Some of you may know what is wrong with that idea, I'll get to that in a moment. But I came up with a way using one of the chips I have lying around, the 74HC595 or better known as a shift register. Using that specific chip was also something I did not think through very well.
I started by doing a simple test to check that I was capable of hooking the shift register up to the pro micro. The benefit of using the shift register is that it only requires 3 inputs, and then you can stack as many shift registers on top of that to get the amount of outputs you need. In my case I decided to use 4 inputs for the shift register to get better control of the clock lines, which would still allow for 8 inputs for the columns and 3 outputs for the LEDs. The gif image below is a single shift register on the right getting input from the pro micro and a inverter chip on left inverting the clock, indicated by the red LEDs.
This worked pretty well I thought, so I quickly moved on:
In above pic, I labeled all the wires before I went further to prevent confusion and expanded the shift registers to cover all the rows. The red LED on the far right of the bread board is a "overstep" indication, where if it is lit then the pro micro is scanning 1 or more rows too many. I fixed this later using a few capacitors on the clock lines. I also hooked up the LEDs that are on the keyboard and the columns themselves. I could now type using the keyboard, which I thought was great, but very quickly I realized I had overlooked a few things. First issue I noticed that certain combinations of keys when held down would nullify the output completely. It could be 3 - 5 keys, depending on the columns they're connected to. Second issue was that when I typed normally, occasionally the key on the same column of the key I just pressed would get pressed in the next row. So if keys Q, W, and E all use the same column and I were to press W, the key E would get sent directly after I let go of W.
I don't have an oscilloscope so its pretty difficult for me to realize / diagnose these problems, so I thought I had an issue where voltage was spiking because of the sudden changes in output was not being properly controlled. I slowed the clock down and the keyboard worked fine with a slower clock, so I thought it was a issue around there. I decided to go ahead with putting the circuit on a perf board to see if that would help with stabilizing the circuit. I've had a few perf boards lying around for a while now but this was my first time using them, so the soldering is dodgy.
The above picture of the perfboard I made had actually gone through quite a few renditions. I could write quite a bit about everything I tried, but this is already a long post so I'm going to keep it short. At first I just had the bypass capacitors by themselves, but I added a ton of them at the ends on each of the 8 columns (the grey wires) to see if that would mitigate the noise issue. It did actually, but didn't prevent the problem with the key in the next row being sent, just made it much less frequent. Also the issue where the output would nullify entirely when certain keys are pressed together hadn't changed at all.
So now its time to explain whats so completely wrong with the circuit here, and what I missed.
first, the extra keypress issue:
This issue is caused by the 74HC595 shift register itself, at least I think. I'm pretty sure though since I missed one crucial detail in the datasheet, that reflects my exact problem.
I think I will keep this circuit and test it properly with an oscilloscope when I get the chance, but for now I'm almost certain this is a "ringing" issue with the chip due to the load conditions. The next issue is essentially the same, except with the routing causing bus contention.
second, the output nullification issue:
This is an inherent issue with how the circuit I made was laid out. I thought the best method was to scan all 17 rows and read the signals from the 8 columns, much like in the Pingmaster. Though after doing some careful studying of how the keyboard itself was designed it seems to me that its actually supposed to be
8 rows scanning
17 columns, one row at a time. With the way the keys are connected, this method would prevent the keys from being nullified. I think the reason the keys were being nullified in the first place is because the pro micro would draw current from the same row for 3 different keys, AKA bus contention as specified in the datasheet, making it so that the voltage would become too low to be considered a high input for a keypress to happen. This would also explain why 2 of the 5 keys being pressed wouldn't get nullified, while 3 of them would disappear.
In conclusion, the best way to mod this keyboard directly is to get a proper controller that can handle input from 17 columns, and scan 8 rows separately. Using the teensy++ comes to mind, but I'm going to look around more carefully this time around for a proper chip before I try something like this again, though I think a teensy should do the job. For now though, I'll be using this keyboard with a signal converter
