Next/previous switching a multiplexer

[TTL]

Using a 4067 multiplexer I'm trying to switch between 16 MIDI inputs and route whichever input has been selected to an output. Using two pushbutton switches I should be able to use the "Next" button to go to the next input while the "Previous" button should allow me to go to previous selected input. I believe I need some sort of binary counter IC for this.

Alternatively, a solution 16 pushbutton switches (one switch for each input) would allow for a faster, more direct switching method, but it would of course need more physical room for mounting on the front panel of its enclosure. Still, I'd like to consider this option as well.
Below is my schematic so far.


PS MIDI, for those who don't know stands for Musical Instrument Digital Interface: a serial data transfer protocol (31.25 Kbaud) between electronic musical instruments.

 

[Harald Kapp]

A 74HC(T)193 up/down counter could be a suitable IC for you. It has separate up/down inputs. If you use mechanical switches, you need to debounce them, e.g. using an SR-Flipflop made from two 74HC(T)00 NAND gates - conveniently there are 4 gates in one IC allowing to debounce two switches.

Your second idea using a separate switch for each channel can be realized, too, but as far as i know there is no single IC for this. You'd need a flipflop for each button, plus a circuit that ensures that only one flipflop ever is active (no two channels can be selected at the same time). Once you have that, you can use the outputs of the flipflops to control a simple selector circuit (e.g. made from open collector AND gates where one input af an AND gate is the MIDI signal, the other is the control signal from the flipflop). Or you can build a decimal to binary encoder and drive the multiplexer as in your circuit.

It can be done but will be rather complex. May I suggest an alternative approach for this? Use a microcontroller. It can read the buttons, do the 1-out-of-n selection and encode the result as a binary number to drive the multiplexer. Or do the multiplexing witin the controller by software provided it has enough I/O pins.

 

[KrisBlueNZ]

You need a 4-bit binary (not BCD) up-down counter. Check out these possibilities:

CD4029: http://www.digikey.com/product-detail/en/CD4029BE/296-2046-5-ND/67275
Presettable (loadable); separate up/down and clock

CD4516: http://www.digikey.com/product-detail/en/CD4516BE/296-2075-5-ND/67349
Resettable; separate up/down and clock

CD40193 (CMOS version of 74xx193): http://www.digikey.com/product-detail/en/CD40193BE/296-3510-5-ND/376609
Presettable; resettable; separate up and down clock inputs

I would say the 40193 is perfect for your application.

You will need some debouncing logic on your pushbuttons. A simple method uses the pushbutton and a resistor across the supply, with a series resistor to a small capacitor, feeding a Schmitt trigger. If you already have a 4011 in your circuit with two NAND gates spare, use a 4093 instead, and use the spare gates to debounce the buttons. If you already have a 4049/4069 in your circuit with two inverters spare, use a 40106/4584 instead, and ditto. Or you can use an SPDT biased toggle switch and an S-R latch to generate a clean signal. Google for more ideas if you're not familiar with this.

Edit: Harald: Snap!

 

[TTL]

Thanks to both for your suggestions
I'm not sure if I understand it all (I'm more of a practical soldering type of person), but I found some info on debouncing switches (in addition to Harald's link which is a little different with the diode) and have made some additions to my schematic below. Does it make any sense?

 

[KrisBlueNZ]

Yes; that looks good.

On each debouncing circuit, I recommend adding a resistor between the resistor-and-pushbutton node and the capacitor-and-gate-input node.

You have the right polarity for the CLOCK DOWN and CLOCK UP signals - the 40193 increments on the rising edge, which corresponds to the pushbutton being pressed, because the 4093 gates invert the signal from the pushbutton.

Two pins on the 40193 are unconnected on your diagram: -LOAD (aka -PRESETENABLE) on pin 11 must be tied high, and CLEAR aka RESET on pin 14 must be tied low.
On the 4067, the INHIBIT input on pin 15 must be tied low.

The inputs of the unused gates must also be tied to a defined logic level.

With those changes, your circuit should work.

It's arguably risky to drive a MIDI cable from a bilateral switch like the 4067. A better way would be to buffer the signal from pin 1 of the 4067. This will also avoid the issue with the variability of the ON-resistance of the bilateral switches.

Here's what I suggest. Replace the 4093 with a 40106 hex Schmitt inverter. This has six inverting gates with only one input each. Use two of them for debouncing, and the other four as a buffer: use the first one to invert the signal from pin 1 (which should have a pullup of about 10k on it) and connect its output to the inputs of the other three inverters; connect their outputs together too. That will give you a non-inverted signal with significant drive capability that you can feed through your 220 ohm current limiting resistor and onto the MIDI cable.

Simply switching MIDI at the data level may produce unpredictable results because there are contexts at certain levels. I'm pretty rusty on this, but I believe MIDI Exclusive is one such context, and bulk data blocks can be transferred too. A smart MIDI siwtch could handle changing between multiple sources in a reliable way, but with a circuit that simply switches the data immediately in response to a button-press, there's a possibility of switching from one source to another while the first source was part-way through a message. As MIDI doesn't have any kind of message framing or error checking, suddenly switching between two data paths without monitoring the data and context could cause commands to be misinterpreted, especially immediately after the changeover. Implementing some kind of idle line check (the currently selected MIDI data source has to be idle for a certain minimum amount of time before the circuit will switch) could help solve this problem.

 

[Harald Kapp]

You've got the inputs and outputs of the 40193 swapped. Pins 3,2, 6 and 7 are the outputs of the counter that need to go to the inputs of the multiplexer, see datasheet. The inputs (15, 1 10 and 9) should not be left open but tied to a defined potential, e.g. ground, preferably via a resistor. 1kOhm or 10kOhm are fine, the exact value doesn't mater.

 

[KrisBlueNZ]

Well spotted Harald!

I agree the inputs need to be held at a known potential but I have never used series resistors with unused inputs on 4000-series ICs. I simply tie them to VDD or VSS. I agree with everything else you said though. If you have a reference that says otherwise, please post a URL!

 

[TTL]

Wow, I'm learning a lot here!
What I've done so far is correct the 40193 outputs (A, B, C and D) to the 4067 inputs, ground the 40193 input pins 15, 1, 10 and 9 (A, B, C and D) through a 10K resistor. Pin 14 (Clear) has been grounded too, and pin 11 (Load) has been connected to power supply +.
I assume the unused "Borrow" and "Carry" pins shouldn't be left unconnected, so I've grounded those too.
The 4067 pin 15 (Inhibit) has also been grounded.
Finally I've grounded the two unused gates of the 4097. Not 100% sure if I've got this right though... Should all 6 pins be grounded perhaps? I've also added the resistors as suggested.
Here are my changes (I've started version-naming the schematics now. This is version 3):


As for your suggestion for replacing the 4093 with a 40106, KrisBlueNZ; I'm working on it. Stay tuned for the next update

Simply switching MIDI at the data level may produce unpredictable results because there are contexts at certain levels.
[............]
Implementing some kind of idle line check (the currently selected MIDI data source has to be idle for a certain minimum amount of time before the circuit will switch) could help solve this problem.

You mean: if there's some MIDI signal passing through and I press the "up" or "down" buttons I simply won't see any input switching advancement until the there is no more MIDI data passing through?
That would make it failsafe, but I don't think even my Roland MIDI patchbay has this feature. It just relies on the user choosing the input before dumping Sysex data. Another thing is that some older MIDI devices such as the Yamaha DX-7 synth sends a constant "active sensing" MIDI signal (basically saying "hello, I'm still here") which is quite irritating, but I imagine could cause serious problems here if there was an idle check function.
Apart from "locking" the input selection switches until Sysex dumping was done, would such an addition have other benefits?

 

[KrisBlueNZ]

-BORROW and -CARRY on the 40193 are outputs; you don't connect them to +V or GND if they're not used. Ditto for the outputs of the unused gates in the 4093.

For the debouncers, typical values would be 10k for R11 and R12, 100k for R14 and R15, and 0.1 µF for C5 and C6.

That's looking good now.

If you can guarantee that there will be no MIDI activity in progress at the moment you change from one input to another, you'll be safe, unless there is any other context involved. For example I seem to remember that you can assign the pitch bender data to control something else; if the receiver has been put into that mode by one sender, then you switch to a different sender, the receiver will misinterpret the bender messages from that sender. I guess you know enough about MIDI, and how you use it in your setup, to be able to say whether that kind of problem could arise.

Re the DX7 heartbeat message, I doubt it would send it continuously, end-to-end. So if you used a timeout of, say, 2 MIDI character times (512 µs, I think), you would be safe.

 

[TTL]

Ah, so it's only unused inputs of logic devices that need connecting to GND or +V so they don't "float" and thereby switch back and forth randomly because of RF noise or whatever?
For the unused 4093 gates I've removed the output connections now and tied all inputs to GND.

Hmmm.. your suggested feature of blocking the switches until MIDI signal flow stops probably will probably be a good idea if it isn't overly complicated/expensive to incorporate so I'm open for it. I'm only woried about those situations where the MIDI device would freeze or something, thus causing my MIDI input selector to refuse to do anything. But an additional "Panic" or "reset" pushbutton would probably solve situations like that, unlocking any frozen data flow.

You said earlier that the 40193 was presettable. I'm not sure if this means what I'm hoping for, but is it possible to make it remember its last MIDI input position instead of resetting to MIDI input 1 after each power-off?

 

[TTL]

It's arguably risky to drive a MIDI cable from a bilateral switch like the 4067. A better way would be to buffer the signal from pin 1 of the 4067. This will also avoid the issue with the variability of the ON-resistance of the bilateral switches.

Here's what I suggest. Replace the 4093 with a 40106 hex Schmitt inverter. This has six inverting gates with only one input each. Use two of them for debouncing, and the other four as a buffer: use the first one to invert the signal from pin 1 (which should have a pullup of about 10k on it) and connect its output to the inputs of the other three inverters; connect their outputs together too. That will give you a non-inverted signal with significant drive capability that you can feed through your 220 ohm current limiting resistor and onto the MIDI cable.

OK, here's my attempt at doing the above:

 

[KrisBlueNZ]

Ah, so it's only unused inputs of logic devices that need connecting to GND or +V so they don't "float" and thereby switch back and forth randomly because of RF noise or whatever?

Right. You mustn't tie any OUTPUT to any defined level - or even to other outputs (unless they're "open collector" or "open drain" outputs, or "tri-state" outputs and won't ever be enabled simultaneously) - because the IC will try to drive them to a certain level, according to its own internal decisions, and if that's the opposite of the level that the output is tied to, then the output will fight with the asserted level, and current will flow. This wastes power, and in some circumstances, enough current can flow to cause the IC to overheat and/or be damaged.

For the unused 4093 gates I've removed the output connections now and tied all inputs to GND.

That's right.

Hmmm.. your suggested feature of blocking the switches until MIDI signal flow stops probably will probably be a good idea if it isn't overly complicated/expensive to incorporate so I'm open for it. I'm only woried about those situations where the MIDI device would freeze or something, thus causing my MIDI input selector to refuse to do anything. But an additional "Panic" or "reset" pushbutton would probably solve situations like that, unlocking any frozen data flow.

Right. I'll have a think about how best to implement that behaviour... unless you decide to use a microcontroller - see later...

You said earlier that the 40193 was presettable. I'm not sure if this means what I'm hoping for, but is it possible to make it remember its last MIDI input position instead of resetting to MIDI input 1 after each power-off?

Partly. Presettable just means that you can set it to any 4-bit binary value by providing that value on the "JAM" inputs and pulsing the PRESET pin (called -LOAD on your diagram) low then high. If you want that value to be non-volatile, i.e. remembered while there's no power, you need to take care of that requirement separately.

Non-volatility can be achieved using a Flash ROM, or a latch that's powered from a coin cell, or the 40193 could be powered separately so it doesn't lose power (the CMOS 4000-series devices consume almost no power when they're in a static condition). There are also devices called "E² potentiometers" which could possibly be used, although they don't wrap from 15 to 0 and vice versa. All of those options would require at least some extra circuitry.

The proper way to do what you want would be to replace all the logic with a microcontroller, such as a small PIC (http://www.microchip.com). This is a whole new realm and requires a lot of learning, but if you're interested, I'm sure you could do it - you seem pretty smart and resourceful. This would make everything simpler. For example a PIC16F527 could provide all of these features:

• Up and Down pushbutton inputs with debouncing done in firmware (no external components apart from the pushbuttons)
• Non-volatile recording of selection (most PICs include a small amount of E² memory)
• Detection of idle MIDI data including logic to force an input change if the data never goes idle
• Sixteen LEDs driven using 4x4 multiplexing to indicate the selected input (these can also flash, etc)
• Interpreting of the actual MIDI data, if needed (or this could be added in future)
• Other expandability and enhancement - for example, generation of MIDI messages from footswitches... the possibilities are endless.

PIC microcontrollers aren't the only type out there. http://www.atmel.com/avr is a competing range that to my mind are a lot better designed, and only slightly more expensive.

If you use MIDI a lot, then getting into microcontrollers would be a great way to give yourself a lot of future options.

OK, here's my attempt at doing the above

That's spot on. Nice work!

 

[TTL]

Thanks!
Actually, this is all a big challenge for me because I'm not a circuit designer at all. I'm just a practical hobbyist who's made a lot of kits and some boards out of simple schematics. I do however have many ideas, but not the knowledge to put them into practice.
Fortunately with the help I've been getting here I'm finally getting somewhere, and learning something in the process as well

Microcontrollers seem like a great way to proceed, but I wouldn't have the faintest idea where to start. At least here I do understand a little bit of what's going on and it does seem we've taken care of most of the details already so I can soon go ahead with the PCB layout and then actually build it. There are a few details left though:

1) Non-volatility: I'm guessing a coin-cell for backup might be the simplest way to implement this?
I suppose such a battery would last many years before needing to replace it. Not the most elegant solution (I'd need to remove the 19" rack enclosure from my rack and open it in order to gain access), but if the Flash ROM option is too complex to implement it's better than nothing.

2) Input selection LEDs (16 LEDs in total): I've also been toying with the thought of using two 7-segment LED displays, but that wouldn't be of much help in understanding which number corresponds to which synth module. With a row of 16 LEDs I would make room below for labels (Dymo or similar) showing the synth name.

3) MIDI activity LEDs: flashing whenever MIDI data is detected. Some thoughts on different configurations:

a) flashing the selected input's LED when that device sends out MIDI data. This would probably be the tidiest solution from the musician's point of view.
b) flashing any of the 16 input LEDs at any time if there is MIDI data passing along those inputs.
This would help in MIDI troubleshooting as the musician would immediately see where any MIDI data originates from.
c) flashing a single LED connected to the MIDI output (i.e. after the MUX switches). Being a separate, dedicated "activity" LED I believe this could probably be a simpler way to implement it into the circuit design.
​

I'm leaning towards option a or b (any opinions on what might be most useful/practical?). I'm thinking two-coloured LEDs would allow for a simpler circuit design (two lighting circuits instead of merging it all into one), but I'd prefer having just a single coloured LED for each input, showing both input selection and MIDI activity if any.

 

[KrisBlueNZ]

Regarding non-volatility. There is no simple way to add it - at least, not that I can think of. It's so obviously the kind of thing that a microcontroller would do that I don't even like to think of how to add it to a "dumb" design.

I think the answer would be to have the 40193 powered from a battery-backed-up supply rail. This requires that any connections between the 40193 and the parts of the circuit that are not powered during backup must behave in such a way that, while the 40193 is powered up and the other parts are not, (a) voltages from the 40193 to the rest of the circuit do not cause damage to the other ICs (ICs are not supposed to have voltages applied to their inputs when they are not powered up); (b) other parts of the circuit do not draw current from the 40193's outputs (since this current would come from the backup battery and would cause it to discharge); and (c) that the signals from the rest of the circuitry to the 40193 remain in known states so the 40193 doesn't accidentally get reset, or incremented or decremented, or loaded.

Actually I think we could get away with just one extra IC for non-volatility, but I'm not sure. Have a think about it, and think about these next comments, then let me know whether you want me to design a non-volatile circuit. You might also want to consider how important non-volatility would be, i.e. how often you would benefit from it (how often you would turn the unit OFF and back ON and want the input setting to be preserved) and how much extra work it would take to just press a button up to 8 times to re-select the input. And whether you want to add a lithium coin cell which will need to be replaced after 10~20 years and could possibly leak.

I agree that a row of LEDs would be better than a two-digit 7-segment display.

I agree that having all of the LEDs flash when MIDI data is detected on the respective input would be a very good idea. This can be done in various ways. The simplest way would require three extra small components per LED: a resistor, a transistor, and an electrolytic capacitor. That simple arrangement would give a glow that fades out, rather than switching OFF cleanly. If you want a clean turn-off, add another few small components per LED, or a few more CMOS ICs.

You can get three-wire LEDs that contain a green LED and a red LED (and other combinations are available) in a single package. You could use one colour (e.g. green) to indicate "selected" and the other colour (e.g. red) to indicate "activity". For that example, the selected input would indicate green, or orange (green + red) while there was data, and unselected inputs would be unlit while idle, and red while idle. As I said, you can get other colour combinations, and we could also arrange things so when there's data on the selected input, the LED changes to the other colour only, instead of showing both colours, if that fits better with what you want.

Another option would be a single-colour LED for each input, as you suggest, and combine the selection and data signals so that the selected input is steadily illuminated, and the unselected inputs are steadily OFF, but data (in both cases) toggles the LED to the opposite state for a short time. So unselected inputs would blink ON in response to data, and the selected input would stay ON and blink OFF in response to data. This would be confusing to look at though, I think, if many inputs had data on them simultaneously. That's why I thought that bi-colour LEDs would be better.

All of this control would be much more easily done by a microcontroller, but as you say, that's quite a jump in complexity (not hardware complexity, but overall difficulty).

 

[Harald Kapp]

I agree the inputs need to be held at a known potential but I have never used series resistors with unused inputs on 4000-series ICs. I simply tie them to VDD or VSS. I agree with everything else you said though. If you have a reference that says otherwise, please post a URL!

Kris, I don't have a URL for reference, but where I work we always use series resistors to tie unused inputs to a defined potential (Vcc or GND) for two reasons:

1. Testability of the board in production. With the resistor in place it is easy to in-circuit test even unused gates to ensure that the chip is in good order and that all pins are soldered corerctly (no floating inputs).
2. During development you can easily put an unused gate to service by removing the resistor and soldering a wire to the now open input (you may even leave the reistor in place if it doesn't disturb the function).

Both of these issues are next to impossible to do if the input is tied directly to a fixed potential.

Harald

 

[KrisBlueNZ]

Harald, does that mean you use a separate resistor for each unused input?

 

[Harald Kapp]

Kris,
in the ideal case: yes. But due to the high density of today's PCBs we are often unable to add separate test points to each pin. In that case we may use one resistor for two or more pins - I'm aware that this nullifies my arguments at least to a good part.

 

[KrisBlueNZ]

Yes, and I don't find those arguments very convincing, except perhaps during development with SMT components. For one-off designs that are built up on stripboard (which I guess this is), it's easy enough to disconnect pins that have been tied to VDD or VSS if that is ever required.

To the OP: I don't see any reason to use resistors when tying unused inputs high or low - at least, not on a manually assembled single-sided board with through-hole ICs, but feel free to use or omit these as you wish.

 

[OLIVE2222]

Regarding the non-volatility one idea can be to store the last selected input on analog form. An Up/down digital potentiometer with storage eeprom like the DS1804 can be used. A counter can increment few steps each time the up/down button is pressed. The potentiometer voltage can be "decoded" with two cascaded LM3914 wired in dot mode.
The LM3914's outputs can directly drive the channels leds and CD4016/4066 to select the midi channel. This for sure involve a "bit" of glue logic and is less cost effective than a small µC but can be full of learning's and it's a battery less solution.
Also sometime, having a bit more parts to skip the usage of a µC can be an asset if the firmware must be certified (obviously not the case at hobby level).

 

[TTL]

Yes, and I don't find those arguments very convincing, except perhaps during development with SMT components. For one-off designs that are built up on stripboard (which I guess this is), it's easy enough to disconnect pins that have been tied to VDD or VSS if that is ever required.

To the OP: I don't see any reason to use resistors when tying unused inputs high or low - at least, not on a manually assembled single-sided board with through-hole ICs, but feel free to use or omit these as you wish.

I'm a little confused, because we already added pullup/-down resistors to the schematic, didn't we?

I'm hoping to get a PCB etched using Eagle. I've never ordered a PCB before and have had limited success in etching my own in the past (way simpler designs as well), but hear that there are numerous places where you can get this done at low cost. I expect several boards to be made: the actual control board, a front panel switching board, one or two MIDI connector boards and a power supply board.
The same 1U 19" rack enclosure will also house two separate 8x MIDI THRU boards, but those are kits which have already been completed. So this will be a quite versatile "MIDI expansion box".

I'm looking into the stuff you asked about previously about volatility and LEDs, but for now wanted to show a schematic I received from someone years ago when I started another project (still not done) where I also wanted to show MIDI activity by flashing an LED for each MIDI port. But can't it be done simpler? I was hoping I could just "tap into" the existing MIDI pins (pin 4 and 5) for each MIDI port I'd be wanting a flashing LED for, but this schematic takes the existing MIDI IN, puts it through the LED circuit and ends with a replacement MIDI IN socket. The nice thing about it though is that the two ICs have enough gates for two LED circuits.