RTS TBX - TriBus ADAM - Manual (Page 8)

4
Features
Interface
with ADAM The TBX-Tribus card is backward compatible with all existing AES, AIO, and RVON cards in an ADAM
intercom system. The hardware and software is compatible to work seamlessly with the TDM a (Time
Division Multiplexing) and control bus circuitry for routing audio and controlling data. This card provides
a downloadable firmware feature through AZedit Intercom Software.
a. TDM is a technology that transmits multiple signals simultaneously over a single transmission path.
Channels
Per Link The TBX-Tribus has three (3) fiber links. Each link can support up to a maximum of 256 audio channels
per link. This channel capability is provided in AIO-16 systems. Moreover, the link can also be scaled
down to 128 channels, allowing it to support AIO-8 based intercom systems.
New System
Architecture The System Framework has been redefined for the TBX-Tribus allowing the system to reconfigure itself in
the event of a frame failure. In the scenario where the master frame fails, another ADAM frame within the
system seizes control until the fault is fixed. This fail-save mechanism monitors both audio and control,
and sends messages to report any corrupt behavior in the system.
NOTE: DBX cards are not compatible with TBX-Tribus cards.
Support for
Multiple
Distances The backcard features three (3) SFP (Small Form-Factor Pluggable) connectors that allow for support of
multiple distances. This allows the user to configure these cards based on their custom application. The
user can insert COTS (Commercial Off-The-Shelf) modules (Multi Mode/Single Mode) to match their
needs.
System
Expansion The TBX-Tribus employs the next generation ASIC (Application Specific Integrated Circuit) Nucleus for
higher performance and future system expansion. See Table 1 on page 5.
Autonomous
Mode Normally, a TBX-Tribus frame communicates with other frames that are part of the same intercom.
However, if an Ethernet link is not present, the Tribus automatically enters Autonomous mode.
AZedit also has a new option on the Intercom Configuration Options window (Options|Intercom
Configuration|Options Tab) called “Force Autonomous Mode when no audio links up.” The Force
Autonomous Mode check box is used to force the current frame into autonomous (independent) mode, if
none of its Tri-bus links are up. Normally, a frame communicates with other frames that are part of the
same intercom. If selected, the frame refuses to communicate with any other frames if none of its Tri-bus
links are up, even if Ethernet communications are fine. And, once one (1) or more of its audio links are
restored, the frame automatically tries to re-establish messaging links to the other frames in the cluster.
Automatic
Transfer of
Control Within each frame, both the active and the standby MCII-e master controllers maintain Ethernet messaging
links with every other frame in the cluster. If the Active controller in the frame loses its messaging links,
but the standby controller has one (1) or more Ethernet links available, an automatic transfer of control is
performed. When this transfer occurs, the standby controller becomes the active controller and the
previously active controller becomes the standby controller when its messaging links are restored.
Alarms and
Warnings A new view in AZedit displays various alarms and warnings that have occurred in the intercom. Once an
alarm has been resolved, it is deleted after five (5) minutes.
AZedit
Connections AZedit Connections (Options|Connect to Frame) allow the user to select the frame AZedit should connect
to.
AZedit version 3.6.1 or higher is required.
Unavailable
Tally
Indicator When a user turns a talk or listen key ON to connect with a resource in another frame within the cluster, the
key displays a busy tally, flashing between the Alpha and **, to indicate the resource is unavailable.
NOTE: For special lists and party lines, no unavailable tally is generated if there are any members of
the special list or party line in accessible frames
Logging Each frame in an intercom cluster generates its own log message and stores them locally. Normally, the log
messages are identical from frame to frame, except when frames are synchronizing. Using the logging
configuration window, you can select whether changes affect all frames in a cluster or just the locally
connected frame.