deskthority

Hi Everyone,

I have recently became interested in building my own protocol adapters for keyboards. I was curious what is the best method for figuring out what data a keyboard actually puts out if it's an unknown protocol. In my mind it would make sense to power on the keyboard and then use an oscilloscope to be able to read the data coming out of the data pins on a key by key basis. I am hoping that there is an easier way tho! That would quite literally take hours to do per keyboard LOL Any advice is greatly appreciated!!!

Cheers,
--Given

What you want is not an oscilloscope but a logic analyzer. For some keyboards, yes, you will have to press every key and record the result. For others, you'll quickly discover a pattern.

Hi. You actually need a digital analyzer more than an oscilloscope. Despite some protocols can be very weird and also have weird limitations, you will always have a VCC pin, a GND pin and at least one data pin, often a clock pin too. What you need to do here is power the keyboard and connect your logic analyzer to the rest of the pins (as far as you have enough channels), hoping that when you hit a key you'll read how their HIGH and LOW state look. You will have to make a diagram for every key, which can be a pain in the ass.

The best method is of course to follow the old documentation for the device... which is how most protocol adaptors have been made.

Other than that, there are only so many ways that a serial protocol can work. First check the components, to see which wire is which and what voltages are needed. (99% use 5V but there are some odd ones out there)
I think also most old keyboard protocols have the keyboard send data without the host having to initiate anything. So start sniffing with the oscilloscope, and once you have figured out which serial protocol (baud rate, start, stop bits, clock etc.) is being used, then you shouldn't need to use the oscilloscope much.

Then wire up and program a microcontroller to receive data - and produce raw bytes to your computer.
Keyboard firmwares out there tend to send diagnostic messages in "vendor-defined" report fields over USB HID to a host program: HID Listen or QMK's HID Console.
Then you can start typing keys and write down what every key does.

Thanks for all the advice! I'm searching around ebay now for a second hand scope and logic analyzer now LOL It seems like something that will be fun to do so I'm gonna play around with it all!
Thanks again!
Cheers,
--Given

To be frank, unless you also want to get in to vintage test equipment, you'll probably be better with one of the cheap USB interfaces (example). For one thing, once you figure out the format, you can just export the scan code data rather than reading traces off a screen.

kps wrote: ↑

03 Oct 2020, 17:09

To be frank, unless you also want to get in to vintage test equipment, you'll probably be better with one of the cheap USB interfaces (example). For one thing, once you figure out the format, you can just export the scan code data rather than reading traces off a screen.

That's a really good point I didn't consider. That would make life much easier. I'll actually go that route to begin with due to it being easier and much cheaper LOL Logic Analysers aren't cheap LOL
Cheers,
--Given

PlacaFromHell wrote: ↑

02 Oct 2020, 22:45

you will always have a VCC pin, a GND pin and at least one data pin

Even that isn't universally true. It's possible to share Vcc and data.

I recently converted external numpads that work by:

• Having the terminal disconnect power periodically and running off capacitors to actually do the data xfer.
• Pulling Vcc low for data (and again running off caps).
• Stealing power from multiple data lines, which therefore need to be kept high, but not all at the same time.

It's still a reasonable assumption when starting out with an unknown board, though.

download and install SwitchHitter. It will show scan code for every key press.

anthonymak wrote: ↑

09 Oct 2020, 04:24

download and install SwitchHitter. It will show scan code for every key press.

This? It's completely irrelevant to OP's questions. (a) It shows Windows' view of keys, and if Windows is seeing keys, you already know what the keyboard sends; and (b) the Windows codes it shows are not actually the codes the keyboard physically sends.

1) figure out voltage levels and power the device.
2) try 300 baud 8N1,
2.1) if not - 1200
2.2) if not - invert the signals between your UART and keyboard.

At this point, with 99% probability you'll have some form of bitstream, which is relatively easy to decode.

2 and 2.1 solved faster by 2-channel scope on RX and TX lines, trigger on mid-swing, having slow enough sweep to see the whole packet. Pressing different keys and counting transitions will get you pretty good idea about interface speed and number of bits.