Shift register led drivers

I've tried to do a little survey of viable solutions for the led dial. Preferably I'd like to not have any resistors or transistors on the lines connected to the LEDs as it s easier to solder one IC than several small smd parts, even if the cost would be quite a bit less with more parts.

The need for transistors is removed in two ways: 

On the positive side of the diodes it is possible to use a line driver such as the uln2803 transistor array. This does however make a "local" solution where both positive and negative sides of the LED are controlled by a single shift register (see post earlier) impractical, but a single driver may power a whole bunch of diodes on several dials. The number of lines running between the dials will increase somewhat though.

On the negative side of the diode the transistor may be omitted if one uses an open drain led driver/shift register.

The resistors are still needed with the open drain version, but switching to a "constant current" led driver lets you control the current using a single, shared resistor that sets up a reference current.

I've done a little list of available 12bit and 16bit LED drivers. It is by no means exhaustive, but probably covers most of the common ones.

Open drain LED drivers 
(low side, meaning they should be connected to the LEDs negative pole to sink current)

12 stage:

TLC6C5912

Hef4894b 

Npic6c4894

Constant current

12 channel:

Max6979

Bd18377

16 channel:

Max6969

Max6971, high voltage 

A6282

A6276 (obsolete)

Stp16c596

Dm133

Tlc59281x

Tlc59025

Cat4016

Tlc5927

Pca9952

Pca9955

24 channel:

Stp24dp05

So far the cheaper solution seems to be:

Tlc59281 - 16bit, 0.987€@100

These are normal shift registers often used for LED scanning in the DIY world. They are neither open drain nor constant current and just mentioned here to remember them:

74hc4094 (can this drive a led from its outputs? Some people seem to do it, letting it sink current without transistors).

74hc164

74hc595 in combination with the uln2803 (row scanner)

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!

Pogo pins

Spring loaded pins, also known as pogo pins, spring loaded test pins etc, are a neat tool to keep pins pressed against a test point or interconnect point. I intend to use five of them for In Circuit Programming, removing the need for permanent ICP pins in my circuits.

While searching the web for such pins I realized brand name ones are insanely expensive. Ebay to the rescue! As often is, china products are available to fulfill your needs. I found that the most common ones are named P75-something. But what does this something after P75 mean?

I found this image, showing all variants. I went for the P75-B1 which has a very sharp tip perfect for holes in the PCB.

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