Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Building a MIDI keytar

Status
Not open for further replies.
Ok. First hardware change. So I've been chasing my tail, trying to figure out why I couldn't get anything out of the keybed.

The solution is quite simple, and called for a modification to the prototype.

The grounds on the 15k sips needed to be removed, and they need to be tied to Vdd. The 74AC238 needed to be changed to a 74AC138.

The schematic in post #143 reflects the new changes.

As soon as I get everything back together, I'll post some more timing diagrams. :)
 
Last edited:
The grounds on the 15k sips needed to be removed, and they need to be tied to Vdd. The 74AC238 needed to be changed to a 74AC138.
I guess that's the thing with the Matrix Diodes i wrote some posts before.
It depends if there cathodes are connected with the sample lines, or the other side.
In different schematic I'v seen both.

Why using a BCD to decimal decoder?
Use direct pins of the PIC to pull down the lines - when You have some free one.
Than it doesen't matter if You pull up or down. It depends only of the Software.
Write 0b00000001 or 0b11111110 to the Port - That's the only change and the pullups / pulldowns of course.

I think You should measure with an oscilloscope about delays caused by the capacitive load of the keybed.
15k seems to be a quite high value for the pullups.
But don't replace them with super low values, because when some keys are pressed the resistors would be connected parallel.
 
So I've been chasing my tail,
MJ . Think we all been there , Yesterday I spent several hours 'de-bugging ' code only to find one of my HC-05 .. UART RX wires ( 1 of 4 ) was on the wrong PIC pin ( a dsPIC33EP512GM304 )...:banghead:

chasing-my-tail1.jpg
 
There is one pullup per input so how can they end up in parallel?
8 key's belong to 1 group.
All the groups are bound together via diodes.
Any group has 2 sample lines ( first contact, second contact ) caused velocity.
When every ninth key is pressed You have to drive 14 sample lines by one output.
( All the sample lines must be pulled to GND ).
In normal playing this would not appear.
Up to 8 parallel resistors is realistic, but theoreticly 14 is possible and the circuit had to handle it.
 
Keybed_Key.jpg


Here's a schematic of one key. When Tx is high (Vcc) the two diodes are back-biased, so closing the switch has no effect.

When Tx is low (Gnd) there's a current path and the pressed key will drag the MKx (and the corresponding BRKx) lines low.

The two resistors are high values (15K in the case of pretty much every key controller out there. But, when a key is down,
the resultant resistance will be 1/2 of whatever value is on a specific switch. (To address the statement that Pommie made. :) )

Because of the geometries of the rubber cup holding the two contacts, there's a finite time between the closure of S1 and S2.
This time varies, based on how hard you strike the key.

Fairly tight tolerances keep the times roughly the same in production.

It's a brilliant design, really. :)
 
I'm sorry, I've looked at this and it seems over complicated. Tomorrow I'll attempt to write C code on an 18 series chip (without any added chips) that scans a 64 key board and sends timing data at 2000Hz. It can't be that hard.

Mike.
Edit, just remembered, I'm in school tomorrow so may be the day after.
 
Last edited:
Pommie: In a sense, yes. But the diodes are also used to select rows by back-biasing.

Take a look at keyboard encoders. Here's a good article explaining them, and the diodes. :)

**broken link removed**
 
I still don't understand why this can't be done with a solitary 18 series chip at 2000Hz. The limiting factor is the serial speed.

Mike.
 
wkrug: LOL I did look at them with a scope. That's how I determined that the drive lines (T0-T7) needed
to be grounded to let the matrix produce output.

I use the AC138 to cut down on the outputs needed from the PIC.
 
But, when a key is down, the resultant resistance will be 1/2 of whatever value is on a specific switch.
That's right, but only when pressing one key.

At 8 Key's are conected the MKx lines and the BRKx Lines together, and pulled up with 2 resistors.
Next 8 Key's the same and so on.
The Tx lines of the first key of every group are connected together.
The seconds key also.

Let's say the first key of the first group is pressed, also the first key from the second group.
The MKx and the BRKx Lines of both groups must be pulled down.
So You have to pull down 4 resistors ( MKx1, MKx2, BRKx1, BRKx2 ).

You'll loss about 0,6V about the diodes, and a non specific voltage by the used driver, depending by the current.
In sum it could be possible, that the scan input can not further detect a pressed key when the voltage don't come down to LOW level.
When 15k work fine without dissortion of the scanning signal all is fine.
When get a low edge steepness the values should be decreased.
But not to low, because the written issues.
A look into the datasheet of the scanning chips could help to figure out the voltage for a proper low level detection.
 
wkrug: In the case of the Roland scanning chip, you can't even get the chips, much less the documentation.

Let's take the case of a 49 note keybed. Each pullup is 15k. That means when any switch is closed, that resistance comes down to 7k5

So, if we divide 7k5 by 49, we get about 153 ohms. So, you're looking at about 30 ma being drawn by the keybed.

Most regulators can source that current very easily.

In the case of a 76 note action, you're looking at an Rt of 99.6 ohms, which will give us a current of about 80 ma.

Still not a showstopper. :)
 
So, if we divide 7k5 by 49, we get about 153 ohms. So, you're looking at about 30 ma being drawn by the keybed.
Not really.
You have 7 groups with resistors.
So You can get a maximum 7k5 7 time parallel = 1k071 Ohms.
That should be no problem for any driver.
But when have to decrease the pullups say to 1k0 Ohm caused by edge stepness the driver had to handle 143 Ohms.
At this condition the voltage at the driver should not go over 0.4V ( 0.4V Driver + 0.7V Diode = 1.1V ) to detect the low level shurely.
But that depends of the used scan chip and should be described in the according datasheet.
At C-Mos low detection works normally under 1/3 supply voltage = 3.3V / 3 = 1.1V.
When the voltage at the lines is over that value no LOW level would be detected.

This is only for understanding.
Don't let's talk about problems we don't have.
When 15k works proper no problem should appear.
And Values down to 6k8 should work too, but higher values decrease the drawn current, of course.
 
I still don't understand why this can't be done with a solitary 18 series chip at 2000Hz. The limiting factor is the serial speed.

Mike.
I used the 24F because I wanted to make sure that the project wouldn't stall and have to be rebuilt.

I have a couple of 18F452 PICs, and I'm going to to look at the pinouts to see if there are enough ports.

If so, I'll build one when I get a chance. :)
 
I've been looking at the pins from the keybed, and I noticed that there is a flip of the bits.
I can compensate for that in the software, because twisting the wires in the hardware might
create all kinds of crosstalk issues.

Also, my gut is telling me that debounce caps are needed on P1-P7 and S1-S7.
I'm going to try 22pf and see how that works.

Another thing I've done is move pins around so that I can get a clock output from the PIC.
For now, I'll use it for state analysis on the logic analyzer.

As soon as I finish building and testing, I'll post schematics, source code and pictures. :)
 
I've been looking at the pins from the keybed, and I noticed that there is a flip of the bits.
I can compensate for that in the software, because twisting the wires in the hardware might
create all kinds of crosstalk issues.
In another forum I was reading that a few higher notes are mirrored to the lowest octave at some keybeds.

I would solve this with a look up table.
In this table for all the "adresses" are stored the corresponding note values.
That You can use for adressing the velocity table ( note table ?, state table ? ) .
That works very fast and give You absolute freedom at twisted notes.

Also, my gut is telling me that debounce caps are needed on P1-P7 and S1-S7.
I'm going to try 22pf and see how that works
That would't be my prefered solution.
Because it slows down the level achieving - You work with very sharp pulses there.
The result would be a slew rate of 0,33µs ( 1 tau ) additional the cable, diodes and pcb caps.
I would measure from shure closing of contact 1 to first closing of contact 2.
The next action that triggers a reaction would be when contact 1 opens first time again.
All other conditions, bouncing and so on should be ignored by the "state machine".
That will give You a software debouncing.
That would not work proper, when wanna using a note off velocity, but in other cases it should work.
The DD E510 works similar.
 
In another forum I was reading that a few higher notes are mirrored to the lowest octave at some keybeds.

I would solve this with a look up table.
In this table for all the "adresses" are stored the corresponding note values.
That You can use for adressing the velocity table ( note table ?, state table ? ) .
That works very fast and give You absolute freedom at twisted notes.

Actually, it's easier than that. All I need to do is to start my bit masking routine at 0x80 and shift right,
instead of 0x01 and shift left. :)

That would't be my prefered solution.
Because it slows down the level achieving - You work with very sharp pulses there.
The result would be a slew rate of 0,33µs ( 1 tau ) additional the cable, diodes and pcb caps.
I would measure from shure closing of contact 1 to first closing of contact 2.
The next action that triggers a reaction would be when contact 1 opens first time again.
All other conditions, bouncing and so on should be ignored by the "state machine".
That will give You a software debouncing.
That would not work proper, when wanna using a note off velocity, but in other cases it should work.
The DD E510 works similar.

Because there's a PC board with a ground plane, there is some extra "stray" capacitance there.
That stray capacitance does not exists in my case, as it's only a breadboard.

For this prototype (and only this one) I may be forced to add capacitors.

I can't really test it until next week, as I seem to have blown up the PIC. :(
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top