Filter
Top Products
Chapter 5 - Design of Matrix Intercom Systems 69
We talked earlier about how addressing of keypanels is critical in the matrix intercom
system. The way in which addresses work is as follows:
In a given group of 8 panels sharing a common data line, the data gets sent from a
keypanel to and from a matrix by a process called polling. The matrix will broadcast a
signal to all eight panels to the effect of “Panel Number 1, do you have any changes for me
to act upon?” These changes could be as simple as a talk key having been pressed or as
complex as the user wanting to see a list of all available party-lines. The matrix expects an
answer from the panel, either a simple “nope, nothing new to report” or a request for a
specific action.
The matrix normally will not wait very long (less than 10 milliseconds) for an answer
before deciding that the panel in question is not there, and moving onto panel number 2,
and so on, up to panel 8, and then starting all over again at panel number 1. The short wait
is mandated in order to assure quick response to panel requests. This 10 milliseconds is the
“polling window”, the 30 milliseconds between LA and NYC is the “polling delay”.
To make such a system work without unduly slowing down all panels by globally
increasing the system polling delay, you can use the AZ™-EDIT configuration software
to allow a longer poll delay (say 33 milliseconds) for one panel with no appreciable impact
on other panels.
In the case of 250+ milliseconds delay due to satellite transit time, it is common practice to
make sure the keypanel associated with the delay is in a group of eight ports where the
delay is not important. For example, on ports that are used for paging outputs or IFBs,
where there is no other data present.
In these ways, remote keypanels become very manageable and feasible, due in large part
to their common format of standard balanced audio and RS-485 data.
Very Large Systems, Split Operation and Trunking
We have used the term trunking earlier and likened it to the long distance telephone
system. In the case of RTS™ ADAM™ matrix intercom systems, that analogy is very
close to reality. Before we get deeply into trunking, let’s discuss the different ways
available to make large systems.
First, exactly what do we mean by a large system? How big is “BIG?” As we discussed
earlier, with older technology (pre-TDM), systems were limited to a certain size (as a
practical matter, in the “few” hundreds of ports) because of physical size and cost, not
because of technological or logistic limitations.
Today, intercom matrices in general, and RTS™ intercom matrices in particular, have a
higher absolute limit, and a larger “typical size”. For example, in the early 1980s, a well
appointed high end Sports Truck, the type which would do an NFL game, likely had 12 or
so channels of PL, 6 IFB channels and 6 ISO channels. Today, most “network size” trucks
carry 64+ ports of ADAM™ matrix, and in some cases, over 100 ports. The intercoms
have grown to carry program audio for monitoring, support 10, 15, or 20+ cameras, a host
of graphics operators, and statistics personnel. Clearly, what is typical today was
unimaginable less than 20 years ago.
Let’s consider matrix sizes for a moment, again sticking to those I know best:
• RTS™ Zeus™ Matrix Intercom System: 24 ports fixed.
• RTS™ ADAM™-CS Matrix Intercom System: 8 – 64 ports in groups of 8.
• RTS™ ADAM™ Matrix Intercom Single Frame: 8 – 136 ports in groups of 8.
• RTS™ ADAM™ Matrix Intercom Multiple Frames: 136 – 1,000 ports in groups of 8.