hawk.ro / stories / Replacing the Rohde & Schwarz PCA-Z1 keyboard

An interface to replace the Rohde & Schwarz keyboard

Good looking, but expensive and hard to find

Some older R&S equipment (mainly spectrum analyzers like FSA/FSAS) can use such a keyboard for entering various parameters while others, like LAS6, require it. Nowadays such a keyboard sells on ebay for over 100 USD, so maybe a cheap PS/2 would be better for a hobbyist.

R&S Interface

Connector pinout

The keyboard connects to the host equipment via a 6.3mm stereo jack with the pinout shown above. "Signal" is TTL level serial data, at 2400bps. All keys send a single byte and most of them send their corresponding ASCII code. There is no communication from host to keyboard.
However, the special keys send special (but still one byte) codes. And then there is the matter of the rotary encoder and various combinations. The following table list the special codes:

(Special) KeyNormalShiftCtrl
WheelEA/EBCA/CB8A/8B
F1-F10E0-E9C0-C980-89
Esc1B1B1B
Tab090909
Line Feed0A0A0A
CR0D0D0D
Del7F5F1F
BreakFFFFFF
Numpad 0-9B0-B930-39F0-F9
Numpad -AD2DFA
Numpad .AE2EFB
Notes:

The plan

Have a cheap and simple PIC (16F628A) receive data from the PS/2 keyboard, translate it and send it as serial data. An alternative approach would be to completely replace the keyboard controller inside a simple PC keyboard with a bigger uC (e.g. 16F1939) with enough I/O pins to scan the keyboard matrix itself, but this would be more complex for others to use, not to mention that each keyboard model is likely to use a different key matrix. Add a rotary encoder, the 2 LEDs (get as close as possible to the original!) and that would be it.

Keyboard layout

The standard US layout is most common here, so that's what I used, but the R&S is somewhat different. That means that @ and ^ are no longer directly available (a Shift is required). The problem is that Ctrl+@ sends 00h and Ctrl+^ sends 1Eh and who knows, maybe there is a piece of software that requires the user to press Ctrl+@ and expects that 00h. On the other hand there is no functionality lost in not having Ctrl+0-9 send the same codes as with no Ctrl pressed, so I decided that Ctrl+2 will send 00h and Ctrl+6 will send 1Eh. This might not be needed, but it didn't take much to implement.
Line Feed is missing, but Ctrl+Enter seems a good enough substitute.
Break is missing but Ctrl+Pause will send Break.

Hardware

Click to download schematic (KiCAD .sch)

As you can see from the above schematic diagram, there is not much to the hardware side of things. Some clarifications:

Software

Download: hex file for PIC16F628A

I had a vague idea about the strangeness of the PS/2 (in fact IBM PC-AT) keyboard protocol and scancodes, but the reality was more than I expected. Besides the backwards compatibility hacks (the most famous being that Pause key sends a special prefix, then the combination Ctrl+NumLock make and break, a total of 8 bytes) there are bizare design decisions, like using 2 scancodes above 80h, one of them for a perfectly usual key: F7 send 83h. Why? There are lots of unused codes under 0x80, I'm genuinely curious about this. I noticed this issue because I am using small 128 bytes lookup tables (total Flash memory for this PIC is 2KWords). So at least 83h for the F7 key require special treatment. I know that I could have changed the keyboard scan code set, but this doesn't work on all keyboards.

The R&S keyboard handles Caps and Num Lock functionality itself; the PC one doesn't. Sending commands to the keyboard was slightly more difficult than expected. However, solving this problem, means one more feature: Since the default repeat (typematic) rate on PC keyboards is quite low, Ctrl+Shift+F11 will set it to fast (250ms delay, 30characters/second). If this proves too fast, Ctrl+Shift+F12 will restore the default (500ms delay, 10.9cps).

Shift toggle was implemented as it is on both PC and R&S keyboards: with Caps Lock on, Shift+letter will produce lower case and with it off it will produce upper case; the same with Num Lock.

The end result

Replacement

Update 2016-09-15

Some time ago (around June), a R&S user from USA contacted me and asked if it's possible to use this adapter "in reverse" meaning using a R&S PCA-Z1 keyboard instead of an AT one. He further elaborated:

I am using a MS-DOS-based R&S instrument which accepts an auxiliary AT keyboard. The instrument has its only keypad and controls on the front panel, and the keyboard is used to supplement the keypad as well as for use when in native MS-DOS, which is necessary for file transfers.
[...]
From what I was reading from your webpage, the R&S PCA-Z1 keyboard has 3 electrical connections through the 6.35mm plug - +5VDC, GND and signal. There is no clock signal which is needed for bi-directional communications between the host and the keyboard.

Here is my thinking:

1. There must be a clock signal on the keyboard controller and if it is wired to the AT socket, perhaps it will make the keyboard work like an AT keyboard, with some restrictions such as non-mapped keys?

2. My requirements for keystrokes are limited to what is needed for this MS-DOS instrument, so I am not concerned about missing functions from keys that are not mapped.

3. It would be neat if the cursor control dial can be used to move the cursor around the 640x480 EGA screen on the instrument but that is not a must.

4. The instrument offers some ALT-key combinations and the PCA-Z1 appears to be able to accommodate that. Am I right?

His message and questions made me realize that my story is not clear with respect to what this interface means (or how different the PCA-Z1 is from standard PC keyboards. My reply (partially quoted below) hopefully clarifies things:

The PCA-Z1 has a completely different interface, both in terms of protocol: doesn't send key codes for any control keys, like shift, ctrl, caps/num lock and doesn't send pairs of codes for make/break, but a single code for each char; as well as electrical: the PC kbd is open collector, the R&S is fully driven TTL.

The PCA-Z1 has its own microcontroller inside (Intel D8748H, UV eraseable) and it's unlikely that it would have included code for anything more than it already does (scanning the keys and sending their ASCII codes).

So, for what you want there are 2 approaches, neither easy: either adapt my code to work "in reverse", that is receiving ASCII codes and simulating a PC keyboard, or adding an encoder to a PC keyboard.

For the former, I will publish the source code to my project in about a month (I want to make it better looking first) but it's PIC assembly, I don't know how you would be with it. However, to really understand what I meant with protocol, here's an example: for the character "!" the R&S kbd will send just one byte, the ASCII code of "!". A PC keyboard will have to send 4 bytes: make code for shift, make code for the key 1, break code for 1, break code for shift. The same with capital letters and so on and so forth.

I never got around to publishing the source, even this update comes almost three months after the e-mail exchange took place. However, if you need it, please let me know and I'll get to it.

Update 2017-04-05

Download sources: rs_kbd.zip

Someone asked me for the sources in order to use this with another type of PIC, so here they are. Be warned that the code is not very "pretty" - it is based on a previous experiment of reading AT (or PS/2) keyboards but I never got around to cleaning it - once was working it was declared "good enough". All the memory locations (and PIC specific constants) are declared in the main asm file (kbd2serial.asm), instead of using a separate header file, also bank switching is done by setting/clearing bits in STATUS register: this will not work with all PICs. Search for BCF/BSF instructions operating on STATUS register and replace with BANKSEL if needed. (of course, check for proper bank first, most hw specific locations vary from one PIC type to another).

Published 2016-05-29, last updated 2017-04-05 by Mihai Gaitos - contacthawk.ro