Help with a very troubled Focus FK-2001
Posted: 10 Aug 2021, 00:38
So a short back story. I found it at an estate sale in a box of old keyboards for 15 bucks. I probably should have grabbed a different one but this was the clickiest and most satisfying.
Cleaned the grime off the keys and the keyboard looked pristine minus a missing dust cover. PCB marks this as a 1992 model so it has the colorful alt, control, and shift keys, and a blank super key on the left hand side. Since it was a 5 pin din cable and I didn't have a converter on hand, I just immediately went for a soarer's conversion and flashed a pro-micro.
Cue my disappointment, every key worked but most worked badly, like there was a long delay on it. Some worked without delay, these are our control keys, the known working ones, proof the whole keyboard maybe isn't trash. I decided to reflow all the solder joints, nothing. So I begin replacing caps. I replace the single electrolytic and the many ceramic and tantalum caps minus one because it was a polar tantalum in a value I didn't have.
This produced positive results, but not perfect. The only non resistor or diode components not replaced are the main controller, a flipflop ic, a polar cap at 3.3uOhms, and what seems to be a two pin oscillator near the main controller.
Since I had some promising results, I haven't given up yet.
I hooked up the keyboards clock and data output lines to my oscilloscope. Here you can see what a well behaving key looks like vs a misbehaving key.
If you were to test this keyboard with the xev utility in linux, this would appear as a long delay between the HID press and HID release commands that the computer receives, similar to a held key. But most of the time the keyboard will release before its registered as a hold, basically just a slow key press. Sometimes they will get stuck and flood whatever text box is selected.
Now it seems the good and bad keys are grouped by some row/column configuration. For example, keys 1-4 are naughty, while keys 5-8 are good.
I have experience converting an old electric typewriter keyboard to USB. This involved removing the control MCU and manually determining the combo matrix layout and programming a replacement MCU to output the HID commands. This was annoying and I hope I wont have to do it again.
I'm posting here hoping someone else has dealt with this in the past and might have some wisdom. I'll also keep updating here as I try more things. My next step was to take a high res photo of the pcb and trace the traces in a photo editor to determine how the keys are grouped and if there's any logic to the bad vs good keys. I'm hoping that it could just be either the oscillator or capacitor but I don't have replacements for either at the moment and I'm hoping to keep costs down.
Cleaned the grime off the keys and the keyboard looked pristine minus a missing dust cover. PCB marks this as a 1992 model so it has the colorful alt, control, and shift keys, and a blank super key on the left hand side. Since it was a 5 pin din cable and I didn't have a converter on hand, I just immediately went for a soarer's conversion and flashed a pro-micro.
Cue my disappointment, every key worked but most worked badly, like there was a long delay on it. Some worked without delay, these are our control keys, the known working ones, proof the whole keyboard maybe isn't trash. I decided to reflow all the solder joints, nothing. So I begin replacing caps. I replace the single electrolytic and the many ceramic and tantalum caps minus one because it was a polar tantalum in a value I didn't have.
This produced positive results, but not perfect. The only non resistor or diode components not replaced are the main controller, a flipflop ic, a polar cap at 3.3uOhms, and what seems to be a two pin oscillator near the main controller.
Since I had some promising results, I haven't given up yet.
I hooked up the keyboards clock and data output lines to my oscilloscope. Here you can see what a well behaving key looks like vs a misbehaving key.
If you were to test this keyboard with the xev utility in linux, this would appear as a long delay between the HID press and HID release commands that the computer receives, similar to a held key. But most of the time the keyboard will release before its registered as a hold, basically just a slow key press. Sometimes they will get stuck and flood whatever text box is selected.
Now it seems the good and bad keys are grouped by some row/column configuration. For example, keys 1-4 are naughty, while keys 5-8 are good.
I have experience converting an old electric typewriter keyboard to USB. This involved removing the control MCU and manually determining the combo matrix layout and programming a replacement MCU to output the HID commands. This was annoying and I hope I wont have to do it again.
I'm posting here hoping someone else has dealt with this in the past and might have some wisdom. I'll also keep updating here as I try more things. My next step was to take a high res photo of the pcb and trace the traces in a photo editor to determine how the keys are grouped and if there's any logic to the bad vs good keys. I'm hoping that it could just be either the oscillator or capacitor but I don't have replacements for either at the moment and I'm hoping to keep costs down.