MIDI cables - length/delay issues?

[dazzjazz]

Anyone know if longer MIDI cables, say 20' or so, would induce some kind of signal delay?

 

Thanks

 

Darren

[J. Dan]

It shouldnt affect latency. The only potential problem with cables that are too long would be errors resulting in dropped messages, stuck notes, etc....but it'd have to be really extreme. 20' is no problem.

[nickd]

I think 50 feet is the conventional maximum length that people quote - below that you should be fine.

[The Real MC]

Signal delay isn't the issue. The issue is signal degradation. The parameter that drives how long a cable you can use is capacitance per foot. The longer the cable, the higher the capacitance. Capacitance will degrade high frequency signals like MIDI.

 

The MIDI spec recommends maximum length of 50ft but says nothing about cap/ft. It is possible to use a poor quality 50ft MIDI cable and it won't work because of high cap/ft. I have successfully used a 150ft snake for MIDI because it has really low cap/ft.

[dazzjazz]

Thanks everyone!

[Dave Bryce]

I've never experienced MIDI delay, and have also used really long cables.

 

dB

[MIDI2XS]

The velocity factor for signals in copper wire data cables is typically around 50%-70% of the speed of light - not much of an issue when it comes to MIDI latency.

 

[DaveMcM]

Anatek (a long gone company that produced devices similar to MIDI Solutions of today) made a product called the MIDI Match. This product consisted of two small boxes, one received MIDI and converted the singal to a male XLR which could plug into a snake and the second box would accept the signal at the other end via a female XLR and convert back to 5 pin DIN MIDI. You could also just use a very long Low Z cable between the two boxes. Anatek stated that the distance could be as much as 4000 feet.

 

HERE is a forum post from someone that has a MIDI Match as well as other Anatek items. It is from over a year ago but might be worth checking into if the MIDI Match sounds interesting.

[WesG]

It is a pretty serious stretch to call MIDI a high frequency cable. MIDI is a serial signal which operates at 31,250 bps. This means the maximum frequency on the wire will be around 16kHz.

 

I bet you could go REALLY long using CAT5 cable, provided you split pin 3 and put it on both pairs (carrying pins 2 and 5). Particularly if you used CAT5 STP.

 

Anyhow, 50ft is not an issue with non-crappy cables and non-junk optoisolators in your gear.

[The Real MC]

It is a pretty serious stretch to call MIDI a high frequency cable. MIDI is a serial signal which operates at 31,250 bps. This means the maximum frequency on the wire will be around 16kHz.

 

Wrong. ~16Khz is the Nyquist limit of a 31.25Khz frequency. And in the EE field, 31Khz is considered high frequency.

[b3plyr]

Actually, in the EE world, 3 MHz is considered high frequency. Certainly at lower frequencies we sometimes have to consider so called "high frequency effects".

[The Real MC]

Actually, in the EE world, 3 MHz is considered high frequency. Certainly at lower frequencies we sometimes have to consider so called "high frequency effects".

 

3Mhz is a high frequency transmission path through air and is high frequency in the communication field.

 

Any AC component that can penetrate capacitive dielectrics, can be attenuated with inductance, cause EMI, cause switching spikes on power rails and ground busses, is subject to PC board layout rules different from DC signals, is subject to the "skin effect", is outside the threshold of human hearing, is susceptable to cap/ft limit in transmission cables, etc is considered high frequency in the EE world. MIDI's 31.25Khz clock is certainly compliant in those situations.

[JeffLearman]

32KHz is HF if you're talking about audio. It'd be LF if you were talking about radio frequencies. But it's a more-or-less base-band square wave, so it'd generate much higher harmonics.

 

Not that any of this really matters; when it comes to communications signals, it was reasonably fast for 1980 but slow as a dead dog for today.

 

WesG was wrong about the 16kHz thing, but is probably right that you can run it quite a distance on twisted pair. Again, though, it's current loop (which makes it reject noise better than baseband voltage), and I don't know squat about the signal decay characteristics of current loop. If anything, it probably goes further than the equivalent voltage modulation. (Current loop (e.g., RS422) is often used in industrial applications. Teletypes were current loop too, IIRC.)

 

WesG was also wrong if he meant to contradict RealMC, who was completely correct. Capacitance degrades high frequencies even in the audio range.

 

In any case, the question was answered early on. If it works, it works. If it doesn't, you'll get missed notes or wrong notes or hung notes (etc), but no discernible delay.

[MIDI2XS]

32kbps is not equivalent to 32kHz. The highest PRR (Pulse Repetition Rate) occurs when adjacent bits alternate high/low. That results in a PRR - or pulse frequency - of 16kHz.

 

A perfect square wave is composed of the fundamental frequency, plus third harmonic at 1/3 the amplitude of the fundamental, fifth harmonic at 1/5 amplitude, seventh harmonic at 1/7 amplitude, etc., out to infinity. Obviously, the amplitude of the harmonics becomes less significant the higher their order, and data transmission/reception doesn't require perfection. In fact, for data purposes, bandwidth that doesn't significantly attenuate the fifth harmonic is often sufficient.

 

For MIDI, that means a cable capable of handling 80kHz (5x16kHz) over the intended distance should be adequate. Skin depth for copper is about 1/4 mm at 80kHz - anyone going to suggest Litz wire or waveguide?

 

[The Real MC]

32kbps is not equivalent to 32kHz. The highest PRR (Pulse Repetition Rate) occurs when adjacent bits alternate high/low. That results in a PRR - or pulse frequency - of 16kHz.

 

True, but it's still a periodic base clock of 31.25Khz and is the parameter used in reactance formulas in passive devices, cable capacitance loss, and circuit board design. PRR is used for distance measurement systems in water/air (sonar and radar) and is hardly relevant to high frequency current flow transmission via a conductive wire(s).

[Dave Bryce]

My deep inner geek loves this forum.

 

dB

[MIDI2XS]

32kbps is not equivalent to 32kHz. The highest PRR (Pulse Repetition Rate) occurs when adjacent bits alternate high/low. That results in a PRR - or pulse frequency - of 16kHz.

 

True, but it's still a periodic base clock of 31.25Khz and is the parameter used in reactance formulas in passive devices, cable capacitance loss, and circuit board design. PRR is used for distance measurement systems in water/air (sonar and radar) and is hardly relevant to high frequency current flow transmission via a conductive wire(s).

Your basic premise concerning a 31.25kHz clock is incorrect. The transmission rate is 31.25 kbps - Hz and bps are not the same.

 

Let's see if I can provide a simple example:

The period of a one-Hz square wave is one second. For a symmetrical square wave, during that period half of the time is spent at maximum positive excursion, and half at the maximum negative. If we think of each of those half-cycles as data bits, we can transmit two of them within that one second period. That is, for adjacent alternating bits, 2bps is equivalent to 1Hz.

 

Since maximum frequency occurs when adjacent data bits alternate H-L-H, etc., and it takes two bits alternating in that manner to complete a "cycle", the highest pulse frequency is 31.25 divided by two, or 15.625kHz.

 

As to PRR, your usage of the term is overly restrictive - it's commonly used in conjunction with electronic pulse signal generators, for example - but that's another issue.

 

[The Real MC]

I have the MIDI 1.0 detailed specification document 4.1.1 February 1990 in front of me. MIDI is a 31.25kbaud asynchronous serial protocol with start bit, eight data bits, and stop bit with 320microseconds (320us) transmission time per serial 10-bit byte. That's 32us per bit, which is the period of a 31.25Khz clock.

 

KBaud is equal to Khz, but neither are not (always) equal to Kbps. There is zero mention in the MIDI spec of bps or using the half cycles of the clock signal as data bits.

 

The 31.25Khz is a WORD CLOCK. It is a synchonization signal for the USART - the crucial component of every MIDI transmitter. Depending on the USART, the clock input triggers on either the rising or falling edge, or the TTL high or low level. Whatever the trigger scheme used, the USART pumps out a serial bit with every trigger event. That trigger event has to happen every 32us - at a frequency of 31.25Khz. Thus the MIDI data message is a 31.25Khz signal.

 

I should know - I designed and built a MIDI controller for my BTEE senior project at college, using a 31.25Khz clock to drive the USART. It's a standard design in every schematic I have studied. It worked, I got my "A".

[MIDI2XS]

I have the MIDI 1.0 detailed specification document 4.1.1 February 1990 in front of me. MIDI is a 31.25kbaud asynchronous serial protocol with start bit, eight data bits, and stop bit with 320microseconds (320us) transmission time per serial 10-bit byte. That's 32us per bit, which is the period of a 31.25Khz clock.

I have the 1995 revised MIDI 1.0 spec, version 4.2. It's a combination of the 4.1.1 document and the 4.2 update. Yes, MIDI protocol is 31.25kbaud, and since there's only one bit per transition, it's also 31.25kbps. The MIDI spec indicates 320µS per 10-bit byte. It actually says nothing about 32µS per bit, which assumes all bits are the same length. However, the math will still work, so let's invert the 32µS/bit to get bits per µS, and convert the µS to seconds. Since scientific notation isn't easy to do on the forum, 1,000,000/32 = 31,250 bits per second - not exactly a surprise.

 

 

KBaud is equal to Khz, but neither are not (always) equal to Kbps. There is zero mention in the MIDI spec of bps or using the half cycles of the clock signal as data bits.

Kbaud is not equal to kHz, and in this case kbaud is equal to kbps (as I explained above).

 

Indeed, the spec says nothing about "using the half cycles of the clock signal as data bits" - and neither did I. In fact, the spec says nothing about a clock frequency, either. It just states 31.25kbaud and 320µS per 10 bit byte. The designer gets to figure out how to clock a UART properly.

 

The spec doesn't have to mention bps, since 320µS per 10 bits says it all.

 

 

The 31.25Khz is a WORD CLOCK. It is a synchonization signal for the USART - the crucial component of every MIDI transmitter. Depending on the USART, the clock input triggers on either the rising or falling edge, or the TTL high or low level. Whatever the trigger scheme used, the USART pumps out a serial bit with every trigger event. That trigger event has to happen every 32us - at a frequency of 31.25Khz. Thus the MIDI data message is a 31.25Khz signal.

As you correctly stated previously, the MIDI protocol is Asynchronous. There's no specific need for a USART, which is a Universal Synchronous/Asynchronous Receiver/Transmitter. Since MIDI doesn't run synchronously (where there are no start/stop bits), a UART is all that's required, and is what's specified in the document (although you could use a USART in UART mode).

 

Yes, a UART typically outputs one bit for either a rising or falling clock edge. What you're apparently failing to account for is that the clock signal only has one rising or falling edge per cycle. In other words, the bit's width is the same as the clock's period - the clock undergoes a high and low state for each bit's high or low state. So, at the highest possible rate (adjacent bits alternating H-L-H, etc.) a complete "cycle" would require two bits, and be twice the clock's period, equivalent to half its frequency.

 

Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

 

 

I should know - I designed and built a MIDI controller for my BTEE senior project at college, using a 31.25Khz clock to drive the USART. It's a standard design in every schematic I have studied. It worked, I got my "A".

You're not the only one with a degree, and my experience is considerably more than a functional college senior project. I'm not questioning that you used a 31.25kHz clock, just pointing out that it doesn't equal MIDI signal frequency.

 

[Losendoskeys]

Nice theory argument guys - I must admit I have forgotten most of my electronics degree!

 

But in practice (which is what matters) the OP just needs to know that good quality off the shelf cables which are not made from bits of wet string will work pretty well up to 50 feet without drop out.

 

The main thing to remember for me is that bad CONNECTIONS are the cause of 80% of all problems in electronic systems.

So buy good quality connectors at all times for your good quality cables.

 

[EscapeRocks]

Excellent tech stuff.

 

Now then, I will just add that I often use a 30ft MIDI cable with my Vortex, and have yet to experience any issues.

[The Real MC]

KBaud is equal to Khz, but neither are not (always) equal to Kbps. There is zero mention in the MIDI spec of bps or using the half cycles of the clock signal as data bits.

Kbaud is not equal to kHz, and in this case kbaud is equal to kbps (as I explained above).

 

Baud rate is the number of signal or symbol changes per second. In the case of MIDI, it is signal changes per second. If the signal were to alternate for every data bit, this would be a repetitive signal with cycles per second, which was the predecessor unit (cps) for frequency before hertz was adopted in the 1960s.

 

The 31.25Khz is a WORD CLOCK. It is a synchonization signal for the USART - the crucial component of every MIDI transmitter. Depending on the USART, the clock input triggers on either the rising or falling edge, or the TTL high or low level. Whatever the trigger scheme used, the USART pumps out a serial bit with every trigger event. That trigger event has to happen every 32us - at a frequency of 31.25Khz. Thus the MIDI data message is a 31.25Khz signal.

As you correctly stated previously, the MIDI protocol is Asynchronous. There's no specific need for a USART, which is a Universal Synchronous/Asynchronous Receiver/Transmitter. Since MIDI doesn't run synchronously (where there are no start/stop bits), a UART is all that's required, and is what's specified in the document (although you could use a USART in UART mode).

 

I know the difference between USART and UART, and asynchronous and synchronous. You can use a USART for an asynchronous serial transmission. The designer has this option if the cpu of his choice has only a USART on the substrate. For the sake of argument, I used the USART to cover all cases. So we are both correct.

 

Yes, a UART typically outputs one bit for either a rising or falling clock edge. What you're apparently failing to account for is that the clock signal only has one rising or falling edge per cycle. In other words, the bit's width is the same as the clock's period - the clock undergoes a high and low state for each bit's high or low state. Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

 

Right you are. In order to generate a 31.25Kbaud MIDI data word, the word clock to the UART/USART would have to be twice the baud rate, IE 62.5Khz. My error.

 

If you were to view a 10-bit MIDI message consisting of alternating states which comprises a square wave, you will find that the frequency is 31.25Khz. I verified this frequency on my oscilloscope when I built my senior project.

[JeffLearman]

Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

Close but no cigar.

 

First, we're talking about UART and not a modem. If we were talking about a modem, you'd be right. Modem signal transmission and reception are designed to use minimum bandwidth on the transmission line, for obvious reasons. Lots of tricks are used (which I bet you guys can go on for days about) to do this.

 

But I recall looking at UART outputs on good ol' fashioned analog oscilloscopes, and those waveforms look square as all getout, even at the highest data rates (at that time, 64KBaud).

 

The frequency content of the signal is way over the baud rate.

 

Now, how much of that frequency content can be lost and still recover the signal? I don't know, but I bet it's well over half the baud rate, or most of those clever tricks that modems employ wouldn't be necessary.

 

(Admittedly some still would, for example to provide a signal with no DC component, as DC is fine on a simple transmission line like a MIDI cable, but not over a phone line. And admittedly a lot of the hocus pocus was to get a 64 kbaud signal over a line that's nominally 8k audio bandwidth.)

 

It might be interesting to add a simple lowpass filter on a MIDI cable and see how low we could go before we start getting signal losses. In any case, the 50 foot length is intended to avoid signal loss due to *something*, and if it's not high frequency loss, I can't imagine what it could be.

 

Of course, since the spec requires operation up to 50 feet, chances are good that a given implementation, with quality cables, will go quite a bit farther.

[MIDI2XS]

Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

Close but no cigar.

[...]

But I recall looking at UART outputs on good ol' fashioned analog oscilloscopes, and those waveforms look square as all getout, even at the highest data rates (at that time, 64KBaud).

 

The frequency content of the signal is way over the baud rate.

I never said otherwise. The last few posts have been about the fundamental (pulse) frequency, not the harmonics. I'm well aware of the the harmonic composition of a square wave - see my 10/30/13 06:09 PM post (#2539937) in this thread.

 

[MIDI2XS]

KBaud is equal to Khz, but neither are not (always) equal to Kbps. There is zero mention in the MIDI spec of bps or using the half cycles of the clock signal as data bits.

Kbaud is not equal to kHz, and in this case kbaud is equal to kbps (as I explained above).

 

Baud rate is the number of signal or symbol changes per second. In the case of MIDI, it is signal changes per second. If the signal were to alternate for every data bit, this would be a repetitive signal with cycles per second, which was the predecessor unit (cps) for frequency before hertz was adopted in the 1960s.

Gee, thanks for the lesson. I was already in electronics for several years when cps became hertz (in honor of Heinrich Hertz, without whom we likely wouldn't be having this "interesting" discussion).

 

The point is that the peak pulse frequency occurs when consecutive bits alternate, and it's that peak pulse frequency that determines how good the cable has to be. You were the one who initially quoted the MIDI spec, and 320µS per 10-bit byte. I'm sorry if you're unwilling to accept that inversion leads to 10 bits per 320µS, or 31,250 bps.

 

 

The 31.25Khz is a WORD CLOCK. It is a synchonization signal for the USART - the crucial component of every MIDI transmitter. Depending on the USART, the clock input triggers on either the rising or falling edge, or the TTL high or low level. Whatever the trigger scheme used, the USART pumps out a serial bit with every trigger event. That trigger event has to happen every 32us - at a frequency of 31.25Khz. Thus the MIDI data message is a 31.25Khz signal.

As you correctly stated previously, the MIDI protocol is Asynchronous. There's no specific need for a USART, which is a Universal Synchronous/Asynchronous Receiver/Transmitter. Since MIDI doesn't run synchronously (where there are no start/stop bits), a UART is all that's required, and is what's specified in the document (although you could use a USART in UART mode).

 

I know the difference between USART and UART, and asynchronous and synchronous. You can use a USART for an asynchronous serial transmission. The designer has this option if the cpu of his choice has only a USART on the substrate. For the sake of argument, I used the USART to cover all cases. So we are both correct.

I didn't say that a USART couldn't be used - in fact, you quoted me saying "although you could use a USART in UART mode". When I was actively working on MIDI hardware, the UART was a dedicated chip, not "a USART on the substrate".

 

 

Yes, a UART typically outputs one bit for either a rising or falling clock edge. What you're apparently failing to account for is that the clock signal only has one rising or falling edge per cycle. In other words, the bit's width is the same as the clock's period - the clock undergoes a high and low state for each bit's high or low state. Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

 

Right you are. In order to generate a 31.25Kbaud MIDI data word, the word clock to the UART/USART would have to be twice the baud rate, IE 62.5Khz. My error.

 

If you were to view a 10-bit MIDI message consisting of alternating states which comprises a square wave, you will find that the frequency is 31.25Khz. I verified this frequency on my oscilloscope when I built my senior project.

Your error is not that the clock "would have to be twice the baud rate, IE 62.5Khz", it's that you won't accept that 32µS wide bits and a 31.25kHz pulse frequency don't "compute".

 

If you still believe that the narrowest bit pulses for MIDI messages as seen on a 'scope (~32µS wide) are indicative of a 32.15kHz frequency, and don't comprehend that if consecutive pulses alternated H-L, 64µS would be the period, I don't have much more to convince you. Perhaps this, if my ASCII diagram for UART output upon clock rising edge shows well enough:

 

|****|        |****|        |

|        |____|        |____| clock 32.15kHz

 

|------T-----|------T-----| T = 1 clock period (each ~32µS)

 

|******** |                  |

|                 |_________| adjacent bits H-L, UART output

 

Note that the UART output is at half the 32.15kHz clock frequency.

[The Real MC]

I don't agree, I'm done, I'm not conceding, I'm tired of arguing. Discussion over.

[Theo Verelst]

Reminds me of '84 when i built my self-designed MIDI-out interface for a TRS-80 clone, by reverse engineering a Poly-800 Midi connection..

 

About the signal delay in Midi-through: think about it that an electronic buffer stage with TTL/CMOS gates and opto-couplers will normally exhibit a phase delay quite less than the bit delay.

 

T

[JeffLearman]

Thus the MIDI data message is NOT a 31.25kHz signal - it's a 31.25kbps signal, which is at most a 15.625kHz one.

Close but no cigar.

[...]

But I recall looking at UART outputs on good ol' fashioned analog oscilloscopes, and those waveforms look square as all getout, even at the highest data rates (at that time, 64KBaud).

 

The frequency content of the signal is way over the baud rate.

I never said otherwise. The last few posts have been about the fundamental (pulse) frequency, not the harmonics. I'm well aware of the the harmonic composition of a square wave - see my 10/30/13 06:09 PM post (#2539937) in this thread.

Right: you said

a cable capable of handling 80kHz (5x16kHz) over the intended distance should be adequate

I buy that, but it contradicts what I quoted above, which is what I was objecting to ("it's a 31.25kbps signal, which is at most a 15.625kHz one"). In the context of signal degradation, this is incorrect and misleading. But earlier you did put it correctly. The rest is pretty much irrelevant, and I suspect it's mostly a semantic disagreement.

 

[JeffLearman]

About the signal delay in Midi-through: think about it that an electronic buffer stage with TTL/CMOS gates and opto-couplers will normally exhibit a phase delay quite less than the bit delay.

That would be less than a microsecond, rather than milliseconds, right?

[MIDI2XS]

Right: you said

a cable capable of handling 80kHz (5x16kHz) over the intended distance should be adequate

I buy that, but it contradicts what I quoted above, which is what I was objecting to ("it's a 31.25kbps signal, which is at most a 15.625kHz one").[...]

Music student's question: What frequency is A above middle C?

Musician's answer: 440Hz in the US and UK, 442/443Hz in continental Europe.

Engineer's "answer": Well, depending on the instrument, there are various possible overtones, so...

 

Random person's question: Hey, where do I tune my radio to get that station?

Ordinary person's answer: It's on AM at 880.

Another engineer: That would be 880kHz, but there are sidebands due to modulation, and if the station overmodulates then...

 

Now don't anyone get upset - being a member for many decades of the group I just poked fun at, I have certain rights.