Print

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

[John Roberts {JR}]

man handled by software engineers.

Almost an oxymoron... 

JR

PS: Just kidding.. I code therefore I am... 

[Dan Mortensen]

Something tells me none of the issues expressed in the thread are actually related to the cabling used...

Actually, in finally running across this thread today, I think ALL the issues in this thread are cable-related, based on my experience in accidentally and then intentionally causing the symptoms reported in the OP and researching the why of that.

First, Jan Duwe's quoted response is the most complete statement I've seen from Behringer on the subject, which I've been following closely since early March. He posted a statement in the other forum, but did not go into anywhere as much detail there, and certainly never replied to followup questions. His statement here that they recommend shielded cable (in the other forum I think he specified CAT6, though; the post here is more ambiguous) and the reasons why is good, but, as has been stated by others, appears in no manuals and is different than previous advice from Behringer, in manuals and online.

Second, the protocol used by Behringer/Midas is actually called SuperMAC, which is compliant with the AES50 standard which tells you what it needs to do and not how to get it to do it. I don't get why Behringer/Midas calls it AES50 instead of what it is, but there you go.

There is a SuperMAC webpage, with a series of FAQ's  (homepage: http://www.supermac-hypermac.com  ), one of which talks cable.

Quoting directly:

"What sort of cable should I use for SuperMAC and HyperMAC?

"For short distances, standard unscreened Cat 5 cable is fine. For longer distances, up to 100 metres (the maximum specified by the IEEE 802.3 Ethernet standard for twisted-pair copper cables), we recommend the use of high-grade Cat 5e or Cat 6 cable."

If you are an AES member you can directly download the AES50 standard for free, and see that it is more ambiguous even than what the SuperMAC webpage says above (define "high-grade", for example). There was something at the standards page about how you can't legally quote the standard, so I'll not do it here.

Third, the SuperMAC protocol uses all four pairs in the Ethernet cable. Snipping one or a couple pairs, as someone suggested, will cause it to not work at all.

Similarly, if the other consoles in the OP do NOT use all four pairs, it's possible to see how the same cable would work for one console type but not the X32, if a particular pair were intermittent. I don't know if that's the OP's case, but it's a possibility. I do know that using a cable that had only three pairs caused me to be able to phantom power and adjust trim on an S16, but not have audio transmitted to the console. No screen flicker and no untoward noises.

Fourth, the four pairs in use are two pairs for transmission stage->console (data and sync), and two pairs for data console->stage (data and sync). I don't know how to determine which direction any data disruption is occurring.

We have been unable to find a way to monitor the data transmission in real time, despite the statement on the SuperMAC webpage that one of its advantages is (almost a direct quote) the "easy monitoring of the data stream  by the user".

Fifth, as someone pointed out, the dimming screen and crackling is one result of disruption of the signal transmission through the Ethernet cable. Those are exactly the phenomena I observed when successfully intentionally disrupting the data stream in my shop (once, with many failures trying to disrupt). Based on our experiences in the next section below, I don't believe that shielded/unshielded make a bit of difference in data disruption vs. no data disruption, but rather that it is the pairs' changing relationship to each other and to themselves while being pinched and pulled (causing capacitive and other electric changes) that can disrupt data. Not to say that's the only cause of disruption...

Finally, as a direct result of being mystified by the phenomena described, I put together a workshop for our local AES Section earlier this month, and a description of it and the results, along with my personal conclusions, is at

http://www.aes.org/sections/pnw/pnwrecaps/2013/jun_cat5/

Apparently, if you are so moved, you can listen to audio recordings of the full day and hear how things progressed.

As I say in my conclusions in the writeup, the forces that the group settled on that day to cause disruptions were stronger than I used when doing it on my own, and the dynamic of the day caused us to ignore gentler forces. I don't think the tale is fully told, yet, but there are some indications IMHO.

Also, the only cable we were not able to disrupt in the time we spent on it was an unshielded cable, but it does not have a rugged jacket and so may not be appropriate.

A cable we didn't try was the Gepco tactical 4 Ethernet cables in one, in which the pairs are encased in an extruded binder that locks them in place relative to each other, with an additional jacket on each Ethernet cable and another heavy jacket around all. We didn't try it because I bought it and didn't want to subject it to the signifcant forces we were using on sacrificial cables.

I am answering the question for myself for the rest of the summer, until things settle down and I can explore again, by using analog snake and not using S16's. YMMV.

[Bob Leonard]

Nice response Dan. Where did you find that Behringer was using supermac??

[Lee Buckalew]

Nice response Dan. Where did you find that Behringer was using supermac??

Bob,
That is the protocol that Midas utilized when developing the XL8.  I do not know if it was purchased prior to or after the release of that desk but, in any case they own it so now Behringer is using it to.  I may be wrong but I believe that Midas told me (pre Behringer) that they were licensing it for free to interested users.  Licensing to maintain integrity, free to hopefully garner more industry support for the protocol.  SuperMAC does vary from the AES50 standard in that SuperMAC only allows for 96kHz sample rates.  Not sure if there are othe differences. 

Here's a link http://www.supermac-hypermac.com/information-supermac.php

I wonder if there is an issue with the protocol running at 44.1/48kHz rather than at 96kHz.

Lee

[Dan Mortensen]

Thanks, guys.

Bob,
That is the protocol that Midas utilized when developing the XL8.  I do not know if it was purchased prior to or after the release of that desk but, in any case they own it so now Behringer is using it to.

Bob, I found it in a post by one of the regulars at the other forum, who referred to the SuperMAC webpage.

IIRC, the protocol was developed by Sony for the Oxford console, and when they pulled the plug on pro audio they apparently had no further use for it and sold it to Klark Teknik. When KT and Midas were bought by Behringer, the rest is history. But the history of the timing of the XL8 development/use of the protocol/purchase by Behringer is unknown to me.

One can imagine that when they went looking at what to use with the future console, they found that SuperMAC/HyperMAC were available for purchase which made more sense than to license. But that's speculation.

BTW, the XL8 page http://www.midasconsoles.com/xl8-midasnet.php says it's using HyperMAC, which is the 96k version. SuperMAC is the 44.1 and 48.

I'm looking at the product pages for other Midas consoles, and can't find anything about sampling rate for the Pro 1. The Pro2 definitely 96, the Pro6 probably is although doesn't specifically say except that it uses a HyperMAC snake.

Speaking of snakes, the Pro1 says "The PRO1 is MIDAS’ first stand-alone digital console with 24 inputs located on the rear panel. However there are a number of optional MIDAS digital I/O units – either with fixed or modular configurations - which can be connected by inexpensive Cat5-e cable that will expand the input count to 48. To further increase flexibility a number of I/O boxes can be connected to the PRO1, up to 100m (300ft) cable distance from the console, allowing audio point-to-point routing of up to 100 inputs x 102 outputs from anywhere within the Network."

No mention of shielded cable, and none on any other console page.

[Bob Leonard]

Thanks Dan. I had not looked deeply into supermac after learning some time ago that in order to work to it's full capability supermac required some special hardware (translation), special cable, and had a very low throughput when handling standard IP packets (5mb). I notice that's mentioned in the writeup but nowhere is it mentioned by Behringer in their product docs. Perhaps if Behringer had stated they were using supermac and recommended the proper cable from the beginning this thread would not exist.

When I continued to read more and more stories of problematic stage box connectivity I opted for the Soundcraft Expression, my intro to the digital world. The X32 may have more bells and whistles, but I feel the Soundcraft to be a better live board and with better proven expansion capabilities, stage box included. By the way, and before it's said, the Soundcraft expansion boxes ship with the required option card for the console.
 
For those not familiar with shielded cable I have posted the pictures below. This is not specialized cable using specialized connectors.
 
 

[Lee Buckalew]

BTW, the XL8 page http://www.midasconsoles.com/xl8-midasnet.php says it's using HyperMAC, which is the 96k version. SuperMAC is the 44.1 and 48.

According to KT in a 2013 publication they (KT) have internally standardized on a sample rate of 96kHz for both SuperMAC and HyperMAC.   This provides them with 24 channels bi-directionally for SuperMAC and 192 channels bi-directionally for HyperMAC.  Latency is also lower for HyperMAC. 
SuperMAC is supposed to be AES50 compliant and supports sample rates from 44.1kHz to 384kHz.  It does this with Handel counts from 48 to 6.

I don't believe that the protocol was purchased from Sony until after the XL8 had already been released.

Lee

[John Roberts {JR}]

Dan nice work. Trying to make sense of this, if I read your report correctly, it isn't a matter of shielding and therefore noise corruption, but spatial(?) relationship of conductors to each other within the cables.  So apparently internal conductor to conductor interference. Perhaps a characteristic impedance discontinuity?

Ignoring the possibility of dealing with this electronically it seems a more robust cable design might help.

If these consist of twisted pairs, and the geometry/integrity of that twist matters. perhaps something like the star-quad 4 conductor twist would be more stable. Since this approach could screw with capacitance and probably characteristic impedance, perhaps stay with two real conductors per pair. and two dummy non-conductors to facilitate the consistent spiral wrap. 

Sounds like a bad day for copper.

JR

[Rob Spence]

One thing that was only mentioned in a note by Uli when he said they needed shielded for protection from interference.

 I wonder if the requirement was really because the unshielded cable radiated beyond what was allowed by a regulatory agency and was discovered late in testing near product ship so there was already marketing material that didn't say shielded cable?


Sent from my iPad using Tapatalk HD

[Dan Mortensen]

Dan nice work. Trying to make sense of this, if I read your report correctly, it isn't a matter of shielding and therefore noise corruption, but spatial(?) relationship of conductors to each other within the cables.  So apparently internal conductor to conductor interference. Perhaps a characteristic impedance discontinuity?

Thanks, JR. Your positive comment means a lot to me.

You have it part right IMO (with my still-incomplete understanding of what's going on): within the limited amount of time we spent on this part, RF type interference was not an issue, the issue was the moment of dynamic change of the wire pairs' relationship with each themselves and each other. The (presumed) impedance change caused by varying the spacing of things was enough to temporarily disrupt the transmission. When change stopped, signal transmission was returned to normal.

And, mysteriously to me, when the spacing of things inside the cable was permanently affected by the repeated flattening of a scissor lift, nothing happened during or after the change, and the cable still measured fine afterward.

Ignoring the possibility of dealing with this electronically it seems a more robust cable design might help.

It's important to understand that all Ethernet devices have surprisingly high quality balancing transformers on both ends, and therefore all four pairs are balanced circuits. *Every* device, according to our non-100%-of-everything-in-the-world research. Regarding cable design:

If these consist of twisted pairs, and the geometry/integrity of that twist matters. perhaps something like the star-quad 4 conductor twist would be more stable. Since this approach could screw with capacitance and probably characteristic impedance, perhaps stay with two real conductors per pair. and two dummy non-conductors to facilitate the consistent spiral wrap. 

The Ethernet cable designers are ahead of you.

The one cable we couldn't disrupt (again, in our limited time trying) had a sort of "double H" (HH with no space in between) physical divider running the full length of the cable, which kept the 4 pairs physically separate. Overall it's maybe 3/8" diameter, with a fairly thin looking jacket, so it may not be useful for our purposes. But it does exist, and the Belden guy who was with us learned something from the day, too, and is going to talk with their designers. (It was one of their cables that we couldn't disrupt.)

I also think the GEPCO tactical with double jacket and immobilizing core that I mentioned will do the same thing, but have not proved it.

Sounds like a bad day for copper.

Actually, I thought it was pretty good.

We learned that the solid wire cables of today are very different than those of yesteryear. The mfr's have perfected the art of annealing to such an extent that wire fatigue is almost a thing of the past for solid vs. stranded, at least for this size wire.

We also learned that you can forcibly flatten your Ethernet cable to a very small thickness and it still passes the rigorous testing of the proper Fluke meter with flying colors.

Regarding shielded vs unshielded: still to be tested is the effect on audio and the console/stage box combo when the latter two are powered by AC with vastly different ground potentials/voltage neutral-ground and then connected with shielded snake. That was on our agenda but we forgot, and I haven't had time since to pursue it.

Still on shielded vs. unshielded: in response to Rob's comment about Uli's statement, from my conclusions in the PNW AES report:

"From an American perspective, the European obsession with shielding cables is overblown, and is a response to a problem that has not been demonstrated to exist at a significant enough level to need a solution. Unshielded cables work just fine in almost every application, except for specific environments with very high levels of specific RF interference. The vast, vast, vast majority of users will not benefit from using shielded cables, nor will they suffer ill effects from not doing so. That said, there are specific legal requirements to use shielded cable in certain situations in many legal jurisdictions, and the wise user will pay close attention to those requirements."

[ProSoundWeb Community]