Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dan Mortensen]

Yes. This is what I believe. The mobile stage they bring in is 20’x40’ and also carpeted. The room itself is 75’x125’ and full wall to wall carpet.

Two points:

1) I believe it was you who brought up using an analog snake to a stage box located at the console. If that was indeed you, and if that practice is to avoid ESD problems that would otherwise be caused by using a problem CAT snake to reach the stage box onstage, I don't get why ESD is not still a problem, because ANY length of wrong CAT in the system will still result in ESD problems IF you are having ESD problems at all.

It has been amply demonstrated that the ESD contact can occur anywhere in the wrong system, including mics and other devices onstage connected via pin 1 to the PA. Moving the stage box to FOH won't change that.

Connecting the analog snake directly to the console and not using AES50 will stop that kind of problem.

If that's not why you were doing that, now readers know that it's not a solution for ESD problems.

2) The snake that you describe as being properly shielded and grounded is behaving exactly as if it is not. You are just a guy on the Internet to me, so I would suggest you double/triple check that all parts of your cable are correctly set up.

Since I am just a guy on the Internet to you, you will do as you please.

A third, semi-related point: There are over a million X32 family consoles out in the world, or at least I heard that a year or two ago. No doubt they are being used in almost every situation imaginable. The fact that there are a small number of reports of intractable problems seems inevitable (maybe your console specifically has a problem?), and the fact that the number is small is proof that the platform is decently robust. Perfectly, no, but decently.

[Rob Spence]

Yes. This is what I believe. The mobile stage they bring in is 20’x40’ and also carpeted. The room itself is 75’x125’ and full wall to wall carpet.

If it is a metal framed stage, are you grounding it?


Sent from my iPad using Tapatalk Pro

[Jonathan Betts]

Rob, it is a metal framed stage. Grounding the stage had never occurred to me. What would be the best way to go about this?

Sorry to have directed this thread away from the OP.

[Kevin Maxwell]

And get a humidifier?

In the room I was referring to that would have had to be a huge humidifier it was a 1400 seat auditorium. 

[Robert Lofgren]

And I will repeat my mantra.

Avoid ethernet cables with pvc (or similar) jackets! The pvc will build-up a static charge in some conditions and eventually discharge.

The longer the cable the ‘better’ the buildup becomes. Breaking up the cable in segments will help as the buildup in each segment becomes less.

[Brian Jojade]

Well that's interesting, if a little sad, that they're using a protocol that has no effective error correction (or at least graceful failure, as some coding methods do) and that that's the root cause. Do all AES 50 implementations suffer from this ESD susceptibility, or is it unique to Beringer?  AES 50 does share Ethernet Physical Layer (OSI Layer 1) with Ethernet so electrically it's the same thing: +/- 2.5 V balanced sent over twisted pairs of 110 Ohm characteristic impedance, etc.

If this really is the case it is a testament to the robustness of all other audio-over-Ethernet protocols that they can withstand all those blown-away bits without a hiccup.

--Frank

The pinout of AES50 is:
1 - Audio data transmit +
2 - Audio data transmit –
3 - Audio data receive +
4 - Sync signal transmit +
5 - Sync signal transmit –
6 - Audio data receive –
7 - Sync signal receive +
8 - Sync signal receive –

The only similarity to Ethernet is the cable/connectors used.  Because the audio signal and sync signal is on separate pairs instead of streamed down the same wire, and disruption in the signal and timing between the pairs can cause issue.  ie, sudden moving and twisting a wire can cause minute sync issues disrupting the signal.

The reason they went with separate sync and audio is to reduce overall latency.  Had they added sync and audio down the same conductors, the sync signal would have to be in series with the audio signals, adding a delay.  It's a trade off that was decided to be important.  Making sure you use the RIGHT cable is critical.

Yes, I certainly would have preferred if the system would immediately mute if something were amiss instead of creating a virtual shotgun!  But, once I stopped trying to make cheap unprotected cable work, I've had zero issues.  Don't get mad at the limitations of gear, just deploy it in a way that the limitations are not exposed.

[Dan Mortensen]

The longer the cable the ‘better’ the buildup becomes. Breaking up the cable in segments will help as the buildup in each segment becomes less.

Robert, surely you're not advocating a snake made up of multiple pieces of CAT cable with couplers running through a crowd? Or outside in the weather?

[Frank Koenig]

The only similarity to Ethernet is the cable/connectors used.  Because the audio signal and sync signal is on separate pairs instead of streamed down the same wire, and disruption in the signal and timing between the pairs can cause issue.  ie, sudden moving and twisting a wire can cause minute sync issues disrupting the signal.

Yes, I certainly would have preferred if the system would immediately mute if something were amiss instead of creating a virtual shotgun!  But, once I stopped trying to make cheap unprotected cable work, I've had zero issues.  Don't get mad at the limitations of gear, just deploy it in a way that the limitations are not exposed.

I did a little digging on AES 50. It employs forward error correction of some sort. (I don't know which method -- I suppose I should try to get my hands on the standard itself.) It is, or at least can be, isochronous so it should be possible to recover a corrupted clock, within limits, using the right kind of phase-locked loop. (Strictly speaking, this would be a frequency-locked loop as it needs to freewheel over missing or extra pulses. A true PLL will smooth over missing pulses but at the end of the day the number of pulses into both inputs of the phase detector is equal.)

The designers of the standard attempted to make the channel robust. Either they didn't go far enough or, as I suspect, there is a HARDWARE problem with Behringer's implementation that makes it especially susceptible to ESD. The real question is, do all AES 50 implementations suffer from this? Who else uses AES 50 -- for anything (serious question)?

I agree that happy people learn to make do with the gear they've got. It's the end result, not the tool, that matters most. As an engineer, I take an interest in what appears to work and what doesn't, and try to understand why. As a consumer, I don't get angry (too much), I just try to steer away from dodgy gear. That's why I value so much comparing experiences here.

--Frank

[Robert Lofgren]

That would be cool ;-) 

No, my suggestion is to use a cable with a rubber sleve or similar static-free sleve. Ethernet cables for industrial environments do exist, rather than the office type of cables.

Leave the pvc cables as for patch cables and shorter runs, where the buildup usually becomes negligible. Also, use cables with separate chambers as for mechanical and electrical stability.

That being said - I do use an El’Cheapo pvc cable at times when there is an elevated risk for it to break.

Robert, surely you're not advocating a snake made up of multiple pieces of CAT cable with couplers running through a crowd? Or outside in the weather?

[Frank Koenig]

I suppose I should try to get my hands on the standard itself.

I downloaded the standard. Unfortunately, like most standards, it's copyrighted with a stern warning not to reproduce it, so I can't put it up here.

At one point early on they RECOMMEND the use of shielded twisted pair. Later they require the bonding of the connector shells to the device frame. Maybe somewhere in there they say that the shield should be bonded as well but I likely missed it. The take home, in any case, is that ESD or other interference was on their minds.

Going into the protocol there are indeed numerous error detection and correction features. Interestingly, near the end there is a discussion of detectable but uncorrectable errors. The protocol allows for interpolation to cover such errors to the extent possible, and requires muting of the audio beyond that.

Interestingly, too, right at the beginning there is mention of patents specifically belonging to Music Group. So MG must have been involved with all this pretty early on. Perhaps others here know more of the history.

I've flogged this dead horse long enough now. Sorry. Carry on.

--Frank

[ProSoundWeb Community]