Technical data

ASTi ACE Studio Components Reference Guide Rev. M DOC-01-TELAS-CRG-4
Copyright © 2014 Advanced Simulation Technology inc. 161
12.4. Intercom Bus Service
Summary: The Intercom service provides an invisible audio connection between
objects that declare they are attached to a common intercom ‘channel.’ All
connectivity between a specific operators comm panel and the source and source/
sink objects is carried out via intercom service links. The service supports multiple
simultaneous channels that operate in isolation from any others. Inputs to a
particular channel mix. Outputs from a channel are common to all destination
objects, with one exception related to the operation of sidetone. Sidetone is the
return signal from an object that has a transmit/receive capability, such as a radio.
See the ‘Description’ for a full definition of the sidetone characteristic. Both half
and full duplex connectivity between objects is supported depending on the source/
sink object type.
Note: As with all ‘Service’ type components the user does not manually instigate
the creation of the service object; this is done automatically on demand by the
loader when it detects that a component has an intercom service port connection.
Only one service component of the appropriate type will be loaded based on the
first found need for a service of this type.
Description: The Intercom service provides an “N” channelized audio mixer and
distribution service. The Intercom service will provide a centralized point for the
generation of sidetone signal return to source objects. The majority of voice
systems receive a portion of the source signal as a return that acts to assure the user
that the system is functional. It is important however that the sidetone is generated
cleanly since there are many potential issues related to multiple signal returns to an
operator - when an operator should hear sidetone, the receive signal should NOT
contain the same source so a return path must provide a “local loop” for the
sidetone and ensure that the source signal is subtracted from the “receive” signal.
This action must also accommodated any processing delays within the signal paths.
This service also includes some intelligence on allowing it to condition the return of
sidetone based on state data returned from a connected object, specifically when
used to link an operator to a radio or network intercom object. When configured
this way the radio object must provide a sidetone ‘state’ return, that will condition
whether any sidetone is to be returned to any operators that may be linked to the
channel.
The Intercom service will touch many other components throughout a model, and
hence it is important to define the nature of the service ‘edge’ primitive. These
primitives will provide the component interface to/from the intercom service. This
interface will pass the input audio to the service, and receive the return audio from
the service, and will pass additional data into the service, including (but not
necessarily limited to - developer to expand as required) channel index (set by the
model developer Channel Handle selection), sidetone gain, audio activity status,
and perhaps component type (used to determine how the sidetone gain is used -
either as a local loop gain or gate value [for radios/local or net intercom]). The
ONLY user defined input to this primitive will be the selected Channel Handle. No
other inputs or settings are to be required.
Available channels for use are declared through the “Intercom” tool. Within the tool
a “handle” (bus name) is defined and the tool assigns an internal index ‘number’ to
the channel. By default the tool assigns the channel numbers incrementally.
Internally the intercom service uses the channel number to link inputs and outputs.
The channel numbers are NOT to be accessible by the user, and need NOT
displayed. All displays related to the handles must be in alphabetic order to aid the
user locating required handles for assignment.
The Intercom tool will also support diagnostic facilities to allow the user to view
the use of intercom channel within the model. This will scan the model for all
objects using the service and extract the information into a table-like view. Two
views will be selectable for the intercom service and are demonstrated in the
following example:
Handle view – this will display all components that are connected to each handle:
UHF_Bus >
UHF_Radio > Main_Asset
OP1_Comm_Panel > Asset_Definition_1
OP2_Comm_Panel > Asset_Definition_1
VHF_Bus >
Main_Asset > UHF_Bus
OP1_Comm_Panel >
Asset_Definition_1 > UHF_Bus
Asset_Definition_2 > VHF_Bus
Asset_Definition_3 > (none)
Asset_Definition_4 > (none)
OP2_Comm_Panel
Asset_Definition_1 > UHF_Bus
Asset_Definition_2 > (none)
Asset_Definition_3 > (none)
Asset_Definition_4 > (none)