Several years ago I came across a number of obsolete Pocket PC handhelds and accessories at a surplus sale. While the PocketPCs themselves weren’t worth keeping due to the dead batteries and slow processors, I held onto a compact portable keyboard with a 9-pin serial connector made by a company called iBIZ. I’m finally getting around to hooking the keyboard up and seeing if I can get it to work. In this post I’ll document the process of connecting to the iBIZ KeySync keyboard and decoding its protocol.
Identifying the hardware
The KeySync has a power switch on the left and runs on three triple-A batteries. Based on some search results from 2000 and 2001 we can be reasonably sure the keyboard uses RS-232, but I was unable to find any documentation on the protocol or baud rate.
We’ll use a standard USB-to-serial adapter to connect the keyboard to a desktop running Linux to figure it out for ourselves. The first step is figuring out what serial pinout it needs (straight-through or null modem), and what baud rate. When in doubt about an older serial device, 9600 is a good first choice to try (115200 or 57600 are likely speeds for newer RS-232 devices). We’ll set up the serial port for raw I/O, 9600 baud, 8 data bits, no parity, and 1 stop bit (9600/8N1):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
Now we pick either a straight-through adapter or a null modem adapter (which swaps the TX/RX and handshaking lines), and try to read data from the port.
Decoding the protocol
Chances are the protocol will use some bitwise encoding for the keys and other
information, so we want to print data we receive in hexadecimal. The od
tool
is useful for this.
1
|
|
The straight-through adapter gave no results, so I switched to the null modem adapter.
Success! We have bytes!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Each key produced one byte on press (make), then one byte on release (break).
No amount of holding a key produced any repeats. It looks like the 0x80
bit
indicates a press when set, and a release when not set. Then A is
0x00
, S is 0x01
, etc.
There are also six function keys, F1 through F6, which produce a make-make-break-break sequence. The first key is Alt, followed by the corresponding number key (e.g. Alt+1 for F1):
1 2 3 4 |
|
This doesn’t match either the XT or AT scancodes. There might be some other keyboard protocol that matches this, but it will be faster to write decoding code from scratch than to find a matching protocol. We just have to press every key and make a note of its key code, then arrange them in a nice table:
1 2 3 4 5 6 7 8 9 |
|
A few lines of C code later, plus another table for character values when shift is pressed, and we can type on the console:
I couldn’t find documentation on the Fn key. I did discover that Fn+0-9 will type predefined strings related to the early-2000s Internet (and the Taiwanese origin of the keyboard):
1 2 3 4 5 6 7 8 9 10 |
|
Code
The code for a simple C program to read keypresses is on GitHub: https://github.com/mike-bourgeous/ibiz_keysync
A next step for an adventurous developer might be writing a driver for Linux’s input layer.