Avoiding System Interdependence

“Mission critical signals, be them command/control or streaming, should be contained in separate universes to minimize the propagation of failures. The goal is to achieve interoperability without creating interdependence”.

Compartmentalization is frowned upon these days. It’s all about the team, the mesh, the one-mind vision of the A/V systems being homogenized, smart, completely aware of each other. There is a beauty to this vision that as of late has really begun to take shape across many sectors of our vast industry. From world-wide sporting events to the local night-club and the home recording studio, signals are intermingling like never before.

This intermingling is due to the enormous influence of the Information Technology industry on the use of a common data format. Simply, Ethernet, in some form or fashion, is everywhere. It carries command/control, TV Network feeds, video signals, telephony, audio, RF and intercom. Every technology specialty uses Ethernet in some form to transport their signals. Since the signals are the same format, the ability to place them all on a shared hardware platform exist, but at what cost?

This attractiveness of single-point-management is countered by the risk of single point failure. The best systems work to accommodate tight integration of systems without the risk of interdependence.

Interdependence is simply the case of otherwise disparate systems sharing any physical piece of hardware or cabling.  It is often thought that since all can be converted to a common data format, such as Ethernet, be it audio, DMX, IPTV, command/control or e-mail, that the signals should run on the same network equipment to minimize cost, rack space and cabling. The downside is that often these systems are specialties that are best dealt with by parallel management workflows.

•The lighting system technicians using DMX should have complete authority over the DMX system without having to contend with the security camera’s signal running through their Ethernet switch.

•The AoIP signals should be able to run independent of camera control so the audio         department can attend to changes, testing, training, etc. without disturbing the camera systems.

Separation of responsibility is also a personnel consideration. Corporate IT professionals are under strict orders to maintain security to the highest degree possible. Cyber-crime is a real concern and a real detriment to us all. It must be taken seriously and the IT professional that stands in the way of an audio technician adding an AoIP device to the corporate network is doing their job and it should be respected. It is for this very reason that corporate IT and A/V networks used in support of what is in essence the IoT in the A/V world, must remain separate. The old motto of “the show must go on” is as real as it has ever been, yet the security firewall and passwords are in place to eliminate ad hoc additions to the network, even if the need is urgent. Each network has its unique purpose and mandates for reliably, accommodation and facilitation. Just because the two industries use the same hardware does not mean they should ever intermingle.

The audio industry has a long history of pulling from existing technology bases. In the early days, we borrowed from the telephone industry, like the Decibel, balanced lines, wet/dry circuits, etc. Today, we have adopted the information technology and computer network hardware to transport, process and store our audio signals. As with the telephone technology, equipped with a firm understanding of network technology, a system designer’s ideas can be elevated above the generic, “catalog-based design”, to one that best supports a customer’s unique workflow, logistical and budgetary requirements.

“Never trade expedient installation for long-term serviceability”

Posted in Uncategorized | Leave a comment

Telex KP-5032, First Impressions

I am serving as the Truck-Compound Intercom Engineer (C2?). Primarily responsible for any deployed truck intercom resources, even if they are in the venue. The truck is MTV Networks “Atlas” which is almost completely OMNEO. Of the 432 ports, only 32 are analog. Because the 5032 can be run as Analog or IP (OMNEO or RVON depending on firmware), the assessment must include the complexities of the connection scheme.

1     The 5032 includes a front-panel AUX VOLUME control knob. The default is to adjust the MATRIX input level. This is intended to be a push-to-toggle between AUX1, AUX2 and the MATRIX signal in a mixing function. The problem is that the user can turn that knob all the way to “off” without any indication after the fact. The panel’s menu system does not allow this to be disabled. This has caused me several trouble calls. One idea is to make the knob toggle to an additional function to control SIDETONE. That should be the default? A continuous display of the current listen level would also be helpful.

2   The 5032 does not include a legacy D-SUB-9 connector for the analog frame connection. This is disappointing when integrating to legacy systems. Though, I do understand that legacy support can hamper the furtherance of a product. Just wish…

3  The ADVANCED AUDIO functions, particularly the compressor, is not powerful enough through the internal menu. Compression ratios of 1:1 (off), 2:1 and 3:1 are offered. I typically like to run the analog output of a Director’s panel through a limiter, like a DBX-160X. Ratios are closer to 8 or 10:1 to really protect the ears of everyone listening. As mentioned above, connectivity can impact the panel’s performance. If connected via an IP/Network topology, there is no way to access the audio signal to patch in an external limiter. The signal would have to be extracted and re-entered to the OMNEO stream as a gain-reduced version. Unless the available audio-process option was purchased for that particular key-panel, access to the audio settings are only accessed at the front panel, not through AZEdit. Not so easy if it is in front of a Director in a crowded TV truck.

As always, these points are hopefully the start of dialog. I appreciate counter points to correct my own myopic observations.

Posted in Uncategorized | 2 Comments

Panel Microphone Preference

Telex offers a slim, black style as the MCP90## where the ## is the length as well as a “0” zero-length stubby version for tight spaces. Clear-Com offers the GM-##, again, the ## is the length. 9″, 12″ and 18″ are common.

I have experienced a much greater propensity for the Telex to be sensitive to aggressive close talking to the point where the key-panel’s compressor actually goes into nearly a mute condition. This is especially true with pops and other breath sounds.

The Clear-Com model, satin finish and of a less slim design, is much more forgiving and consistent across a wide range of talking levels without over-driving the compressor. I prefer to use the Clear-Com model and have had very good results in all versions of the KP32 as well as the Clear-Com products which use a screw-in, TRS mount form-factor.

I have not had may opportunities to experience the panel-microphone from Riedel as a comparison. Can anyone comment?

Would love to hear any other opinions.




Posted in Uncategorized | Leave a comment

KP32 Front-panel Headset Microphone Input: Balanced vs Unbalanced

Has anyone run into inconsistent performance of the front-panel headset microphone input when using un-balanced headsets?  These would include popular headsets such as the Beyer DT-108 or 109, the ASG LWS-4 or 5.  The Telex PH-88 has a balanced wiring configuration which should not be a problem, but the unbalanced headsets, only sometimes, will create a buzz when the talk is activated. I have had to tie pin-3 to pin-1 to essentially “ground” the (-) mic-preamp input.

Posted in Uncategorized | Leave a comment

Telecast 6442i and KP32 compatibility

Has anyone run into the issue of certain Telex KP32 Matrix key-panels not working with the 6442i? The KP32 is perfect when directly connected to the Telex frame but won’t work through the 6442i while other KP32 units will work just fine.

Posted in Uncategorized | 2 Comments

J9 and J10 on the Telex ADAM System

To use J9 and J10 for two additional connections for AZEdit or CLP sessions, it is first necessary to enable them for AZEdit or CLP and set the Baud rate.  In the Communications Setup page, the ADVANCED command button expands the dialog box to provide additional options to configure J9 and J10.  The complication with this stems from the need to first establish an on-line connection with the frame via J1 using an RS-232/null-modem connection. This is the only condition that allows the ADVANCED command button to appear in the communications setup screen. I have seen this before, but this morning I ran into it again and forgot that this was the case. I wasted a few minutes making sense of it all. Connecting via Ethernet will not allow the ADVANCED command button to appear.  Further, even when connected via J9 or J10, the ADVANCED button does not appear.

Does anyone out there use these connections on a regular basis?  Are there any other caveats which need to be understood? 

Posted in Uncategorized | 4 Comments

Telecast TR6442i Initial Review

I received a pair of TR6442i units late yesterday   I say late to emphasis that I still arrived home in time for dinner as these units are ridiculously simple to use.  No menus, no PC to setup, just some clearly identified toggle switches to set the proper modes.

There are a few gotcha’s that were explained to me prior to the setup of the units which did save me time.  One point to note is that the single ST fiber, and the need for bi-directional information, requires a matching set, a “-15” and a “-13” in the model number for the light wave-length to cross-over properly.

The other point  is to really pay attention to the wiring of the RJ-45 connector on the rear-panel.  They are exactly as they say.  On a previous blog post, I spoke of the 568B v s. USOC and how the mingling of the two can wreck havoc on an otherwise fine day.  USOC is an RJ11/12 convention from years back.  RJ45 and 568B are also a common standard in data networks.  The Telex ADAM System (specifically the Zeus-III) mixes the two by wiring RJ45 connectors with the USOC pin-out.  If you don’t know this, the 6442 may appear to need “special’ cables, possibly inferring that Telecast made a design error.  They are not special as much as they are specific.  I have accommodated the RJ45/USOC issue with cables in my rental inventory so this was easy…just place the correct adapter on the ADAM XCP-32-DB9 and an RJ12 cable at the KP32 end and it worked without any issues.

As I mentioned to the factory guys at NAB, the plan of inserting an RJ11 into an RJ45 connector is not terribly cool…while it will mostly work, it is not “what was intended” so be careful to get the RJ12 centered.

I have not yet tried it as a 2-wire interface in the field, but when I demo’ed it at NBA in 2012 it worked very well.

This is a preliminary report..more to follow.


Posted in Uncategorized | Leave a comment