OK 5pinDIN, I have the whole keybed out. What is the general idea for cleaning these interconnects? Just pull each of the cables out and clean them up with soap and water?

Dave

Oh this is getting fun. Just discovered that EMKS-FD talks some variant of I2C back to the processor. Maybe the third pin (IC) is an interrupt pin? I’m so tempted to plug this into my logic analyzer and see what kind of pattern comes out when I play the notes...stay on target…

OK, so I definitely found a pattern with the 3 black keys played (F#, G#, A#) and then throw in the B and this pattern glitches all over the keyboard, except at the lowest octave.

I’m scared to pull out those plastic interconnect cables for fear of not being able to push it back in. The pins on the plastic receivers look very shiny, but I can’t see what the substrate on the plastic cable looks like as it’s seated into the connector too deep. Should I yank one out?

Based on your most recent post, I’d leave the keybed interconnects alone. The determination that the lowest octave doesn’t exhibit a problem while the rest do is interesting, since it’s the furthest from connection to the processor.

I mapped the offending keys to key lines and their processor ports, taken from page 248 of the SM:

I don’t see an obvious commonality related to the above. Keys that are working correctly use the same lines and ports.

Here’s the datasheet for the HD6433693 processor:
http://www.digchip.com/datasheets/download_datasheet.php?id=365273∂-number=HD6433693

You might want to check Vcc for IC5 - make sure the +5V is stable, and use a scope to verify it’s relatively clean.

Please let us know if you determine what’s causing the problem.

Note:
Anyone who doesn’t understand the above should probably ignore it, and certainly leave servicing of their Motif to someone who is qualified.

Thanks 5PinDIN, I’ll investigate that chip and it’s characteristics at the power rail.

Dave

Any idea what the “gain” and “offset” trim pots do on that board? There is only a refdes on them in the SM with no detail as to what they do.

Dave

DaveKush - 05 February 2016 12:38 AM

Any idea what the “gain” and “offset” trim pots do on that board? There is only a refdes on them in the SM with no detail as to what they do.

Dave

They’re adjustments for After Touch operation. The AT sensor is connected as a feedback element from pin 1 to pin 2 of IC2 (in parallel with R13 and C23).

Most problems with the keybed have revolved around one or more random keys not working correctly, typically caused by corrosion if the Motif had been in a shore area.
http://www.google.com/search?q=corrosion+5pindin+site:www.motifator.com
You might look at those threads.

However…
Your individual keys apparently are responding correctly, but with specific groupings in most octaves causing the velocity to maximize, that would seem to be a processing problem. Since I’ve never experienced that particular symptom, I’m not sure what the next step is to pin down the specific cause.

OK, thanks! It’s going on the logic analyzer tonight. I just can’t resist the urge to see what a “good” key pattern looks like vs. my glitchy ones and I think that will tell us if HD6433693 isn’t happy.

I’ll post a pic or two once I get it all hooked up and running.

Dave

Well, after a few hours at the LA, I think I’ve got a rough idea of how the keyboard encoding works over I2C. Essentially, a “light” keypress is made up of 5 bytes and a “hard” keypress is made up of 40 bytes, which I’m too tired to figure out, but it likely includes more info on the keypress speed as well as the after-touch.

Those 5 bytes, on the “light” keypress consist of the device I2C address for the processor, in this case address 16, a space, another 8-bit number that hovers in the 150’s and I’m guessing is a start timer value for switch 1, 8 bits representing the key, and a final 8 bits representing what I’m guessing is the switch 2 close timing. For the switch one and switch two timing, if I do an “average” keypress, these two numbers, byte 1 and byte 4 converge toward equality somewhere in the 130’s to 150’s.

When I do a keypress for the lowest octave F#,G#,A#, I get 15 bytes all neat and tidy in the format described above. But when I play this same key combination on the glitchy octave, I get a big the first 15 bytes, but then a massive string of bytes after it of what looks like random garbage or random key presses.

In all of this, one thing I have noticed is that the glitchy symptom actually goes away somewhat as the keyboard remains powered. So, maybe a sign of heat mortality. I suppose I could blow cold air on the HD6433693 and observe the results, but that’s just getting a bit too crazy.

For this issue, I think I’ve taken it far enough to know that it appears that this PCB is the culprit. So, the million dollar question is: Can I buy one of these PCB’s somewhere and if so, does anyone know where?

Included is a pic of the logic analyzer cable hooked up to the connector as well as a screen capture of the A# key for posterity sake.

Thanks guys,
Dave

Click thumbnail to see full-size image

Pic 2

Click thumbnail to see full-size image

pic 3

Click thumbnail to see full-size image

DaveKush - 06 February 2016 01:25 AM

[...]For this issue, I think I’ve taken it far enough to know that it appears that this PCB is the culprit. So, the million dollar question is: Can I buy one of these PCB’s somewhere and if so, does anyone know where?[...]

As far as I know, the EMKS-FD board is attached to the MKH-D, and not sold separately.

Shipping is additional.

https://www.yamaha24x7.com/YamahaOMS/EasyOrder/QuickOrder.aspx

Yamaha Corporation of America
6600 Orangethorpe Ave.
Buena Park, CA 90620
1-714-522-9011

---------------------

I’ve never dealt with this company…
http://www.partsimple.com/wd806100-yam-n-13.html
...but they appear to have the part for $102.91 plus shipping.
It’s apparently special order, and non-returnable.

Hi 5pinDIN, just got my brand new Yamaha MKH-D PCB and installed it and to my dismay, the problem is still there, actually seems a bit worse now.

So...I paid $1400 for the XS, just put another $200 into it plus a bunch of hours in debug and such and it’s still bricked. Am I past the point of no return? Any ideas on where to go from here?

Sure appreciate all of your help!

Dave

I can appreciate your dismay. As I mentioned previously, I’ve never experienced the problem you’re having.

Can you be more specific about “a bit worse now”?

Well, maybe it’s just me. I was hitting random keys together and chords and it was glitching all over. I don’t remember it doing that before. With the original MKH-D, it seemed like it was specific to that pattern of keys I mentioned before.

Something I hadn’t thought of before was if the garbage I was seeing on the I2C bus was coming from the processor, not the keyboard. This is purely speculation, but I’m just wondering if the I2C receiver at the processor is not getting a solid 1 or 0 and then nack-ing back to the keyboard controller, causing a re-send or even a bunch of bus collisions. Just a thought.

Dave

DaveKush - 12 February 2016 07:49 PM

Well, maybe it’s just me. I was hitting random keys together and chords and it was glitching all over. I don’t remember it doing that before. With the original MKH-D, it seemed like it was specific to that pattern of keys I mentioned before.

For the symptom to change like that with a replacement of the MKH-D/EMKS-FD seems strange. If the original was good, and the replacement is also good, then it would seem that the symptom would remain the same.

 

DaveKush -

Something I hadn’t thought of before was if the garbage I was seeing on the I2C bus was coming from the processor, not the keyboard.

 

DaveKush -

This is purely speculation, but I’m just wondering if the I2C receiver at the processor is not getting a solid 1 or 0 and then nack-ing back to the keyboard controller, causing a re-send or even a bunch of bus collisions.

Obviously if 1’s or 0’s aren’t solid, there could be a few possible causes. Anything on the bus might be leaky, a bad ground for the MKH-D/EMKS-FD could cause 0’s from the keyboard to be insufficiently low, etc. You could look at the 1.5k pullups for SDA and SCL (and the 10k for Initial Clear) on the DM board (R621/622/623 - see attachment, which is taken from page 244 of the SM) as a possible cause if 1’s aren’t high enough.

While I’ve got a fairly well equipped test bench, a logic analyzer isn’t part of the mix, so you’ve got an advantage which I hope will help you find the problem.

Click thumbnail to see full-size image