A (failed) AT101W mod

lilwebsite

17 Jun 2019, 18:37

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
Spoiler:
read the datasheet for chips carefully before you start soldering, and use a suitable chip for your project. If your chip doesn't have the correct amount of pins to interface with the rows and columns of the keyboard and you don't want to damage traces on the board to add diodes, it is likely not to work. 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.


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.
Spoiler:
markings.jpg
markings.jpg (1.48 MiB) Viewed 414 times
Then I did some wiring so I could use the connections on a bread board.
Spoiler:
wiring.jpeg
wiring.jpeg (158.02 KiB) Viewed 414 times
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.
Spoiler:
led1.gif
led1.gif (3.08 MiB) Viewed 414 times
This worked pretty well I thought, so I quickly moved on:
Spoiler:
setup.jpg
setup.jpg (1.76 MiB) Viewed 414 times
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.
Spoiler:
perfboard-front.jpg
perfboard-front.jpg (1.41 MiB) Viewed 414 times
Spoiler:
perfboard.jpg
perfboard.jpg (1.52 MiB) Viewed 414 times
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.
Spoiler:
datasheet-detail.jpg
datasheet-detail.jpg (70.62 KiB) Viewed 414 times
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 :lol:

Hak Foo

18 Jun 2019, 06:26

The AT101W doesn't have diodes, though, so there should be little electrical difference between 17x8 and 8x17. I could see some potential weirdness where they tried to spread around keys to avoid blocking on common combinations and that got undermined by rotating the matrix, but I'm not sure about that.

The Pingmaster uses a demultiplexer so you just need 4 pins to handle 16 rows. Soarer's Controller Firmware has a prebuilt config file this design. If the Teensy has 20 I/O pins to work with, you could do 17 columns, then direct 3 pins into a multiplexer to get 8 rows.

lilwebsite

18 Jun 2019, 10:55

Hak Foo wrote:
18 Jun 2019, 06:26
The AT101W doesn't have diodes, though, so there should be little electrical difference between 17x8 and 8x17. I could see some potential weirdness where they tried to spread around keys to avoid blocking on common combinations and that got undermined by rotating the matrix, but I'm not sure about that.
No you're right, a lot of the keys were spread out between the lines, specifically the left/right control and shift keys which have their own lines for each respectively. I'm not sure of the electrical difference, its hard for me to measure that. I'm going to keep the circuit I have and test it at some point to see whats going on, I just don't have the equipment for that ATM.
Hak Foo wrote:
18 Jun 2019, 06:26
The Pingmaster uses a demultiplexer so you just need 4 pins to handle 16 rows. Soarer's Controller Firmware has a prebuilt config file this design. If the Teensy has 20 I/O pins to work with, you could do 17 columns, then direct 3 pins into a multiplexer to get 8 rows.
I'm probably going to do something similar to this since I have 3 - 8 line de-multiplexers which is perfect. Don't know when I'll get around to it, since I'll probably have it converted for now, though I plan on attempting this mod again. As for Soarer's firmware, I'm aware of it, though I'm not interested in getting the keyboard to work necessarily. I'm a programmer, its what I do, so getting my own firmware to work with a keyboard is something I take a lot of enjoyment out of :ugeek:

Post Reply

Return to “Workshop”