MIDI keyboard fault

[ITAM805]

AG, good point thanks, yes there is a regulator on the board, I'll check that out.

As a quick test I powered the k/b from a 12V smpsu wall wart that I know is quiet and well regulated, and into my laptop via the USB cable, M-Ox showed no channel switching anomalies despite me hammering away on the keys. Keeping in mind the last time I tried it with the original 9V psu it also behaved itself?

[Ancient Geek]

Also, check all grounding points. Is there any shielding in the unit? Is so, check that it is grounded securely. If there is no shielding, check for proximity to RFI sources. This sounds like a very intermittent problem, such that odd noise spikes from, say, ill-behaved led lights or wall warts (not necessarily the one driving the unit) or even wifi routers, in combination with flaky design and/or flaky psu components could easily be at fault.

[SiriusHardware]

Originally Posted by Ancient Geek

I think it's most likely that the EEPROM is used only to store configuration data. All the code will be in the microcontroller which, by the way, has a mask ROM.

Agreed, the firmware will have been mask programmed into the processor at the time of manufacture so any replacement, unless bought from the keyboard manufacturer, will not contain the vital firmware code.

Also agree that the serial nonvolatile memory device will not contain firmware, only programmable parameters.

[kevinaston1]

Every type of keyboard note or MIDI error I have had has been due to noise in the electronics, or the power supply.

I have had crystals way off frequency, crystals that jitter, etc. Power supplies that have HF noise on them, regulators that oscillate – every thing you can think of has come up.

MIDI is a very simple serial interface running at 32 KHz WITH NO ERROR CORRECTION. Each message is 8 bits long; the first bit denotes the message type, whilst the remaining 7 bits denote the value, from 0 to 127.

Although it is a simple serial interface, it was brilliant in its inception. At the winter NAMM (National Association of Music Merchants (USA)) show in 1981, the Roland Electronics chief, Ikutaro Kakehashi met with two American synthesiser giants, Tom Oberheim (Oberheim Electronics) and Dave Smith (Sequential Circuits). Together, they hammered out the basis of the MIDI interface, and it was immediately taken up by all the other manufacturers. How is that for friendly international cooperation?

So, check the power supply for noise, hum, low voltage etc. Check the processor data for noise etc; check the MIDI data for noise. Look carefully and you will find it.

Kevin

[ITAM805]

Hi guys, well of course the k/b is behaving perfectly at present

Notwithstanding, I carried my spare scope onto the lounge floor where this heavyweight sits.The PSU (11.5V) input had lots of ripple on it although the 5V at the regulator was flat with no spikes noted. This could be cured easily with a better supply but as I say, it's working without issue at the moment

Then I tried the MIDI o/p, with the scope screen to -V but I can only get a very weak trace on what I believe is the data pin 4?

AG, there is no shielding or ground wires, the case is metal but isolated from the board.

Hi Kevin, where do I look on the microcontroller? I have the schematic but it comes in at 12mb

[SiriusHardware]

As mentioned previously, if you are trying to scope an otherwise unconnected MIDI output you will need to supply a load resistor because the output is open-collector. See the attached image, taken from 'Advanced Midi User's Guide' (R.A. Penfold, 1991).

Wire a resistor (about 220R to 470R) between pins 4 and 5 on a spare 180 degree five pin DIN plug, plug it into MIDI OUT on the keyboard and use the scope to monitor what's coming out on pin 5.

To generate a long stream of MIDI info rather than just a quick 'blurt' every time you press or release a note, try rolling the pitch wheel smoothly back and forward. You won't be able to 'read' the individual packets but you will be able to see if the data is clean and square.

[ITAM805]

Thanks SH. The cable was plugged in at both ends so I assumed the collector was sinking current? Anyway I shall try again with a resistor

[SiriusHardware]

Yes, if you have a MIDI cable plugged into the keyboard's MIDI OUT and into the MIDI IN of something else then the other device's input optocoupler and its associated series resistor will provide the load through which the open-collector output on the keyboard will sink current. In that case, you don't need a load resistor. But you should be looking at pin 5 on the keyboard, not pin 4 which you were looking at originally, to see the main data output from the keyboard.

That said, the source path from +5V to pin 4 on the MIDI out on the keyboard will be through a low value resistor like it is on that diagram I attached above, so, provided you have a load, you will also see the data at some level on pin 4. But it won't be as 'big' as it will be on pin 5.

[kevinaston1]

Sorry, I have no service data for a Studiologic SL-880; I doubt it even exits. Since the demise of the Italian keyboard industries in the 70’s the manufacturers around the Castelfidardo region have had a very tough existence.

By far, the greatest number of faults are power supply related. Ensure that any regulators have at least 2.5V higher on the input than its regulator voltage; otherwise they are prone to dropping out.

Check for oscillation and ripple with the scope set to a.c. and the gain turned up – difficult to see 20mV of noise on top of a 5V trace.

The processor (CPU) will be the biggest IC on the board. Rather than trying to identify the clock oscillator pins, look for the crystal which will be mounted close by. If you scope this, you have a direct reading of the clock frequency. Look on the case of the crystal, and it will give a clue as to its operating frequency. It should be a nice clean signal, with no jitter, and at the quoted frequency.

Be careful. Sometimes, the loading of the scope probe can stall a crystal. If this happens, switch your probe to divide by 10 (if it is switchable), turn up the Y gain to compensate.

Pin 4 of the MIDI out socket is the 5V bias supply to the optocoupler in the next MIDI item in the chain. You will see a small variation here during data transmission, but not much. Look at pin 5 to see the actual data.

To see a clear data chain, keep hitting and releasing a key; you then have a nice constant note on, pitch and note off data stream to look at.

Alternatively, if you have MIDI software which includes a decoded MIDI event page, set the software to record and look at the MIDI events as they roll on; you will soon notice any event other than note data.

Also never forget the technician’s friend to locate intermittent faults – heat and cold. Gentle heat from a hairdryer will bring 99% of faults on. Once you have a set of suspect components, the application of a freezer spray will remove the fault instantly, showing the culprit(s).

Kevin

[ITAM805]

Well I tacked a 470R between pins 4/5 and am getting about a 1V pulse on 5 when I hit a key, but my scope isn't sophisticated enough to sync to it. There is no extraneous rubbish going on that I can see unless I increase the scope sensitivity down to 10mV range where there's some (expected?) digital/clock hash

[Ancient Geek]

To help see what's going on, if your 'scope supports it, try setting the timebase and trigger holdoff so that you can see a consistent trace when you repetitively hit a key. This would make it easier to see any noise or jitter. The timebase should be such that you see at least the whole first byte of data. There's one start bit, 8 data bits and a stop bit transmitted at 31250 bits per second. If my mental arithmetic is not way off beam, something like 25-50 microseconds per division horizontal timebase would work. The idea of the trigger holdoff is that it's a delay to prevent the scope from retriggering until after the end of the midi message to avoid the trace of the first byte or two being overwritten. You may need to adjust this. Try hitting the same key repetitively at a rate that allows you to see what's going on given the screen persistence of your scope. If you have it set up right, you should be able to see any changes in the status byte that contains the channel ID, and also any jitter in the bit timings.

[ITAM805]

Hi AG, I dont think my Telequipment D1011 has such a function that you describe? I also have a Trio CS-1830 which probably does have, but it's in need of attention, alas it's rather flaky and seems reluctant to trigger at all

[Ancient Geek]

I just looked at the manual on the web and you're right, it doesn't have trigger holdoff. A shame, as it's a really useful facility to have. Still, you could adjust the sweep time to accomodate all three bytes of a note on/note off message and still have enough resolution to see what's going on, although this may be pushing it a little. Set the trigger mode to normal, not auto. The note on and note off messages differ only in one bit, which you should be able to spot. Try and have equal times for pressing and releasing the key. Note that MIDI data is transmitted most significant bit first.

[ITAM805]

Well, the fault is back but with no apparent means of seeing what's wrong? My Trio scope has the aforementioned trigger 'holdoff' facility but it won't trigger, nor will the trusty D1011 sync, so we're up a certain creek

[Ancient Geek]

Not really. What has changed between the fault being present and not? Temperature? Other appliances being switched on or not? Take another look for noise on +5V atc while the problem's occurring.

[SiriusHardware]

If you have the circuit diagram and feel this fault is unique to key-on / key / off events you could try knocking up a little variable frequency square wave oscillator (or use the output of a signal generator if you have one) and use that to drive an electronic switch - a transistor or an optocoupler - connected with appropriate polarity across the actual key switch of the key which you have observed tends to give you this problem.

This will then enable you to generate a constant stream of note on / note off messages all at exactly the same spaced interval, and that in turn will be much easier for your scope to sync to.

[ITAM805]

Hi guys, I secreted a 7809 regulator (plus a 0.15uF cap on the o/p) in the supply housing, and the ripple has gone, the supply is a rock solid 9.1V - but the fault remains.

To add to the spook channel switching, I just noticed there's no 'note off' message on certain notes/channels. So it's a proper basket case

[SiriusHardware]

Can you confirm:

You're using MIDOX as your MIDI analyser / receiver

This problem (occasional transmission of the right note on the wrong channel, along with occasional failure to send a note-off message), is happening on ALL of these combinations:-

-Keyboard connected to low end computer with cheap USB MIDI interface

-Keyboard connected to high end computer with high end MIDI interface

-Keyboard connected to a multitimbral tone module, bypassing computers and MIDIOX altogether.

Failure to send note-off could be a purely mechanical problem if each key uses a single-pole double throw switch, with the common connected to one contact when the key is at rest and the other contact when the key is pressed.

The reason it might work this way is if it is velocity sensitive, so then the keyboard scanning regime measures the elapsed time interval between the ending of the 'key at rest' state and the beginning of the 'key pressed' state. The shorter the interval between the two states, the higher the velocity. In an arrangement like this it is quite possible that the contact for the 'at rest' position has become tarnished and does not always 'make' when the key is released and returns to the rest position.

Or, your transmitted MIDI data is so badly deformed that MIDI receivers are just having trouble understanding it. You really are going to have to try to scope the data, if possible.

Here's another idea. People sometimes use 'Audacity' (the audio toolbox program) to capture DATA rather than audio, using it, in effect, like a one-shot storage scope. I've seen an article where someone captured the output from a 433Mhz remote-control socket receiver using Audacity in order to understand the data format. Maybe you can try something like that? You would probably need to attentuate the data level and put the audio input on your PC into line-input mode.

[ITAM805]

Hi SH:

Keyboard is connected to high end computer with high end MIDI interface (M-Audio 2496) and Midi-Ox via good quality Midi cable

As per post #1, the key-bed was removed and the membrane key switches (which are all in perfect condition) were thoroughly and meticulously cleaned by me. All 'note on' and 'aftertouch' behave as expected according to Ox, thus it's highly unlikely the key switches are at fault, as the intermittent strangeness isn't note dependant, sorry if I gave that impression in post #37

Thanks for the Audacity tip, I'll keep it in mind. I admit I'm loosing hope and patience with this keyboard, as did the my mate who gave it to me!

PS: added a camera pic, channel 16 is selected, 5 is an interloper, no midi off!

[McMurdo]

have you tried to replicate the fault by playing the keyboard into another midi device, eg tone module or a synth?