Ensoniq ESQ-1 dead keys

[thatsmithy]

Hello everyone.

I came into possession of an Ensoniq ESQ-1 that had a row of 8 dead keys. The 2nd highest C to the G# are all completely not responding. Now here's where it gets weird. I have tried everything and the kitchen sink to fix this thing. I have :
- Tested all the diodes, spring contacts, traces, and connector pins from the dead keys and some working keys on the keyboard contact board. When the spring is contacting the key contact bar, I to get continuity on my ohm meter(that all I had on hand).
- Replaced the cable between the motherboard and keyboard controller chip.
- Replaced the keyboard controller IC.
- Tested all the joints on the socket to the controller IC.
- Tested all traces from the keyboard ribbon pins on the motherboard to the controller chip.

All of this, and the it's been the same issue. Everything else appears to work flawlessly on this thing, and I would really like to have this thing fixed and not spend a bunch more of money fixing it(I don't want to take it to a repair shop).

Anyone have any ideas?

Thanks,
Alexander(ThatSmithy).

[rhino]

Those vintage Ensoniq boards can last for decades, then turn on you like a rabid hyena!

Try (if you have not already) a soft reset:

NOTE!!! you'll loose all user patches - save them first!
Press and hold RECORD, then press the top left button over the display. Answer YES to reset.

Next step - which I have NEVER needed is a hard reset:

Open the synth and with power OFF - short the battery for 10 seconds

Let us know.

[synthparts]

You should never "short" a battery. Disconnect one side of it if you really need to remove it from the circuit.

[thatsmithy]

Those vintage Ensoniq boards can last for decades, then turn on you like a rabid hyena!

Try (if you have not already) a soft reset:

NOTE!!! you'll loose all user patches - save them first!
Press and hold RECORD, then press the top left button over the display. Answer YES to reset.

Next step - which I have NEVER needed is a hard reset:

Open the synth and with power OFF - short the battery for 10 seconds

Let us know.

Thanks for replying rhino! I have not tried that. I will give it a shot hopefully tonight. I'll update when I am able to.

Alexander

[thatsmithy]

You should never "short" a battery. Disconnect one side of it if you really need to remove it from the circuit.

Thanks for the reply! I'll keep in mind if I need to hard reset.

[rhino]

Brian Frat! You jumper the battery to ground AFTER the current-limiting resistor going to the RAM.

For the METAL cased version:

Short right side lead of CR1 to C1


For the PLASTIC cased version:

Short the right side lead of C18 to LEFT side lead of CR3

Do the soft reset afterwards.

[thatsmithy]

Brian Frat! You jumper the battery to ground AFTER the current-limiting resistor going to the RAM.

For the METAL cased version:

Short right side lead of CR1 to C1


For the PLASTIC cased version:

Short the right side lead of C18 to LEFT side lead of CR3

Do the soft reset afterwards.

Alright, I just tried to hard reset and soft reset. After attempting what you suggested, I also disconnected one end of the battery as synthparts advised. Neither had any effect.

Alexander

[noiseg33k]

Hello just wanted to reach out and tell you if you need any parts, like a keybed, I have an entire esq for parts minus the dead power supply.

[thatsmithy]

Hello just wanted to reach out and tell you if you need any parts, like a keybed, I have an entire esq for parts minus the dead power supply.

Thanks noiseg33k. If I can figure out what may need replacing, I will keep you in mind. Doubt I'll be needing a keybed though. I just recently tested all of the traces and diodes on the board and they came up fine. We'll see I guess...

[opcode]

I recently acquired an ESQ-1 with the same issue and symptoms you described in the original post!

Did you ever get this resolved?! Or does anyone have any insight into why 8 keys might be dead in a row?!

I've tried cleaning the upper and lower contacts of the 8 keys, reseating the chips, deoxing and cleaning the j2 ribbon cable and key springs, etc, etc. It's driving me nuts!

[Rasputin]

Stick a logic probe on the 65002B (aka R1120-12, U1) keyboard controller chip to test pins 4-19. How do they behave?

I don't have an ESQ-1 keyboard in front of me to totally break this down with 100% accuracy, but:

Pins 31-38 should be the row return from the keybed itself. Pins 4-19 should be the column output which is sequentially strobed to activate groups of keys in the keybed. When you press/release a music key on the ESQ-1 then a signal is generated (of varying duration) and passed backed to the keybed processor.

The processor knows which column is currently being strobed, so it knows there is only one group of keys to which that row signal can belong to. So the processor compares the active column to the active row(s) and a keypress/keyrelease is generated depending on where the row/column intersects on the key matrix.

Putting a logic probe on the processor will tell you if it is strobing the column lines properly. For the columns, the signal comes DIRECTLY from the processor so there is no chance for anything else to go wrong. If all the column pins are not pulsing (on/off incredibly quickly) then the processor is messed up.

The rows are returned from the keybed so can be tested from the processor side, but if any are missing then that tells you there is a problem, but does not conclusively prove anything. To track down a row malfunction, the keybed itself must be tested. First test the row returns on the keybed side of the ribbon cable. If they are good then test on the processor side of the ribbon cable. If you get a differing result then the ribbon cable is bad or the header pins are corroded, etc.

If the rows do not activate on the keybed side of the ribbon cable then start looking at the individual diodes and traces for any non-working rows.

Edit: I have edited this because of a pin numbering error and to reduce confusion with the keypad processor.

[opcode]

Rasputin, thank you so much for your response!

If they are good then test on the 6500 of the ribbon cable. If you get a differing result then the ribbon cable is bad or the header pins are corroded, etc.

- I am a little new to the troubleshooting side of sytnhs. I just got an oscilloscope and a multimeter. What settings should I use, and am I just looking for a square wave output from the it sounds like? Would you know which exact pins i need to test, and what I should look for? It's the same dead key range described in the original post

If the rows do not activate on the keybed side of the ribbon cable then start looking at the individual diodes and traces for any non-working rows.

- Like a continuitity test with a multimeter on each side of the diode?

Would replacing both the 6500 & Ribbon Cable most likely solve the issue?!

[Baus]

Hi there,

Rainer Buchty has just released some good news about cloning the ESQ-1 keyboard processor. You might want to head over to the Ensoniq Users Group on FB to stay up to date!

Robin.

[Rasputin]

Rainer Buchty has just released some good news about cloning the ESQ-1 keyboard processor. You might want to head over to the Ensoniq Users Group on FB to stay up to date!

I had heard rumors about such a thing. I'm super curious how he approached that, and I'm excited someone finally did it because that topic has been on my mind for a while. Buchty rocks!

Would replacing both the 6500 & Ribbon Cable most likely solve the issue?!

I wouldn't recommended trying to source anything immediately. I would wait until you can definitively prove it is bad (or at least highly suspect) as they're not common ICs. I wouldn't want to take a spare processor out of circulation unless it is 100% needed.

The ribbon cable is absolutely suspect, so if you have one to swap out and test with then by all means it's worth trying. Alternatively, you can remove the ribbon cable, test each and every conductor with a continuity test (ideally while flexing the cable in various positions), and also polish up the cable header pins to remove any gunk.

As far as testing chip signals goes:

I already mentioned the pin numbers on the R1120-12 (65002B) to look at. One set (the columns) will change automatically and rapidly. So all column pins should be a square wave at the keyscan frequency. I don't know exactly what that frequency is, but it doesn't really matter. As long as the column pins aren't stuck high or low then they're probably good. Remember, you can test the columns directly on the R1120-12 chip legs because they're output directly from the chip.

Edit (4/30/17): Not that it really matters, but technically any individual column is inactive for the majority of the time and cannot be active for longer than [1/number of columns being scanned] -- in this case, each column must not be active for longer than 1/16 of the total column scanning time. So for the sake of clarity, this wouldn't really be a "square" wave, it would be a rectangular wave with a duty cycle less than 50%, but that's primarily irrelevant to troubleshooting such an issue.

When no keys are being pressed, the "row" pins should all be in the same state. And then when a single key is held down or released, one of the row pins should change between high and low (5V to 0V) while the rest stay the same. If you "rake" (glissando?) the keyboard then the row pins should "blip" as the keys from different rows are pressed and released. But as I mentioned, this is best initially observed from the keyboard PCB side of things because the row signals are sent as a return to the R1120-12 chip as an input whereas the columns are output directly by the R1120-12.

I probably didn't answer all your questions, but it's actually a fairly easy troubleshoot (famous last words) once you wrap your head around the idea that the whole keyboard thing is only an intersection of column/row in a matrix. The columns "flash" automatically because they're tightly controlled in a predictable sequence and time by the R1120-12. The rows turn on and off only when keys are pressed and released.

I believe each column corresponds to each key of a given note (all 'A', all 'A#', etc.) and each row corresponds to the particular octave (A3, A#4, B4, G6, etc.)

Since it's a matrix, if one of the rows or columns is dead then it will kill a set of keys at once. If you know how the matrix is arranged then it is possible to tell if it's a dead row or column and even which specific row or column is dead solely by which keys are not working. The dead keys will have either a particular row or particular column in common. From there, you can trace that row or column back from the corresponding pin on the R1120-12 while making sure each point of the circuit in the row or column is electrically intact.

Speaking of Rainer Buchty, this should help you out:
http://www.buchty.net/ensoniq/files/esq1-tg/20.jpg

I highly suspect it's a row issue and not a column issue, so I would pay particular attention to that. I don't have an ESQ-1 to look at, nor the keybed schematics so I cannot definitively narrow it down to which exact row it would be, however I suspect (when numbering the rows 0 to 7) that it will be row 6. That's pin 32 on that R1120-12, so if that pin NEVER blinks on/off when jamming on any of the keyboard notes then you've found your gremlin.

If it was a column issue then the dead keys should appear as a scattershot across the keybed. Since they are grouped in a linear fashion then it should be a row. But it should only be C-G, not including G#. Row 7 should be the highest five keys on the keyboard, I think: G#, A, A#, B, C.

Row 0 is probably the lowest C-G, Row 1 would be G#-D#, Row 2 would be E-B, Row 3 should start on C again, and so on since every set of three row pins would cover two octaves of notes. So Row 0,1 and 2 would be first two octaves starting on the lowest C, Row 3,4 and 5 should be the next two octaves, Row 6 should be the start of the fifth octave and Row 7 is "incomplete" because there are only 61 keys on the keyboard which doesn't take advantage of the full 64 keys of the key matrix -- solely because of musical reasons.

Now, assuming that the Row 6 signal is the problem... is it because the R1120-12 can't see row 6 being activated/deactivated because pin 32 is fried and is now "blind" or is it because there is an earlier problem preventing the Row 6 signal from making it back to the R1120-12?

This is why you watch for the row signals before they try to pass through the ribbon cable and back to the keyscan chip (R1120-12). If the signal is present on the KEYBOARD side ribbon cable header then the keyboard itself is working, but something further upstream is bad. That could be a corroded header pin on either the keyboard PCB or keyscan PCB side, the ribbon cable, a trace leading to the R1120-12, or the R1120-12 itself.

If the row signal is making it to the KEYBOARD side header but can't be measured on the KEYSCAN side header then that's your absolute best case scenario. Fix the header pins or the ribbon cable -- that's it.

If the row signal is not making it to the KEYBOARD side header then you're still pretty lucky because that means it's not the R1120-12 and is just a corroded trace or a bum diode or something inexpensive and "easy" to fix.

Edit: I changed this post due to a pin numbering error and to avoid potential confusion with the keypad [U9, 6500/11] processor.

[Madisynths]

I realize this is post is nearly 7 years old, with the last response from 4 years ago, but I'm replying with nearly the exact same problem because this was a VERY useful post AND there's a pretty simple solution.

When you see a pattern of 8 notes being dead, like C-G, G#-D#, or E-A, then there's pretty good odds of there being a broken/corroded trace on the keybed PCB. I couldn't figure it out until I noticed that there wasn't continuity between all of the diodes (cathode side), which led me to believe there was a broken/cold solder joint that developed on the keybed PCB (this keyboard worked 100% fine just days earlier before I removed it to perform work on the mainboard). It is a major hassle to carefully remove each of the key springs from the keys, but that's what's needed to be done to get the PCB off.

Once you've gotten the PCB off, you will more than likely find some sort of spill between the keys that's corroded one or several traces. This design with the traces up leads to an easy way for minor spills to devastate the PCB, like this:

With a light touch, carefully scrape the coating above the traces that are corroded, and bridge the gaps like so:

I used some old Tayda resistor legs (the kind that are nearly as thin as your hair) as repair wire on the two traces that were severed, and soldered over the traces that were exposed after removing corrosion that was between the copper trace and the protective coating layer (liquid flux is VERY helpful in getting the solder to stick).

I hope this helps someone else down the road!