Music Player Network
Previous Thread
Next Thread
Print Thread
Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

Another cool aspect is that it is possible for MIDI 1.0 devices to take advantage of this. I'm not sure whether manufacturers will go back and update firmware or whatever for MIDI 1.0 devices, although some probably will. However even when MIDI 2.0 comes out, there will still be situations where new MIDI 1.0 devices are manufactured, because they won't need the extra resolution and such. These can incorporate Jitter Reduction time stamps.

The bottom line is that timing will be much tighter. Another twist is that timing doesn't deteriorate as data streams get more complex.

1 member likes this: hard truth
Sound, Studio, and Stage Island
Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
I was building a MIDI accessory. I noted that the standard optocoupler circuit in the MIDI spec takes the output at the collector with a pullup and wondered what about using a pulldown at the emitter. You have to amplify the weaker output but the transients are a LOT faster. Faster propagation time too.

Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
I don't think we're going to be seeing a lot of opto-couplers and 5-pin DINs in the future, there's probably more MIDI going over USB these days than over DIN.

Interestingly the Universal MIDI Packet, which incorporates MIDI 1.0 and MIDI 2.0, is transport-agnostic. So if there's a new UniversalFireThunderbus protocol 15 years from now, the data won't care about the change.

Joined: Jan 2015
Posts: 614
Likes: 43
N
Gold Member
Offline
Gold Member
N
Joined: Jan 2015
Posts: 614
Likes: 43
This is actually a big deal. Anyone with a big modular rig and a DAW has had to deal with sync issues. There are products specifically to solve these issues. Glad to hear of this - this is a foundational capability that won't make a big splash initially, but over time will become critical.

Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
Originally Posted by Nathanael_I
This is actually a big deal. Anyone with a big modular rig and a DAW has had to deal with sync issues. There are products specifically to solve these issues. Glad to hear of this - this is a foundational capability that won't make a big splash initially, but over time will become critical.

There's a lot about the MIDI 2.0 spec that was designed with the intention of it lasting as long as MIDI 1.0. That's a tall order in today's tech world, but I think there's a pretty good shot at that becoming true. I'm sure there will be additions, as there were to the MIDI 1.0 spec, but the core specs seem pretty forward-looking.

Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
Originally Posted by Anderton
I don't think we're going to be seeing a lot of opto-couplers and 5-pin DINs in the future, there's probably more MIDI going over USB these days than over DIN.

Interestingly the Universal MIDI Packet, which incorporates MIDI 1.0 and MIDI 2.0, is transport-agnostic. So if there's a new UniversalFireThunderbus protocol 15 years from now, the data won't care about the change.

We are both EEs. Optocouplers and current loops were the key to preventing ground loops. Ground loops are a problem with USB MIDI. How does MIDI 2.0 propose to resolve ground loops without optocouplers?

Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
Originally Posted by The Real MC
We are both EEs.

Well, actually I'm not. Dropped out of college after a year, to tour with a rock and roll band smile

Quote
Optocouplers and current loops were the key to preventing ground loops. Ground loops are a problem with USB MIDI. How does MIDI 2.0 propose to resolve ground loops without optocouplers?

There's nothing that prevents companies from using MIDI 1.0 / DIN / opto-couplers if they think that will serve their needs better. MIDI 2.0 is more MIDI, not less MIDI.

I haven't experienced problems with USB and ground loops, so it hasn't really been on my radar. My understanding is that something like a USB controller is just feeding data, not audio, into a system, so ground loops become a factor only after the system has to interface with audio...yes? So far I haven't seen anything in MIDI 2.0 about audio over USB, just data.

Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
Originally Posted by Anderton
Originally Posted by The Real MC
We are both EEs.

Well, actually I'm not. Dropped out of college after a year, to tour with a rock and roll band smile

I'm an EE, but most of what I know about audio and solving problems with audio equipment wasn't learned in college, but rather from my ham radio experience early on (long before college) and from a few audio engineering experts half way through my vanilla career as a g'u'mmint injineer.

Quote
I haven't experienced problems with USB and ground loops, so it hasn't really been on my radar. My understanding is that something like a USB controller is just feeding data, not audio, into a system, so ground loops become a factor only after the system has to interface with audio...yes? So far I haven't seen anything in MIDI 2.0 about audio over USB, just data.

"Ground loop" isn't the right term for the problem that can occur in audio when there are USB connections involved. It's essentially the "Pin 1 problem" as described by Neal Muncy and thoroughly discussed in the June 1995 issue of the AES Journal (now available as an AES special publication). Computers can have a lot of crap on their ground that gets connected to the ground of the audio device through the shield of a cable. If the ground system of the audio device isn't properly designed to keep the audio and chassis grounds bonded for a very low impedance connection, that ground noise can be introduced on to the audio.

Audio manufacturers have been hip to this for a while now, and are doing a better job with internal grounding than they did in the 1980s - 1990s, when the noise floor for your average Shure mixer or Yamaha synth was high enough so that Pin 1 noise was, well, down in the noise. But as noise floor lowered, the influence of external noise became more bothersome.

Joined: Aug 2006
Posts: 288
Likes: 6
Senior Member
Offline
Senior Member
Joined: Aug 2006
Posts: 288
Likes: 6
Originally Posted by Anderton
The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
Originally Posted by Greg Mein
Originally Posted by Anderton
The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

They can if they wait to respond until the right time according to the time stamp. Each device might not receive the data at the same time, but it it's able to sit there and wait until the time (relative to the time stamp) comes around, they can all fire off at the same time. It could slow down the near-real time response a bit but the worst case shouldn't be any worse than that of the slowest-responding device. That's sometime a problem with soft synths, but not because of data transfer, rather it's because of how long the program takes to produce the sound.

Another side of the coin is - who cares? If you're programming the same drum hit on four different snares, yeah, you might notice some flamming, but time code synchronization could improve this. And who's going to notice if the lights change 20 milliseconds after the explosion sample plays?

1 member likes this: Greg Mein
Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
Originally Posted by Greg Mein
Originally Posted by Anderton
The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

The limitations of the 31.25k Baud rate doesn't exist inside the computer, only if feeding something like an external hardware synth using 5-pin DIN. The new Universal MIDI Packet (UMP) data structure in MIDI 2.0 handles data entirely differently compared to MIDI 1.0, although you can embed MIDI 1.0 data in the packet for backwards compatibility. One of the biggest differences in MIDI 2.0 hardware will be UMP compatibility.

If 32-bit controllers had to send their data out at 31.25 kBaud, we'd all be in trouble!

Joined: Feb 2001
Posts: 7,504
Likes: 203
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Feb 2001
Posts: 7,504
Likes: 203
Originally Posted by Mike Rivers
"Ground loop" isn't the right term for the problem that can occur in audio when there are USB connections involved. It's essentially the "Pin 1 problem" as described by Neal Muncy and thoroughly discussed in the June 1995 issue of the AES Journal (now available as an AES special publication). Computers can have a lot of crap on their ground that gets connected to the ground of the audio device through the shield of a cable. If the ground system of the audio device isn't properly designed to keep the audio and chassis grounds bonded for a very low impedance connection, that ground noise can be introduced on to the audio.


Totally agree. This is also the case with AES/EBU. A few years ago I had a bitch of a time figuring out why moving my mouse caused audible artifacts. Once I lifted all 8 shield grounds on my RME AES-32 DB25 connectors life was good.

Joined: Feb 2001
Posts: 7,504
Likes: 203
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Feb 2001
Posts: 7,504
Likes: 203
On second thought...how is this not a ground loop? The noise that’s on the computer ground should be going to ground via the computer AC. But instead it’s making its way to the audio device via the shield connections in my AES/EBU case or USB pin 1 and into the audio signal; either via coupling or “substrate bleeding” onto the signal lines/circuits. I believe that’s still a type of ground loop although the source of the noise is understood.

Is the USB pin 1 issue so different that it’s not technically a ground loop?

Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
I agree. How is this NOT a ground loop. Ground noise artifacts can ONLY happen when current flows between two different voltage potentials, and this is ONLY possible with a closed loop.

Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
Originally Posted by Markyboard
Is the USB pin 1 issue so different that it’s not technically a ground loop?

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.

Joined: Sep 2016
Posts: 63
Likes: 3
Senior Member
Offline
Senior Member
Joined: Sep 2016
Posts: 63
Likes: 3
Originally Posted by Anderton
The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

Another cool aspect is that it is possible for MIDI 1.0 devices to take advantage of this. I'm not sure whether manufacturers will go back and update firmware or whatever for MIDI 1.0 devices, although some probably will. However even when MIDI 2.0 comes out, there will still be situations where new MIDI 1.0 devices are manufactured, because they won't need the extra resolution and such. These can incorporate Jitter Reduction time stamps.

The bottom line is that timing will be much tighter. Another twist is that timing doesn't deteriorate as data streams get more complex.


32 microseconds?

Isn't that 1,000,000 / 32?
or
1 bit at 31,250 bps?

[i]Taken from "M2-104-UM_v1-0_UMP_and_MIDI_2-0_Protocol_Specification,pdf" section 4.8.2 and 4.8.3.

Strange number that, now where have I come across it before?

Oh! Yes.
One bit at the old MIDI 1 DIN interface transmission rate.
Isn't it odd that the same things keep turning up again and again?
Nothing new under the sun, eh?

To be honest, I've been reading and re-reading that part of the protocol specification (section 4.8) and haven't yet been able to relate it to real life.

I expect it's me.

Say a two handed chord (six notes) played on a MIDI 2 compliant keyboard (sending either MIDI1 or MIDI2 messages, UMP encoded) has the timestamp prepended to each Note On,
but the six messages happen to get split across two USB packets because of USB timing, just how do they get reassembled at the receiving end (also MIDI2 compliant),
assuming it's a computer with VSTi's or some kind of new sound module?

Does the first batch of notes get delayed in the input buffer awaiting the second, or what?
Or, is it completely irrelevant in this situation?

Sorry, I just can't figure it out.

Can't wait for the MIDI 2 SMF specification to arrive.
MIDI 2 files are going to get quite a bit bigger, aren't they?

Oh, and will a MIDI 2 file name sufffix be different from a type 1?
e.g. filename.md2
And I suppose the file header information will change too?

Enquiring 74 year old minds need to know. ;-)

JohnG.

Last edited by JohnG11; 01/11/21 07:23 PM.

Akai EWI 4000, VL70m, AN1x, PX560.
Joined: Feb 2001
Posts: 7,504
Likes: 203
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Feb 2001
Posts: 7,504
Likes: 203
Originally Posted by Mike Rivers
Originally Posted by Markyboard
Is the USB pin 1 issue so different that it’s not technically a ground loop?

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.


Despite the number of hours/days/weeks I've spent chasing ground loops my brain doesn't easily remember what I've learned. It also doesn't rest until things make sense. I always appreciate a refresh and the potential to learn something new that I may have missed. Thanks Mike and Mike for your insights.

Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
Originally Posted by Mike Rivers
Originally Posted by Markyboard
Is the USB pin 1 issue so different that it’s not technically a ground loop?

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.

Nope.

The metal housing could be connected to chassis ground at any port. Therein lies the crucial difference.

"Pin 1 problem" argues the purpose of pin one. In the audio world of XLR balanced connections, it is accepted that pin 1 is SIGNAL GROUND and the metal housing is CHASSIS GROUND. Chassis and signal ground should NEVER be connected. Chassis is the earth connection at power entry; signal ground is far removed from that as it is referenced at a tap of the secondary of the power transformer. Due to this configuration there is a very real possibility of voltage potential difference between the two grounds. Short them together and you create a closed loop where noise current can now flow.

Same problem exists in the USB interconnect. Metal housing (potentially) connected to chassis to earth, signal ground (pin 1) connected to a tap on the power transformer secondary. It's not a "special case of ground loop", it's the same configuration with the same vulnerability to ground loop.

I studied power transmission, power supply design, and computer systems in college and have been a systems engineer with experience in grounding practices since 1988.

The MIDI 1.0 specification solved the ground loop problem with its current loop architecture which does not need a reference, and by mandating that pin 2 (cable shield) be connected to ground at the MIDI output/thru ports but NOT at the input port.

I make my own MIDI cables and I/O panels with DIN jacks. I always had intermittent MIDI hiccups over the years. When I built my stage MIDI system the hiccups went into overdrive. I found I had inadvertently created a closed circuit from cable shield to chassis ground. When I assembled my MIDI cables, the cable clamp on the plug connected to cable shield. That clamp is the metal housing of the MIDI plug. At my custom I/O panel, the metal housing on my MIDI DIN jacks connected to chassis through the rack panel through rack rails through rack devices whose chassis were tied to power earth. Insert plug into jack and poof, a closed circuit between grounds. Although no one could hear the ground noise, it had corrupted the MIDI signals. I had to open all my DIY MIDI cables and add shrink sleeving to insulate the shield wire from the cable clamp, and bingo no more MIDI hiccups. NEVER connect MIDI pin 2 shield to chassis.

Joined: Aug 2013
Posts: 92
Likes: 3
S
Senior Member
Offline
Senior Member
S
Joined: Aug 2013
Posts: 92
Likes: 3
Originally Posted by JohnG11
32 microseconds?

Isn't that 1,000,000 / 32?
or
1 bit at 31,250 bps?

We were not specifically targeting a match to the 1 bit at 31,250 bps. It just turned out that way.
We had a certain number of time bits available and practical timing accuracy goals to meet.
It's a convenient time value for devices with a 1 MHz clock.

Originally Posted by JohnG11
To be honest, I've been reading and re-reading that part of the protocol specification (section 4.8) and haven't yet been able to relate it to real life.
...
Say a two handed chord (six notes) played ... get split ...

Does the first batch of notes get delayed in the input buffer awaiting the second, or what?

Removing jitter always requires adding latency. When the connection is first made there is a burst of JR Timestamps data so the receiver can make some determination about jitter on the connection, then add an appropriate amount of latency. That might typically be up to a few milliseconds. From there the Sender puts JR Timestamps on every message. The receiver is delaying everything coming in, reassembling it and assigning timing according to the JR Timestamps of each event, before performing the data.

Originally Posted by JohnG11
Can't wait for the MIDI 2 SMF specification to arrive.
MIDI 2 files are going to get quite a bit bigger, aren't they?

Oh, and will a MIDI 2 file name sufffix be different from a type 1?
e.g. filename.md2
And I suppose the file header information will change too?

MIDI Association members are working on defining the SMF2 format now. It will have notable differences from the original formats. I predict it will take another year to complete.

Mike.


Mike Kent
- Chairman of MIDI 2.0 Working Group,
- Co-Author of USB Device Class Definition for MIDI Devices 1.0 and 2.0
- Member of MIDI Association Technical Standards Board
Joined: Sep 2016
Posts: 63
Likes: 3
Senior Member
Offline
Senior Member
Joined: Sep 2016
Posts: 63
Likes: 3
Thanks very much for your rapid response, SynMike.

Originally Posted by SynMike
We were not specifically targeting a match to the 1 bit at 31,250 bps. It just turned out that way.
We had a certain number of time bits available and practical timing accuracy goals to meet.
It's a convenient time value for devices with a 1 MHz clock.

Sorry, I didn't mean to imply that you were copying the DIN interface transmission rate, just isn't it odd how when we do things like this we turn up with the same number?
A 1 MHz clock subdivided will often give the convenient figure of 31,250.
And, of course, it existed before MIDI, because it happens to be a clock frequency we can feed to the UART.

Quote
Removing jitter always requires adding latency. When the connection is first made there is a burst of JR Timestamps data so the receiver can make some determination about jitter on the connection, then add an appropriate amount of latency. That might typically be up to a few milliseconds. From there the Sender puts JR Timestamps on every message. The receiver is delaying everything coming in, reassembling it and assigning timing according to the JR Timestamps of each event, before performing the data.

Okay, yes a trade off. Thanks for that, I'll have to think about the implications. It certainly makes more sense now. (Thinking cap goes on.)

Quote
MIDI Association members are working on defining the SMF2 format now. It will have notable differences from the original formats. I predict it will take another year to complete.

Mike.

Okay, yes, thought it might take a while.

Do we have any insights to completed parts yet?
Header, obviously, but still three file types; 0,1 & 2?
Similar chunks perhaps with more in them, but maybe new group chunks?
Any changes to delta timing?
TPQN still the same?

Curious minds are seeking early insights.
(Especially this one.)

Thanks again,
JohnG.

Last edited by JohnG11; 01/12/21 10:26 AM.

Akai EWI 4000, VL70m, AN1x, PX560.
Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
Originally Posted by The Real MC
The metal housing could be connected to chassis ground at any port. Therein lies the crucial difference.

"Pin 1 problem" argues the purpose of pin one. In the audio world of XLR balanced connections, it is accepted that pin 1 is SIGNAL GROUND and the metal housing is CHASSIS GROUND. Chassis and signal ground should NEVER be connected. Chassis is the earth connection at power entry; signal ground is far removed from that as it is referenced at a tap of the secondary of the power transformer. Due to this configuration there is a very real possibility of voltage potential difference between the two grounds. Short them together and you create a closed loop where noise current can now flow.

That's correct when you're inside the box, but when you have two boxes connected together that might (and usually do) have different voltages between the cable shield and the brown stuff under the house, that's something that must be dealt with. Good practice is to bond the signal ground (pin 1) to the shield at one single point inside the box, as closely as possible to where the cable enters the box, and with the lowest impedance path as possible.

Where we started running into problems was with audio devices built with XLR and 1/4" connectors mounted on the circuit board, with Pin 1 (or the phone plug sleeve) having a haphazard path to the chassis ground, often through a circuit board trace, or a connector with a metal shell secured to a plastic case.

As a sometimes tech writer, I try to avoid (and correct) the use of terms that have become part of the vernacular that may not be completely accurate. "Ground loop" has become the common term for any cause of hum that occurs when two boxes are connected by a cable. This is most critical with unbalanced connections where the cable shield carries signal current. When there's a separate conductor between the boxes that carries ground but (hopefully) no signal, then the current caused by different ground potentials between Pin 1 on the two units, hum is induced locally within the box rather than being carried along with the signal on a conductor between the boxes. That's the distinction. But, yes, there is a "loop," but there's a more accurate description.

As an off-topic warning, I'm getting rather testy about the use of a couple of other contemporary popular terms/. One is the use of "saturation" to describe distortion resulting from anything, not just from a component that limits the maximum level that its output can reach regardless of input level, with a rise of harmonic distortion between the onset of non-linearity and maximum output level. And then there's "pivot," a term that's been overused by news media lately. I don't want to hear about a musician who has "pivoted" from playing bars to composing background music for the local podcasters.

Grumble, grumble, grumble.

Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
Originally Posted by Mike Rivers
As a sometimes tech writer, I try to avoid (and correct) the use of terms that have become part of the vernacular that may not be completely accurate.

The more accurate term is "0v reference". They are relative to their local power systems. "Chassis ground" is the 0v reference relative to utility power source (can vary with countries other than US though). "Signal ground" is the 0v reference relative to a signal. "Analog ground" and "digital ground" are 0v reference relative to the power supply in a local device. Never assume these are all the same potential. Design convention is to couple any non-chassis 0v reference to chassis through a low value resistor with a cap across it so that ground noise flows across the resistor and not through local circuits.

Quote
"Ground loop" has become the common term for any cause of hum that occurs when two boxes are connected by a cable. This is most critical with unbalanced connections where the cable shield carries signal current. When there's a separate conductor between the boxes that carries ground but (hopefully) no signal, then the current caused by different ground potentials between Pin 1 on the two units, hum is induced locally within the box rather than being carried along with the signal on a conductor between the boxes. That's the distinction. But, yes, there is a "loop," but there's a more accurate description.

You're an EE. I would argue that the more accurate description lies in the Thevenin (or Norton) theorem. Any network of closed loops consisting of voltage sources (or current sources for Norton) and passive impedances can be reduced to a single loop with a single voltage source and impedance. When you have two ground points with non-equal potentials, this fits the definition of a voltage source. Connect them together and you create a closed loop. Since they are ground points they are technically a ground loop which follows Thevenin's theory.

Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
OK, have it your way. Let it be a ground loop, because that's a term that people understand, even if they don't understand it.

So when making a USB connection causes hum, how do you fix it?

Joined: May 2005
Posts: 6,429
Likes: 98
MPN Advisory Board
MP Hall of Fame Member
Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: May 2005
Posts: 6,429
Likes: 98
Originally Posted by Mike Rivers
So when making a USB connection causes hum, how do you fix it?

USB hub with isolated ports.

Joined: Feb 2005
Posts: 788
Likes: 27
MPN Advisory Board
Gold Member
Offline
MPN Advisory Board
Gold Member
Joined: Feb 2005
Posts: 788
Likes: 27
Originally Posted by The Real MC
Originally Posted by Mike Rivers
So when making a USB connection causes hum, how do you fix it?

USB hub with isolated ports.

I didn't know there was such a thing, but sure enough, at least that description brings up several different models. Not cheap, though, and some with pretty poor English descriptions. Have you guys verified that this sort of gadget works to eliminate hum in a practical setup?

Single port USB 2 - $30

4-port USB 3.1 - $220

Joined: Jan 2000
Posts: 9,721
Likes: 241
MPN Advisory Board
MP Hall of Fame Member
OP Offline
MPN Advisory Board
MP Hall of Fame Member
Joined: Jan 2000
Posts: 9,721
Likes: 241
Originally Posted by Mike Rivers
Originally Posted by The Real MC
Originally Posted by Mike Rivers
So when making a USB connection causes hum, how do you fix it?

USB hub with isolated ports.

I didn't know there was such a thing

Nor did I. The single power USB2 you referenced looks to be specifically about audio isolation. I got the impression that the 4-port one was more about if something bad happened on a port, it wouldn't happen to the other ports, or the port into which the hub connects. Or something.


Moderated by  Anderton 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5