Old Motifator threads are available in the Archive.
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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 |
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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? |
5pinDIN
Total Posts: 11891
Joined 09-16-2010 status: Legend |
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:
// HD6433693 (IC5)
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:
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:
|
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
Thanks 5PinDIN, I’ll investigate that chip and it’s characteristics at the power rail. Dave |
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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 |
5pinDIN
Total Posts: 11891
Joined 09-16-2010 status: Legend |
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.
However…
|
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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 |
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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,
Image Attachments
|
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
Pic 2 Image Attachments
|
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
pic 3 Image Attachments
|
5pinDIN
Total Posts: 11891
Joined 09-16-2010 status: Legend |
As far as I know, the EMKS-FD board is attached to the MKH-D, and not sold separately.
// Part # Description Qty Price Shipping is additional. https://www.yamaha24x7.com/YamahaOMS/EasyOrder/QuickOrder.aspx
Yamaha Corporation of America
---------------------
I’ve never dealt with this company…
|
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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 |
5pinDIN
Total Posts: 11891
Joined 09-16-2010 status: Legend |
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”? |
DaveKush
Total Posts: 29
Joined 01-30-2016 status: Regular |
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 |
5pinDIN
Total Posts: 11891
Joined 09-16-2010 status: Legend |
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.
Â
The I²C receiver is, of course, looking at data from more than just the keyboard, such as the panel buttons and data dial, and foot controllers. If you rapidly spin the data dial, or operate a volume pedal rapidly, does there seem to be a problem?
Â
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. Image Attachments
|