Telex KP-5032 Key Panel, First Experience

 

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. This includes all system level-balancing and panel programming. 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 as a mixing function. The problem is that the user can turn that knob all the way to “off” without there being any indicator after the fact. This  has caused me several trouble calls. One idea is to make the knob toggle to an additional function to control SIDETONE. That would be a nice default. A continuous display of the current listen level would also be helpful. As with all firmware defined user-interfaces, updates could alter many of these default conditions and may be different in other panels already.

2   The 5032 does not include a legacy D-SUB-9 connector for the analog frame connection. This presents a challenge when integrating to legacy systems.

3  The ADVANCED AUDIO functions, particularly the compressor, only provides ratios of 1:1 (off), 2:1 and 3:1. I typically like to run the analog output of a Director’s panel through a limiter, like a DBX-160X. I select ratios closer to 8 or 10:1 to really protect the ears of everyone listening. 3:1 is not enough. Further, if run in 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

Telex offers the Audio Package software option which includes additional compression ratios, but I have not had a chance to work with any 5032 units with this option.

version.http://www.rtsintercoms.com/ru/rts/product/Software%20Packages/1554

As always, I like to start conversations about these subjects. I especially like to hear counterpoints to correct my myopic opinions.

 

TR6442i Continued…

I got one positive response to my post about the Telecast 6442 recently which motivated me to maybe post some of my in-field observations.

• The 6442, when not linked, will loop the four-wire input to the four-wire output. This can have significant influences on the “side-tone” of the circuit to which the 6442 is connected. If the 6442 is a member of the Camera Conference and suddenly lost its link, maybe do to a fiber-technician cleaning ends, power-loss or whatever, there would suddenly be massive amounts of “loop-back” of the voices on the conference.
• The 6442 uses an RJ-45 connector wired as USOC. This is really an unsupported standard, though it can be found in the Telex Product line. A 568B wired cable will not work in a Telex environment.
• The “right” way to connect a four-wire signal in terms of direction can be a bit of a mystery since the MTX and STA switch positions can reverse the Input/Output function of the pins of the RJ-45.

Again, any thoughts or comments to support or debunk my thoughts are welcomed.

 

 

 

 

 

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”

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.

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.

 

 

 

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.

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.

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? 

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.

 

USOC vs 568B Wiring

USOC vs. 568B

Since the early years of matrix intercoms systems, the McCurdy brand saw broad acceptance at the major broadcast networks in The United States.  It is 2012 in London and I am working with an engineer that refers to the Telex ADAM key-panels as “the McCurdy”. Telex purchased the McCurdy intercom product line and in 1996, when the ADAM DSP/TDM product first appeared in the U.S, it was bound to a McCurdy 9500 controller frame.  The software application was called CSEdit, a DOS program.

McCurdy featured the RJ-12 connector using the USOC (Universal Service Ordering

Code)  wiring convention.  Three unshielded twisted pairs: Audio talk (+/-), audio listen (+/-) and RS-485 data (+/-).

Enter computers and Ethernet.  The now ubiquitous RJ-45 connector used in Ethernet data networks is everywhere.  Intercom system which appeared on the market in later years featured the RJ-45 connector with the 568B wiring convention.  This convention established a data-rate and pair usage that is quite different from the RJ-11/12 (USOC) standard. (disclaimer: this blog entry is not intended to be a tutorial on the FCC 47 Part 68.  This is a pretty deep subject of nearly 160 pages)

Problems occur when the two wiring standards become intermingled.  The DC-continuity can actually line-up pin-for-pin sometimes, but it is the “splitting of pairs” that wrecks havoc with proper noise immunity and data integrity.  The twisting of the pairs may seem to some as insignificant, but it is a very critical element in the elimination of crosstalk and to the rejection of outside noise interference.

Since backward compatibility is a large part of the recipe for manufacturers to maintain customer loyalty, Telex developed the 1-RU, 32-port intercom system which they have named the “Zeus-III” with,  RJ-45 connectors but still wired to the USOC standard.  This allows an RJ-12 connector to plug into the Zeus using possibly pre-existing cables and key-panels.   One other ADAM System product from Telex features an RJ-45; this is the KP-32-CLD.  In an effort to remain compatible, the CLD is delivered from the factory as USOC but with internal jumpers it can be configured for 568B.

The problem is that Telex has not yet embraced the 568B as a complete option and the co-mingling of the two conventions, even within their own product line, is becoming a big problem.

1             Telex does not make any product that comes standard wired as 568B

2             That product uses an RJ-45 connector.

3             The use of an RJ-45 connector, in today’s world, that is not 568B is a problem waiting to happen

4             Since Telex is not presenting a solution in this area, other end-users and integrators are solving it with yet more incompatible schemes only adding to the confusion.

In conclusion, I would like to see Telex approach this situation proactively and establish a standard. Even if the standard is not yet ready, let the industry know that the situation is being addressed.