Button scanner utility board

I've made a chainable button scanner board, similar to the one for potentiometers. Each one connects up to 64 keys/buttons through 8 connectors. When clocked, button statuses are output on a single pin. 

The button status is inverted, so a pressed button reads as 0/GND, an open as 1/V+ 

In addition, a breakout board is available, converting 8 columns + common row to 8 column pins + 8 row pins, making it easy to connect buttons using Dupont connectors.

The breakout boards are made with surface mount connectors to have a flush back, making it easy to glue/tape them to the back of the panel, close to the switches.

Prophet VS Keyboard controller PCBs v1.2 ordered

A batch of boards with the bugs from v1.1 fixed was just ordered from dirtypcbs. Fingers crossed they work this time!

Nailed it!

Finally got a stable, velocity sensitive version of the Prophet VS keyboard scanner working.

One last bug, double triggering of some notes took a long time an thorough research to figure out. I chose to quadruple the core speed from 16 to 64 MHz as some of the sends seemed to get delayed, possibly by the interrupt routines.

 However, this sees to have triggered bouncing in the top switch readings. As a key start switch always leads to a note on event (through timeouts), this would lead to notes that never got turned off. Why? Because off is only sent when the start switch opens, and this has happened long before the timeout if the key isn't really pressed.

The solution is to check if the start switch is still on before sending a timeout (or possibly resetting hasSentNoteOn on start key opening).

Debugging - each row corresponds to an event - note on/off, as read directly from the output bus. The bright green shows how long each note was pressed, the reds show notes that were turned on but never off. dark green-ish are where notes were turned off. Yellow shows notes with velocity 1, which means that velocity by itself didn't make the notes hang.

The reason velocity didn't work straight away wasn't that hard to find. I have always only measured the most significant bits of the data transmission to be able to use two probes for kybd and kyint. When timing out, the velocity had all the 6 msbits set to 0 so I assumed velocity should be 0. Not so. 0 is always read as "no more data" by the main mcu, so the minimum velocity has to be 1!

Decoding the 68b01 keyboard scanner

Returning to the Prophet VS service manual, I noticed that the output bus from the keyboard scanner runs through a set of latches. This means that bus communication is one way only. In addition to the bus, the only pins connecting the scanner to the main MCU are the KYBD and KYINT lines. Thus, the communication protocol should be fairly simple.

I connected logic probes to various parts of the 68B01 and its surrounding components. First to the CD4022 octal counter to see how the keyboard lines are scanned. Then to the rows to see which ones are connected to the first and second set of keys. I registered the data on the output bus while pressing keys to understand the protocol. I also checked the KYBD and KYINT lines while monitoring the data bus to see how the MCUs interacted.

The velocity was a bit trickier to get right. I needed to know the interval between hitting the first key and the second key, and at the same time registering the data bus output. I only have 8 probes on my logic decoder, but luckily, the velocity is 7 bit only, and by ignoring the least significant bit I could still get quite accurate velocity measurements.

What I found was that certain number of rounds of scanning the keys in between first and second keys made contact corresponded to a certain velocity. In other words, there is no 'free running' counter used for calculating velocity, one only needs to know how many times the keys have been scanned. This makes sense, as the only legal intervals corresponds to the times the keys are scanned.

I got a nice surprise when I made a plot of the velocity versus the scan cycle count. It turns out the velocity is a faux exponential curve, much like the way an analog audio-scale potentiometer works. For the first quarter of the measured cycles the velocity follows a steep line. For the other three quarters it follows a much flatter line. This, of course, makes calculating the velocity much easier (without the use of a lookup table. In that case any curve would be equally simple).

Plot of cycles vs velocity

(Disclaimer: The lines measured are not perfectly flat even if I try correcting for a +/- 1 error. This means that there is actually some kind of timer involved that is not connected directly to the keyscanner cycles. However, when recreating the program it will be sufficient to count cycles as long as cycle lengths are constant)

Here are some details about the scanner:

The keys are scanned column-by-column. The first column is turned on for about 70uS, the rest for 52uS. The total period (time between successive scans of the same column) is 432uS, giving a scan frequency of about 2.3kHz.

The three first columns and their scan pulses

The columns are scanned by clocking a CD4022 octal counter. Each clock pulse is approximately 2.5uS wide. The carry out from the CD4022 alternates between 0 and 1 every four clock pulses.

Data transfer works like this:

When the scanner has something to send, it lowers the KYINT line. At the same time, it puts the data on the output bus. Approximately 10uS later, the main MCU lowers the KYBD line. This turns on the 74HC367 transparent latches and puts the data on the databus, and at the same time signals to the scanner that it is reading data. KYBD stays low for about 0.25uS. The scanner waits an additional 10uS and then puts the next data byte on the output bus. The main MCU seems to read the data bus until it gets a 0 (0 on the bus is not a valid note on or velocity).

The data format is equally simple:

Note on is sent as two bytes: Note and Velocity
Note off is sent as a single byte: Note.

Both note and velocity are seven bit values. To differenciate between Note on and off, the MSB is always 1 for note on and 0 for note off. MSB is always 0 for velocities.

The lowest key on the keyboard, C0, is sent as x0100100 (x being 1 or 0 depending on note on/off), so the note value to send is simply 36 + key number.

Velocities:

Time t from key is pressed until it reaches bottom is x * 432uS + 571uS, where x is the number of times the first switch is scanned before it reaches bottom.

An approximation to the velocity transfer curve is as follows (not rounded):
[0, 1]: y = 127
[2,19]: y = 124 + (1867uS - t) / 80
[20,69]: y = 38 + (8779uS - t) / 570
[70, ->: y = 0

If more than 70 scan cycles are reached without the key hitting the bottom, a note on with velocity 0 is sent (and a note off is sent when the key is released later).

where
x = number of key scan cycles
y = velocity sent to master

This will of course not be an easily calculateable curve, so one is better off using a lookup table.

Top three: colum enable. Line four: key start switch, line five: key bottom switch. Pulses on key lines show when they are read. It seems that a lot of work is done when the first switch is turned on, making the initial delay longer than normal.

Important I/O pins:

Pins 13-20 corresponds to row 0-7 of the key press start switches
Pins 37-30 corresponds to row 0-7 of the key at bottom switches (NB: reverse order!)
Pins 22-29 are the output data bus pins
Pin 8 is clocking the CD4022 column selector
Pin 9 reads the carry bit from the CD4022
Pin 12 is the KYINT bit that must be set low before data transfer
Pin 39 is the KYBD bit that can be used to detect that the master reads the data.

Please don't butcher your synths!

A friend of mine recently brought me a Prophet VS he bought some time ago. The synth had some serious issues - while it worked perfectly over MIDI, 24 of the keys on the keyboard did not work as they should. 16 of the keys did not work at all, while 8 worked but always triggered the notes at maximum velocity. He considered selling the synth, but I was intrigued by the problem and asked him to wait for a while so I could look into the problem.

After consulting the service manual, I quickly realised that the keys in question were connected to three row-input lines of the keyboard scanning circuit. This got my hopes up, as it could simply be a matter of a few corroded or short circuited data lines.

I opened up the synth and within seconds came to the conclusion that it had to be something way more serious. Someone had, quite visibly, tried to fix this synth before. Aside from the fact that most of the screws holding the lid were missing, there were a few modifications, repair jobs and even a custom replacement for one of the CEM5580 sample and hold chips. Not a problem in itself, but surely a sign that this synth was in need of some love and care.

This is probably a factory fix but still looks funny

This could also be a factory fix, but the left resistors look horrible

Someone has smudged the print on this SaH chip. Maybe we could do a finger print analysis?

One of the CEM5510s has been replaced with a cool looking mod.

The biggest shock came when looking at the keyboard scanner chip. This chip, a Sequential Circuits 68B01, is a rebranded (or cloned) motorola 6801 microcontroller. Take a look at the pictures below:

Someone has cut deep grooves into the packaging and soldered new pins to the exposed internal connectors! I can only guess why - perhaps they cut the legs to get the chip loose from a PCB instead of trying to desolder it, or maybe one or more of the legs broke and they had to dig into the chip to reattach it. Whatever the reason, the person doing this must either have been well informed and highly competent, extremely brave or just desperate. The 68b01 is a very rare chip, and replacing it with a off-the-shelf 6801 will not work as it contains custom firmware. I guess if I owned this synth and the chip died, I could have tried something similar, after all you have little to lose if it does not work in the first place.

The chip even had a small wire connecting the first and second key switches for one of the rows. Now, the first switch detects when the key leaves the top position and the second when it reaches the bottom. The time between is used to calculate velocity. When they are connected, the effect will be that the synth thinks the key instantly hits the bottom position. This explains why 8 of the keys only played at maximum volume.

I tried resoldering the pins and even removing the wire, but this did not help. The chip is defective.

Luckily it seemed that the only defective parts are the row inputs. The chip still sends keypresses for most of the keys, which means it would be possible to decode the protocol. This lead to the only sane conclusion - I had to create a custom drop-in replacement. Challenge accepted!