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!

More Prophet VS Hardware issues.The

The VS I have been working on must have been used as a training kit for monkeys learning electronics. There are so many weird errors and botched jobs inside. After finishing the keyboard scanner, 8 keys (g#2 to d#2) still didn't work so I disassembled the keybed, initially leaving the pcb in place, to figure what was going on.

From the schematics it is clear that all these are connected to row 20 in the cable (I knew from earlier that it was the start key switch that was the problem, not the end).

I started by measuring between the diode kathode and pin 20 and got nothing. But the same was true for the working lines! Turns out there is an inaccuracy in the VS service manual - the diodes are before the key switches, not after, so it is the columns that are common to the diodes, not the rows.

Even if I tried pressing a key, my multimeter's connection checker didn't beep. I gave up and unscrewed the pcbs to get a closer look. It quickly became apparent where the error was. I also figured out why the connection checker didn't work: the switch pads have a tiny resistance. Also, I could see that both the top and bottom switches are in fact in the same place. Assumingly, the outer ring that makes the connection is pressed down slightly slanted, connecting two of the poles before the other two.

What happened here?!

Scraping away a bit of solder mask from the broken trace enabled me to solder a new wire to bypass the fault. It worked straight away.

After (of course, after...) assembling the keyboard I heard and felt a clicking from one of the keys. I opened it up again and discovered a bent spring. How it is possible to bend this is beyond me, it was really hard bending it back. It only strengthens my monkey theory. Anyway, the synth is now fully operational and will be returned to a happy owner.

The bent spring in the middle black key

The bent spring

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!

Pro-one rack external IO diagram

Planned external inputs and outputs. Top ones are normal analog IO, bottom ones are midi and special keyboard and mod/pitch wheel IO.

Internal signal path diagram for Pro-one rack

Internal signals from card to card in the planned Pro-one rack. As the sheet indicates, the plan is now to build five cards, with the functionality spread as indicated. External signals and signals going to the front panel are not shown, except where indicated by "via switches".

Pro-one rack front panel sketch

Not much to say - just made an initial sketch of the pro one "rack" front panel. The panel is 5U high and 430mm wide, which leaves room for rack ears to be added later - meaning that the machine can be used both as a desktop version and as a rackmounted one.

Pro-one gate and seq/arp

The Pro-one has a nifty system for controlling the arpeggiator and sequencer. It all runs through the gate circuit, so here are a few details about the gate and trigger circuit, deducted from the schematics (as I have no real Pro-one to compare with).

Sequencer and arpeggiator

First of all, the sequencer/arp speed is controlled by the speed of the LFO, which is not uncommon on old synths. The triangle output of the LFO runs through HALF of switch S125 (Seq) or S127 (Arp) when these are in active modes. The other half of the switches are connected to the microcontroller, to read the sequencer or arpeggiator mode. From the switch, the triangle wave is connected to the Gate output, and thus controls the gate directly. So, in sequencer or arpeggiator mode, a new gate signal is sent for every cycle of the LFO. The gate signal from the LFO is NOT sent to the Gate out jack. I don't yet know the shape of the LFO-gate signal when it arrives at the gate. It starts out as a triangle wave, but runs through a transistor and a capacitor on the way.

The square wave of the LFO is connected to the microcontroller as the "clock". One can assume that this is used to control the arpeggiator up/down motion and sequencer advance. More on the clock a little later.

The trigger signal is normally controlled from the microcontroller, and is probably syncronized to the clock programatically when the synth is in sequencer or arpeggiator mode.

The clock signal may be overriden by both an external gate input and the -ext and Audio Gate inputs. how the sequencer/arpeggiator works in these cases is unknown to me at the moment.

Gate/Clock input, Ext and Audio gate

An external gate signal input is available. It is connected to the clock input of the microcontroller and not directly to the gate. As such, the fact that the gate signal comes from an external source is unknown to the microcontroller, which is the reason I don't know how the arpeggiator and sequencer act in this mode.

As the ext and audio gate signals are connected to the clock in, the same is true for these. However, if no external gate/clock is connected, one must probably turn down the LFO speed to 0, to prevent the LFO from interfering.

Trigger

The trigger sets off the envelope generators that control the volume and filter frequency (The envelope generators then run through the Attach and Decay-parts of their cycle, and stays at Sustain level untill the gate signal goes away, which triggers the Release-mode). The trigger is controlled directly by the microcontroller in normal mode, but can be overridden by Mode drone or Mode repeat/ext.

Mode drone

The mode drone switch is connected between the microcontroller and the trigger and gate signals (the gate out signal is tapped before the switch and is not affected by mode drone. When the switch is in the drone-position, both trigger and gate are permanently connected to +5v, keeping them "open" at all times, which lets through any sound coming from the mixer.  When the Mode drone switch is in the off position, the gate and trigger signals are unaffected.

Glide

Glide is not directly a part of the gate circuit, but it is controlled by the gate. As with gate out, the control signal is tapped before the mode drone switch and thus not affected by mode drone. When the glide switch is in auto-mode, the gate is connected to the glide circuit, when it is in normal mode, the glide circuit is fed a constant signal of +5v through the switch.

Repeat/Ext

The Mode repeat/ext switch is connected between the microcontroller and the trigger/gate. As it is connected BEFORE the gate out, it affects the gate out signal. When in normal mode, both trigger and gate are passed through directly from the microcontroller. When the switch is in repeat mode however, both trigger and gate are connected to the clock in. This means that they are controllable directly by the Audio gate, gate/clock in and LFO! In LFO mode, notes are retriggered on every LFO cycle, regardless of wether or not a key is currently pressed. It also means that the gate and trigger cannot be controlled by the microcontroller when in repeat mode, which in turn means that the keyboard keys only affect the pitch, not the triggering of notes.

Gate out

The gate out jack is tapped before the mode drone switch, but after the repeat/ext switch. It is thus not affected by Mode drone, but will be affected by any external clock input when the repeat switch is in repeat mode. The gate signal from the Seq/Arp switch (LFO triangle wave) cannot reach the gate out directly, so in seq/arp mode the gate out is connected to the microcontroller. I do not know if the microcontroller outputs any gate signal when in seq/arp mode.

Pro one mix and random board finished

Just finished the second board for the Pro-one project. This one contains the oscillator mixer, a modified noise circuit, a sample and hold part and the output buffer. There are so many ins and outs on the upper part of this card that I couldn't find room for the top right screw hole... Oh well.

I think it will take at least two more boards, perhaps three, to get all the necessary circuitry in place. And that excludes the front panel that will hold the pots and switches, and any output boards.

Pro one oscillator board finished

Just finished revision 1 of the Pro one oscillator board! It looks quite good and fits on a 10 x 8 cm PCB. It contains the CV-mixers and two oscillators. Next up is the audio mixer, envelope follower, reference voltage generator and noise generator.

Sequential Circuits Pro One - Octave selection rotary switches

The octave selection rotary switches on the pro one works a little differently than most other.

They are in fact four position, DP switches, meaning that they have no common pin, the rotary action short circuits two and two poles.

The way the selector works, is that it selects 0, 1, 2 or 3 connections to the 1V reference voltage. In the various positions of the switch it means that:

• Pos 0 : pin 10 is connected to pin 2, and pin 5 is connected to 6, connecting the octave summer to R161, which in turn is connected to ground.
• Pos 1: pin 1-2 and pin 6-7 are connected, connecting the octave summer to the reference voltage through R162 (100k)
• Pos 2: pin 2-3 and pin 7-8 are connected, connecting the octave summer to the reference voltage through R163 and R164 (100k * 2)
• Pos 3: pin 3-4 and pin 8-9 are connected, connecting the octave summer to the reference voltage through R162, R163 and R164 (100k * 3)

Mouser.com sells a C&K switch with the number R20407RN02Q. I don't know if the kind of shaft is the correct length (it is .500", for a total height of about 1.05"), but the switching mechanism is the correct one. The same switch is sold by digi-key.com too.

NB: The switch has a 0.25" (6.35 mm) shaft. Other pots may use 6mm shafts.