Highly Liquid Forum facebook twitter google plus rss feed
  #1  
Old 09-07-2014, 05:03 AM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default OBSX and UMR2 problem

UPDATE 2017-Jan-20: the UMR2 is NOT compatible with the Oberheim OBSX due to its design of extraneous signals on the keyboard matrix which caused the UMR2 to get "confused" during setup. This is the fault of the OBSX, not the UMR2.

However the UMR2 has found a home in my Oberheim FVS.

Leaving the remainder of the discussion for prosperity.

(original opening thread)

First off, I am an EE with 30+ years of DIY and maintaining analog synths and I know my way around embedded circuits.

I'm not saying that to sound infallible - but I'm not ashamed to admit I sometimes make mistakes! And I did review the documentation carefully and briefly searched for problems similar to mine.

I have an Oberheim OBSX that I resurrected from the dead and was attempting to install the UMR2. I checked my wiring very carefully with a continuity meter and verified no shorts between adjacent terminals.

I followed the setup procedure. Then when I play back the OBSX/UMR2 over MIDI, the voices trigger in rapid succession.

So I hooked up my 16 channel logic analyzer (Tek 7D01) to watch the data lines at the CPU (clocked by the *IORQ pin). I can clearly see the expected behavior of the data lines for each key when using the OBSX keyboard, and I can see a repetitive signal over multiple loops. When the UMR2 is triggered over MIDI, I do not see a repetitive signal. The pulses are random, with the key alternating between on/off.

I checked the power rail on the UMR2 with my scope, nice and clean.

I isolated any devices on the data lines and repeated the setup procedure, in case one of them was aliasing the UMR2. No better. There were two signals I could not isolate, when I put probes on them they are good.

The weird thing is I should see data pulses only during addresses 0x00 through 0x06, but I see another pulse on a data line at address 0x08. I can't find anything on the schematic mapped to that address, which is why I tried the isolation tactic.

I tried moving the cabling carrying the signals to the UMR2 to check for EMI, no better.

Any good engineer knows that it is a good idea to walk away and take a break from a problem. I shut down at midnight and am going to sleep on it. One of the things I will try next is putting the logic probes on the data lines of the keyboard cable as opposed to the CPU. I'm open to other ideas.

Last edited by The Real MC; 01-20-2017 at 08:10 PM. Reason: update 2017
Reply With Quote
  #2  
Old 09-08-2014, 03:34 AM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

I hooked up my logic analyzer probe directly to the data line pads on the UMR2. I also hooked up an analog scope probe to data line #1 on the UMR2 so I could see what was really there.

The problem is NOT the UMR2.

The scope probe revealed something that the logic probes could not... I can see the repetitive pulse in the key press, but there are other non-repetitive spurious pulses in between. I have a fault in the OBSX in which there is bleed onto the keyboard scan data lines - it doesn't seem to impact the OBSX, but under this condition the setup procedure won't work on the UMR2 because when it is in "learn" mode the spurious pulses are confusing it, hence the "aliasing" issue.

When I trigger the OBSX over MIDI, I can see all these random pulses on the data lines and no repetitive key pulse at all. That's because the spurious pulses are aliasing the data lines while the UMR2 is in learn mode.

I'll upload a video shortly.

I'm going to have to breadboard a barebones key scanning circuit and hook the keyboard and UMR2 to it in order to get a successful setup procedure. Yeah I could fix the fault in the OBSX but I do not have any spare 80C98 ICs and they are no longer available.
Reply With Quote
  #3  
Old 09-11-2014, 01:16 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by The Real MC View Post
Oh, and are you planning to build more MPA boards? I want three of them for the OBSX to manipulate front panel pots, pitch bend/mod wheels, and program selection. I have a circuit strategy for that
I'll answer the easy question first. The MPA is permanently discontinued, but you can find all of the open source design files here. Perhaps a potetiometer-output add-on board can eventually be created for the new MD24 product.
Reply With Quote
  #4  
Old 09-11-2014, 01:29 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

By the way, welcome to the forum, TRMC.

Thank you for posting the informative video. You found what I think is a common cause for UMR2 incompatibility. Some keyboards have extraneous signals on the keyboard matrix (often by design) which cause the UMR2 to get "confused" during setup.

May I upload the video to Youtube for posterity?

Nice shop!
Reply With Quote
  #5  
Old 09-11-2014, 06:07 PM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

Quote:
Originally Posted by John View Post
By the way, welcome to the forum, TRMC.

Thank you for posting the informative video. You found what I think is a common cause for UMR2 incompatibility. Some keyboards have extraneous signals on the keyboard matrix (often by design) which cause the UMR2 to get "confused" during setup.
Glad to be of service, I'm probably one of the few with the tools to uncover this and wanted to share

Quote:
May I upload the video to Youtube for posterity?
Help yourself... have the original uncaptioned larger videos if you want them.

Quote:
Nice shop!
I do a lot of DIY maintenance/repair/modifications, need those tools for gear like this!

Last edited by The Real MC; 01-20-2017 at 08:05 PM.
Reply With Quote
  #6  
Old 09-12-2014, 03:22 AM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

I built the breadboard, verified each block, verified with keyboard, verified clean pulses, went through the setup procedure, tried the MIDI controller... does not work, same behavior.

If there were some way to get the *IORQ signal to the UMR2, the same signal controlling the buffers to the data buss then it may had worked... what are the undocumented X lines?
Reply With Quote
  #7  
Old 09-12-2014, 02:36 PM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

After sleeping on it (a great problem solver, but don't try it at work!), it occurred to me that the keyboard select lines are always pulsing. This is because A0-A3 connected to the 74C42 are directly connected to the CPU.

That means the OBSX keyboard select lines are constantly pulsing and the poor UMR2 is constantly updating the data lines even when the firmware isn't scanning the keyboard.

The data lines are supposed to be isolated from D0-D7 on the CPU via the 80C98 gated buffers. But if one of those 80C98s is bad, then I have a data buss conflict which would cause my fault condition. I have uncovered bad 80C98s in my OBX. 80C98s are obsolete and I don't have any spares.

So I asked: this worked in the OBXa, so what is different? And indeed, the OBXa includes a 74C174 latch (U26) for the address lines to the IO decoders - CLOCKED BY THE *IOR LINE. This means the keyboard select lines are only active when the firmware is scanning the keyboard.

So I have two potential solutions (maybe both):
  1. replace the 80C98s with a 74LS244 (not a drop-in solution, requires subboard)
  2. shoehorn a 74LS174 on the A0-A3 lines to the IO decoders (yuk), replicating the OBXa

The first solution can be breadboarded, that is the easiest experiment.
Reply With Quote
  #8  
Old 09-15-2014, 05:48 AM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

I programmed the UMR2 using a breadboarded key scanning circuit, away from the OBSX to prevent aliasing the UMR2. After the setup was complete, I left the breadboard circuit in place and tested each MIDI key, observing the data lines. All correct, the UMR2 is configured correctly.

Hooked it back to the OBSX, same problem.

I decided to gate the select lines out of the 74C42 with a 74LS244 which is gated by *IORQ and *A3. That didn't work (I checked the circuit, even found a bad gate on my 7400). The key scanning isn't reliable at every key, and the UMR2 does not work at all.

With that circuit out and the OBSX back to normal with UMR2, I decided to look at a select and data line for a MIDI key, with the UMR2 generating the data signal. While I saw a steady stream of select line pulses, I did NOT see the associated data signal from the UMR2 at every select pulse. I saw the data signal at an occasional select pulse, just not every one. That explains why the voices trigger in rapid succession, the data signal is not consistent and the OBSX thinks it is seeing many key on & key off signals.

When I looked at the select line with the analog probe (triggered by the logic analyzer), it's really messy. That's because the A0-A3 lines are ALWAYS pulsing the select lines. This was why I attempted to gate the select lines using the '244.

What if I gated the select lines between the keyboard and the UMR2...? If only I knew why the UMR2 didn't respond. I double checked the MIDI controller, it's good.

Is there a minimum pulse width that the UMR2 will respond to? When I probed the output of the '244 the pulse on the select line was pretty narrow. Sounds to me like it was narrow enough that the UMR2 couldn't respond. The '244 approach might not work with the OBSX keyboard, but might work between the keyboard and the UMR2 if I widened the pulse.

As for my other approach, I did find a 74C174 on the OBSX that latches A0-A3, but it's latched by a completely different signal with different memory mapping, not gonna work.

I'm out of options.

Last edited by The Real MC; 09-15-2014 at 05:56 AM.
Reply With Quote
  #9  
Old 09-15-2014, 01:33 PM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

When I get home I am going to check the '244 circuit to see how the tri-state outputs look. It's a good possibility that the enable pulse is too narrow and could be cleaned up with a Schottky 7414 inverter gate. That might lead somewhere. Sleep is a great problem solver.

Another solution would be a plain old OR gate per select line instead of a tri-state gate. Tri-state doesn't work for everything...

Last edited by The Real MC; 09-15-2014 at 02:07 PM.
Reply With Quote
  #10  
Old 09-24-2014, 03:59 PM
The Real MC The Real MC is offline
Junior Member
 
Join Date: Sep 2014
Posts: 8
Default

I breadboarded a gating circuit. The outputs of the '42 select lines were gated using '32 quad ORs, with the control input coming from the OR of A3 and *IORQ. Thus the select lines are only active when the OBSX is scanning the keyboard and it masks the spurious signals. The circuit and keyboard functions correctly yet the UMR2 would not generate data signals. Checked every point of the circuit with the scope and logic analyzer, everything is there. Pulse width of the select line is ~1us, same with the gate circuit out of the system. If I attempt the setup procedure with the gate circuit in, the UMR2 would not respond to the local keyboard. I am beginning to suspect a loading issue (or reflection), it doesn't show on the scope despite probing right at the UMR2.

I am going to try another approach. When I built a standalone scanning circuit using the '138 to generate the select lines, both the local keyboard and the UMR2 worked with that. The '138 has enable inputs that are convenient with the *IORQ and A3 lines.

Whereas my first circuit gated the select lines to both the keyboard and UMR2, I am going to use the '138 to generate select lines for ONLY the UMR2. I will also place the circuit closer to the UMR2 to avoid reflection/loading issues.
Reply With Quote
  #11  
Old 02-10-2015, 03:43 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by The Real MC View Post
Just a quick update, shortly after the last post I had serious health issues and am recovering. I haven't abandoned this project, and I have some ideas going forth. Just other things that are higher priority at the moment.
Sorry to hear it but I am glad that you are getting better. Thanks for checking in!
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 12:29 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.