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.
Help with a very troubled Focus FK-2001
-
- Main keyboard: Ducky 10kl
Small update, grabbed a logic analyzer and decoded the ps/2. Initial findings are somewhat concerning, but also a little confusing.
Here is a sample of a good hit: and here's a naughty one As you can see, the noise after the hit is actually the host communication requesting a resend of the last data.
I need to take more data to see if the messages actually are getting corrupted enough the pro-micro cant read them(but the logic analyzer can), or if this is an error on the converters end. I have a spare pro-micro to flash to test it out, its possible this one is just no good.
Here is a sample of a good hit: and here's a naughty one As you can see, the noise after the hit is actually the host communication requesting a resend of the last data.
I need to take more data to see if the messages actually are getting corrupted enough the pro-micro cant read them(but the logic analyzer can), or if this is an error on the converters end. I have a spare pro-micro to flash to test it out, its possible this one is just no good.
-
- Main keyboard: Ducky 10kl
So I may have figured it out.
According to the PS/2 timing standard, the clock frequency range of the protocol can run from 10KHzz to 16.7KHz, so a min/max allowable clock period being around 60-100 µs.
I'll upload the standard just for documentation sake.
Now, lets look very closely at the clock line of the keyboard, shall we? What we have is an uneven clock, with the largest active time being about 20µs too long, and overall increasing the max allowable period by 20%.
This is consistent across the good and bad keys.
So why are there some keys that work and some that dont despite the clock always being screwed up? beats me, I'm going to keep looking into it but something tells me I need to order some fancy tantalum caps with a low tolerance to get this oscillator back on track.
According to the PS/2 timing standard, the clock frequency range of the protocol can run from 10KHzz to 16.7KHz, so a min/max allowable clock period being around 60-100 µs.
I'll upload the standard just for documentation sake.
Now, lets look very closely at the clock line of the keyboard, shall we? What we have is an uneven clock, with the largest active time being about 20µs too long, and overall increasing the max allowable period by 20%.
This is consistent across the good and bad keys.
So why are there some keys that work and some that dont despite the clock always being screwed up? beats me, I'm going to keep looking into it but something tells me I need to order some fancy tantalum caps with a low tolerance to get this oscillator back on track.
-
- Main keyboard: Ducky 10kl
A short slightly off-topic reply for someone who might find this in the future. If your model has a super key sans logo and it either outputs a backslash in windows or a < in linux, the key is mapped to the HID code 0x64. So in a soarer's converter config, a simple remap would be:
It does feel like I'm speaking into the void on this thread but if it helps someone avoid a "wisdom of the ancients", then I'll be satisfied.
...despite that basically being soarer's converter in a nutshell...

Code: Select all
remapblock
EUROPE_2 LGUI
endblock
It does feel like I'm speaking into the void on this thread but if it helps someone avoid a "wisdom of the ancients", then I'll be satisfied.
...despite that basically being soarer's converter in a nutshell...

-
- Main keyboard: Ducky 10kl
I've tried a few different USB cables and have tried a few different machines.jsheradin wrote: 12 Aug 2021, 20:47 Definitely some weird behaviour. Have you checked that the board is getting enough power? From the pictures is looks like you are powering it off the Vcc pin on the pro-micro. Have you tried powering it off the RAW pin? What about a shorter USB cable/different port?
I did not think to try the raw pin, I was under the assumption that was an input but I just looked it up and it also can be an output. I'll give that a go!
Edit: No difference. The Raw pin and VCC are both putting about 4.6-4.7v. once attached to the keyboard, around 4.5v. I do wish I had a 5pin din -> ps/2 so I could test this sans converter.
- jsheradin
- Location: USA
The 8049 datasheet says VCC should be 5V +/- 10%. If it's actually dropping to 4.5V you're at the absolute limit. The RAW pin would be dropping due to a schottky diode so ~4.7V is expected but the regulated VCC should be bang on 5V if jumper J1 is closed. I believe some cheaper micros don't have J1 soldered from factory. Might be worth a shot; I usually use Teensys so I'm just guessing.dualrange wrote: 13 Aug 2021, 03:53The Raw pin and VCC are both putting about 4.6-4.7v. once attached to the keyboard, around 4.5v.jsheradin wrote: 12 Aug 2021, 20:47 Definitely some weird behaviour. Have you checked that the board is getting enough power? From the pictures is looks like you are powering it off the Vcc pin on the pro-micro. Have you tried powering it off the RAW pin? What about a shorter USB cable/different port?
-
- Main keyboard: Ducky 10kl
jsheradin wrote: 13 Aug 2021, 05:24The 8049 datasheet says VCC should be 5V +/- 10%. If it's actually dropping to 4.5V you're at the absolute limit. The RAW pin would be dropping due to a schottky diode so ~4.7V is expected but the regulated VCC should be bang on 5V if jumper J1 is closed. I believe some cheaper micros don't have J1 soldered from factory. Might be worth a shot; I usually use Teensys so I'm just guessing.dualrange wrote: 13 Aug 2021, 03:53The Raw pin and VCC are both putting about 4.6-4.7v. once attached to the keyboard, around 4.5v.jsheradin wrote: 12 Aug 2021, 20:47 Definitely some weird behaviour. Have you checked that the board is getting enough power? From the pictures is looks like you are powering it off the Vcc pin on the pro-micro. Have you tried powering it off the RAW pin? What about a shorter USB cable/different port?
Huh, I looked into this real quick because I assumed it was for the working voltage,
"Even the Pro Micro schematics claims about the SJ1: "Closed for 5V Board" and "Open for 3.3V Board". This is misleading: the jumper is not for chosing the working voltage." https://golem.hu/guide/bridging-j1-pro-micro/
My next step will be skipping the regulator since it will always be provided a regulated 5 volts.
-
- Main keyboard: Ducky 10kl
Maybe final update:
I gave up on the soarer's firmware, built and loaded up the tmk ps/2 -> usb firmware and its working a lot better. I'm getting some double presses on the space bar but otherwise the keyboard is working a lot better. I just need to figure out how to remap the EUROPE_2 key to left_gui, I know TMK has a keymap editor but since it's one key, i'm hoping I can just switch a scancode mapping.
Another edit:
If you find this and want to get this keyboard working with tmk and have a useful superkey, you need to edit unimap_trans.h in the ps2_usb directory(assuming you're doing ps2/usb conversion.
You need to change the 61st entry in the big unimap table from "UNIMAP_NUBSP" to "UNIMAP_LGUI".
I'm sure there's a way to do it involving the fancy keymap editor but I didn't have the patience to learn yet another tool.
Those cool double shot color coded keys made this all worth it
I gave up on the soarer's firmware, built and loaded up the tmk ps/2 -> usb firmware and its working a lot better. I'm getting some double presses on the space bar but otherwise the keyboard is working a lot better. I just need to figure out how to remap the EUROPE_2 key to left_gui, I know TMK has a keymap editor but since it's one key, i'm hoping I can just switch a scancode mapping.
Another edit:
If you find this and want to get this keyboard working with tmk and have a useful superkey, you need to edit unimap_trans.h in the ps2_usb directory(assuming you're doing ps2/usb conversion.
You need to change the 61st entry in the big unimap table from "UNIMAP_NUBSP" to "UNIMAP_LGUI".
I'm sure there's a way to do it involving the fancy keymap editor but I didn't have the patience to learn yet another tool.
Those cool double shot color coded keys made this all worth it