This document contains the following sections:
Trunk Supervisor is a 32-bit Windows application designed to run under Windows 2000/XP. It will also run under Windows NT 4.0 or later, as well as Windows 98 with Internet Explorer V4.0 or later (with V4.72 or later of the 32-bit common controls library). It should also run under Windows ME, but has not been tested in these configurations.
Trunk Supervisor V1.6.x and earlier use Microsoft Data Access Objects (DAO) V3.5 and V3.x of the Microsoft Jet engine to create and manipulate database files compatible with Microsoft Access 97.
Trunk Supervisor V1.7.x and later use Microsoft Data Access Objects (DAO) V3.6 and V4.x of the Microsoft Jet engine (by default) to create and manipulate database files compatible with Microsoft Access 2000 and later.
You do NOT need to have Microsoft Access installed in order to use the Trunk Supervisor but you do have to have V3.5/V3.6 or V4.x of the DAO/Jet engine installed. The Jet engine is installed by many applications (including Microsoft Office and/or Access), so it may already be installed on your computer. If the Jet engine is not already installed, you will need to install it from the re-distributable DAO package available from your Bosch representative.
The Trunk Supervisor V1.6.x and earlier database files can be opened and viewed with Microsoft Access 2000 (or later) but cannot be modified without converting the database files which will render them inaccessible to the Trunk Supervisor V1.6.x.
To open a Trunk Supervisor V1.6.x database file for the first time with Microsoft Access 2000 (or later), the file must NOT already be opened by Trunk Supervisor. You must exit Trunk Supervisor and open the database to allow Access to confirm that you do NOT want to convert the database file, and that you simply want to open and view the database. After the initial time, you may use Access 2000 (or later) to open the database file, even if it is already open in Trunk Supervisor.
Version 1.7.5
Support for Zeus-III / Zeus-III LE and Intracom VCOM intercom types
- Trunk Supervisor reports the new intercom types.
Version 1.7.4
Support for intercom to TM-2000 communications via Ethernet
- Trunk Supervisor reports the connection type and IP addresses for intercoms that support Ethernet communications with the TM-2000.
Support for detection of compatibility issues
Support for improved data security by detecting and reporting communication problems that may indicate a compatibility issue with an intercom. (Requires TM-2000 V8.8.1 or higher).
Version 1.7.3
Improved Communications with Trunk Master
- Occasionally, Trunk Supervisor would generate an alarm for losing contact with the Trunk Master that was resolved within one or two seconds. This has been corrected.
Automatically Compact Database at Startup
- If the database is larger than 10MB (a threshold defined by a registry setting), Trunk Supervisor prompts the user to compact the database at startup. The prompt requires a response from the user before continuing to run the application. In some cases, where the application is configured to start automatically when the PC restarts, there may not be a user available to respond to the prompt. Trunk Supervisor now automatically proceeds with compacting the database after 20 seconds (a timeout period defined by a registry setting) at startup if there is no user response before that.
Database Engine Compatibility Checking
- Trunk Supervisor V1.7.x versions use the Microsoft Jet Engine V4.x by default for creating new databases. If upgrading from Trunk Supervisor V1.6.x or earlier, the existing main database will be in Jet V3.x format, but new databases for request and alarm archives are created in Jet V4.x and are not compatible with the existing main database. One workaround was to delete any existing database, and let Trunk Supervisor rebuild it in Jet V4.x format.
- However, with this version, Trunk Supervisor checks to format of the main database, and uses that format to create the request and alarm archive databases, ensuring compatibility.
- Also, a new registry entry allows you to select which Jet Engine format to use when creating a new main database (and compatible archive databases). The default is still Jet V4.x.
Version 1.7.2
Enhanced Rapid Test RT-2M interface:
The interface to the RT-2M has been enhanced so as to minimize the likelihood of a premature test timeout when certain uncommon combinations of advanced test settings are specified via the registry.
Bug Fixes:
- Intercom names are now removed from the tree when the intercom is deleted from the Trunk Master using Trunk Edit.
Version 1.7.1
Support for Rapid Test RT-2M Audio Measurement System:
- Trunk Supervisor now supports either the Consultronics AutoTIMs or the NTI Rapid-Test RT-2M Audio Measurement devices for Trunk Testing.
- Select the testing device type from Configuration page of the View | Configuration dialog.
- Modify the device settings from the Test Parameters page of the View Configuration dialog (different settings are available for each device type).
Support for UPL Resources and IFB Special Lists:
- Trunk Supervisor now uploads and displays alphas for trunkable UPL Resources and IFB Special Lists
- To display alphas for UPL Resources only, select the Function Filter UR in the Alphas view.
- To display alphas for IFB Special Lists only, select the Function Filter IL in the Alphas view.
- Alternatively, you can select the correspondingly labeled node (UR or IL) underneath the Alphas node for a particular intercom in order to display the corresponding alphas for that intercom only.
Version 1.6.1
Bug Fixes:
- The database Alarms table field for Device Instance was too small (16-bits) to handle the large numbers (32-bits) used to identify request numbers on "busy" alarms.
- Blank matrix names and alphas are now shown as default/generic on the alarms view and in email and pager notifications for busy alarms.
- It was possible for some busy requests to become finished without generating a resolved/unresolved notification.
- The database Intercoms table field for Communication Status was too small to represent the status of all intercom types.
Version 1.6.0
Alarms and Notifications:
A new alarm type "Request Busy" is now generated whenever a trunk request cannot be immediately satisfied and must be queued. The alarm is linked to the request number in the request table, and is marked as Resolved when a trunk is allocated to the request. The alarm is marked as Unresolved if the requester abandons the request before a trunk is allocated (i.e. if the user releases the talk key). The new alarm type has all the same configuration options available as for any other alarm. The options for "Automatically acknowledge resolved alarms" and "Generated notifications when this type of alarm is resolved" are also applied to Unresolved alarms. The email notification for an Unresolved alarm includes a [UNRESOLVED] modifier, and the pager notification includes a "-??" modifier (instead of the "-OK" used for Resolved alarms).
The Alarm view now includes filter options to show or hide Request Busy alarms and/or Unresolved alarms. In addition, the previous filter option for Show Trunk Master and AutoTIMS alarms has been split into two separate filter options (one for Show Trunk Master alarms and one for Show AutoTIMS alarms). A second Info Bar has been added to the Alarm view to allow showing a count of Unresolved alarms. The Info Bars can be enabled/disabled via the View menu. Unresolved alarms are shown in Orange (with an orange background if not acknowledged, and orange text if acknowledged). Active alarms, Resolved Alarms, and Stale Alarms continue to be shown in Red, Green, and Yellow respectively. The colors for all alarms are adjustable via registry settings if necessary.
Previously, when starting the application, all Active alarms were marked as Stale. This precluded notifications from being sent when those alarms were later resolved. Now, only Unresolved alarms are marked as Stale at start up. This means that if the Trunk Master, AutoTIMS, or an Intercom were not communicating when the application was shut down, you will now get a Resolved notification if they later begin communicating and the application is re-started. It also means that Trunks that had previously failed trunk testing will generate a Resolved notification when testing later passes, even if the application had been shutdown in between. The application also "remembers" the communication status for each intercom when it is stopped and re-started, so that it can generate both Alarms and Resolved Notifications if an intercom stops or starts talking while the application is not running. In addition, the application now "forces" a Resolved Notification if a new intercom is detected.
If a trunk test passes after several failed attempts, each generating its own alarm, only one Resolved notification is sent (previously, one would be sent for each failed attempt still in the alarms database).
New registry settings for pager notifications include PagerFromAddress, PagerFromDisplayName, PagerReplyTo, and PagerXMailer. These settings mirror the existing settings for email notifications (which were also previously used for pager messages). The default value for each of the new pager settings is taken from the existing email settings. The existing registry settings called IncludeEmailFromInPagerMessages and IncludeEmailReplyToInPagerMessages have been renamed to IncludeFromAddressInPagerMessages and IncludeReplyToInPagerMessages (with the default values taken from the existing settings) to reflect that the email settings no longer apply to pager messages.
Bug Fixes:
- The Graphical Usage Display and Trunk Summary views could sometimes display incorrect trunk counts (including negative numbers) if a trunk that was in maintenance mode was redefined.
- Trunk requests could display an incorrect Alloc/Active state when one side of the request was Inactive but the other side was not.
- The layout of some controls on the Configuration dialog caused some text to be clipped.
Version 1.05.00
General:
Trunk Supervisor no longer requires a license file or USB dongle in order to communicate with a Trunk Master. Existing license files or dongles are read and validated, but their restrictions are not implemented. Trunk Supervisor will still display the license information for connected Trunk Masters if available.
Trunk Testing:
If a trunk used as a cascade trunk during testing fails, Trunk Supervisor now marks the cascade trunk in the FAILED state, and optionally leaves the cascade trunk in maintenance mode so that it is not used again as a cascade trunk for testing other trunks. The actually trunk under test is still marked in the ERROR state, is not removed from service, and will be tested again during the next automatic test session.
Also, error and failure messages have been improved to include more information (specifically the cascade trunk number used during the test).
Version 1.04.03
General:
Trunk Supervisor can now be licensed via a USB dongle (available from Bosch), allowing the program to be run on any computer that has a valid USB dongle connected to it. If a valid USB dongle is present, Trunk Supervisor does NOT need a license file in order to operate. The options for connecting to FR9589 Trunk Masters or unlicensed TM-2000's can be programmed into the dongle by Bosch when ordering your system.
Please see the Installation section for details on installing support for USB dongle licenses.
Version 1.04.02
General:
Trunk Supervisor can now be licensed to a particular TM-2000 system without being tied to running on any specific computer via a MAC addresses or CPU ID. This means that Trunk Supervisor can be licensed to run on any computer as long as the license file identifies at least one TM-2000 system by name. Using Trunk Supervisor with FR9589 Trunk Masters or with unlicensed TM-2000's still requires Trunk Supervisor to be licensed to a particular computer (or computers) by specifying a set of CPU IDs or MAC addresses in the license file.
Trunk Supervisor now recognizes the Cronus intercom when it is connected to a Trunk Master.
Communications:
A new registry setting allows adjusting the AutoTIMS communication timeout if necessary. See Customizing Trunk Supervisor for details.
Version 1.04.00
General:
Trunk Supervisor now requires a license file in order to communicate with TM-2000 and/or FR9589 based Trunk Masters. The license file (TKSUPV.LIC) must be acquired from Bosch Security Systems, Inc. and must reside in the same directory as the application executable (TKSUPV.EXE). The licensing information for Trunk Supervisor is displayed on the Help | About Trunk Supervisor dialog.
TM-2000 Trunk Masters at V8.3.0 and higher now also require licensing from Bosch. Trunk Supervisor queries and displays the licensing information for the TM-2000 Trunk Master on the View | Trunk Master Version dialog.
Trunk Supervisor now recognizes the ZEUS intercom when it is connected to a Trunk Master.
Bug Fixes:
- The suppress notification of alarms spin control only allowed up to 120 seconds, but you could manually edit up to 7200 seconds.
- Could conceivably display the Release Notes for the wrong product (or refuse to display any notes) if directory was changed.
- Setting AutoTIMs intercom and port to zero did not work.
Version 1.03.06
General:
The drag and drop positioning of objects on the graphical layout views was broken in V1.03.05. Dragged objects moved in an exaggerated manner and did not follow the mouse. This has been fixed in V1.03.06.
When exiting the application with the "Automatically save layouts when changing views" option enabled, the user could be prompted to save changes to a modified graphical layout instead of automatically saving the layout. If the user chose not to save the layout from the prompt, the layout would be saved anyway. This has been fixed in V1.03.06
Notes on AutoTIMS communications have been added to the end of this file.
Version 1.03.05
General:
More context sensitive help, and the inclusion of a help file.
A bug that could cause the application to crash when selecting a time for daily or weekly trunk testing has been fixed.
Alarms and Notifications:
Pager messages for resolved alarms now include the resolved time, rather than the alarm time.
Version 1.03.04
General:
Support for context sensitive help for all views, dialogs, menu items, and controls.
Error message and prompt when DAO is not installed.
Version 1.03.03
All Views:
Added support for 6 and 8 character intercom names and resource alphas (selectable from configuration dialog). This requires that the Trunk Master (and connected intercoms) also support 6 and 8 character alphas.
Trunk Summary and Trunk Definition Views:
If trunks were defined or undefined while Trunk Supervisor was not connected, Trunk Supervisor would incorrectly calculate the Trunk Summary display when reconnected and would continue to display trunk definitions for trunks that no longer existed.
Graphical Usage Displays:
Graphical intercom representations and context menus previously could accidentally include blank entries for nameless intercoms. Now nameless intercoms are either not shown, or are shown with default names as appropriate.
Communications:
Trunk Supervisor no longer allows the same COM port to be selected for the AutoTIMS and the Trunk Master.
Trunk Supervisor previously could GPF if you swapped the COM ports for the AutoTIMS and Trunk Master.
The AutoTIMS communication thread detects a request to exit the application more quickly.
The AutoTIMS communication thread did not have a large enough serial buffer.
Serial port initialization did not disable XON/XOFF flow control if it was previously enabled.
General:
When the application is started, the size of the database is checked and if it is larger than 10MB (threshold set in registry), then the user is prompted to compact the database to free space occupied by deleted records. In order to compact the database, it must be closed by ALL applications.
You may now click on the splash screen to dismiss it early.
The build date is now displayed on the Help About dialog.
Version 1.03.02
Trunk Testing:
Automatic (and queued) testing of trunks that involve an intercom that is not communicating (or can only be tested via a cascade trunk that involves and intercom that is not communicating) is skipped. These skipped trunks will be tested when the appropriate intercom regains communications.
Note that manually forcing one of these trunks to be tested will cause a warning prompt to be displayed, but that the test will be performed anyway. The test will likely fail because of an unmeasureable loss.
Notifications:
The "Suppress notifications if resolved with ___ minutes" alarm setup option has been changed to "Suppress notifications if resolved with ___ seconds" to allow for notifications on shorter breaks in communications.
Email notifications for resolved alarms now include [RESOLVED] in the email subject line.
Pager notifications for resolved alarms now include -OK in the subject line.
The date/time format for resolved and acknowledged times in email messages has been corrected to M/D/Y
Trunk Summary Display:
A bug which caused incorrect totals to be displayed after trunks had been undefined, and redefined, has been fixed.
Communications:
Previously, intercoms that had an "Unknown" status were shown as being bad (and generated email/pager notifications for communications failure). This has been corrected.
Version 1.03.00
Trunk Testing:
Trunk testing has been improved. Error messages from have been made clearer, and two bugs have been fixed: Some trunks were being skipped if they were in-use, even if the option to skip in-use trunks was disabled, and some trunks that failed were not left in maintenance mode even if that option was enabled.
Trunk Summary Displays:
By selecting the Trunk Master, or individual intercom nodes on the tree view you can display a summary of trunks from one intercom to all other intercoms, or a summary of all trunks in the system. The summary includes a total count, plus an indication of how many trunks are in-use, allocated, or in maintenance mode. This is similar to the Trunk Status display in CStrunk.
Graphical Usage Displays:
You can now create customized views showing individual intercoms and the trunks between them in a graphical layout mode. The lines connecting each pair of intercoms represent the trunks between them. The thickness of the lines indicates the number of trunks, and the colours of the lines indicate how many trunks are idle, allocated, or in-use (or in maintenance mode). You can create as many different views of the system as you like.
Alarms and Notifications:
A new Alarm screen allows you to be notified when something goes wrong. Alarms can be generated when communications are lost with the Trunk Master, with the AutoTIMS, or with any of the intercoms. Alarms can also be generated whenever a trunk test fails. Alarms can be enabled or disabled on an intercom by intercom, or trunk by trunk basis.
In addition, you can configure the alarms so that each alarm type can also generate an email and/or pager notification message sent via SMTP to your mail server.
Alarm descriptions for intercom communication failure now include the intercom name, and alarm descriptions for trunk test failures include the intercom names for each end of the trunk.
Notifications can now be generated when an alarm is resolved in addition to when an alarm becomes active.
An option to automatically acknowledge resolved alarms has been added. This allows resolved alarms to be archived without having to manually acknowledge these alarms.
An option had been added to allow active alarms to be archived if they have been acknowledged. This allows you to force an alarm to be archived even if it remains active.
User interface access has been provided to the options for aborting notifications for stale alarms, and for canceling notifications when an alarm is acknowledged which where previously only modifiable via the registry.
Trunk Conflict Display:
Another new display checks the trunk definitions for any errors (such as two trunks that share the same intercom/port at one end) and displays a list of conflicting trunks.
All Views:
The columns on all list views may now be re-ordered, simply by dragging the column to the desired position. The column order is stored in the registry for each view and is restored when a new view is created.
Column widths can now be set automatically by double-clicking the column divider to the right of the column to be resized. The column width will be the wider of the column header text, or the widest list entry for that column. By default the column width also includes room for the sort arrow. If you hold down the SHIFT key while double-clicking the column divider, the width will be calculated on the list data only (the header text will be ignored). If you hold down the CTRL key, the width will be calculated on the header text only (the list data will be ignored). If you hold down the ALT key, the column width will not automatically include space for the sort arrow.
When you sort a list by clicking on a column header, the sort order is now remembered when you leave and then return to that view.
Dates were previously shown as a time only, if the date was within 24 hours of the current time. Now, dates are shown as a date and time, unless the date is the current day, in which case only the time portion is shown.
Automatic re-sorting of the list displays on updates has been disabled, as this was visually distracting to the user. This feature may be re-enabled by changing a registry setting as described in the Customizing Trunk Supervisor section.
Selected list items are now remembered when the list data is updated or re-sorted. Previously, if list items were selected and the list data changed or was re-sorted, a potentially different set of list items became selected.
Communications:
Serial communications with the Trunk Master and the AutoTIMS have been made more robust, so there should be fewer communication errors (and alarms) generated for these devices.
There are also numerous user-interface improvements, including new filtering options, and many new configuration customization options.
To Install Trunk Supervisor, insert the installation floppy diskette into a floppy disk drive and execute the SETUP.EXE file on the diskette. Follow the on screen instructions. The default directory for installation is:
C:\TELEX\TKSUPV\V175
but you may change this if desired. The installation program creates the desired directory if necessary, and then creates another BIN directory beneath it. The TKSUPV.EXE application file, and the release notes (this file) are copied to the BIN directory.
The installation program also creates a shortcut to TKSUPV.EXE on the Programs sub-menu of the Start menu on the Taskbar. The shortcut is labelled:
Trunk Supervisor V1.7.5
The location of this shortcut, and its name, are not customizable during the installation process. You may move, rename, or delete this shortcut afterwards; however, if you move or rename it, it will NOT be deleted as part of the uninstall process.
At the end of the installation process, you are presented with a dialog that allows you to view this file. To view this file at a later time, you can choose the Release Notes menu item from the Help menu within the application.
To run Trunk Supervisor after installation, simply select the shortcut from the Start | Programs menu.
The first time Trunk Supervisor is executed, it will create several directories as siblings to the BIN directory. Assuming that the installation directory was the default as described above, the directories created will be:
C:\TELEX\TKSUPV\V175\LOGS
(stores diagnostic log information files)C:\TELEX\TKSUPV\V175\VIEWS
(stores graphical display layout files)C:\TELEX\TKSUPV\V175\DATABASE
(stores the trunk information database)C:\TELEX\TKSUPV\V175\DATABASE\ARCHIVES
(contains two sub-directories)C:\TELEX\TKSUPV\V175\DATABASE\ARCHIVES\REQUESTS
(stores request archives)C:\TELEX\TKSUPV\V175\DATABASE\ARCHIVES\ALARMS
(stores alarm archives)These directories, and the files created within them, are NOT removed during the uninstallation process.
Trunk Supervisor will also create a set of registry entries located at:
HKEY_CURRENT_USER\Software\Telex\tksupv
For the most part, you will not need to edit the settings stored here directly as almost all of them are modifiable through the View | Configuration dialog in the application.
While each new version of Trunk Supervisor is installed into its own directory so that the corresponding database files are unique to each version, ALL installed versions of Trunk Supervisor utilize the same set of registry settings.
These registry settings are also NOT removed during the uninstallation process.
To uninstall Trunk Supervisor, use the Add/Remove Programs applet from the Control Panel. Select the Trunk Supervisor application from the list of available applications and press the Remove button.
The uninstall process will delete the TKSUPV.EXE program file, the Release Notes file, the BIN directory, and the Start Menu shortcut. It will NOT delete the directories and files created when running the program for the first time, nor will it delete the registry entries used to customize the application.
To fully remove Trunk Supervisor, you must manually delete the installation directory (which defaults to C:\TELEX\TKSUPV\V175), and all of the files and directories beneath it. You may also decide to manually delete all of the registry settings under HKEY_CURRENT_USER\Software\Telex\tksupv, although these settings are also used by other installed versions of Trunk Supervisor.
Most of the configuration customization options are available via the Configuration dialog accessed via the View | Configuration menu item or by pressing ALT+ENTER. The configuration options in this dialog should be self-explanatory.
There are a number of other customization options that are currently only available by editing the registry directly. These options are located under the HKEY_CURRENT_USER\Software\Telex\tksupv key in the registry.
Here is a list of the advanced customization options (default values shown in brackets), followed by a description of the option.
Preferences\AutoUpdateSortOrder (0)
This option controls whether the sort order on list views is automatically updated when the list data is changed. When enabled, this can make the display visually distracting if the list data is changed frequently.
Allowable values for this setting are:
0 = The list is NOT automatically re-sorted when a data update occurs
1 = The list is automatically re-sorted when a data update occursPreferences\AlternateLineShading (2)
This option controls the shading of alternate lines in the list views.
Allowable values for this setting are:
0 = No line shading
1 = Shade every other line
2 = Shade every other pair of lines
4 = Shade every other set of 4 linesNote that the alternate line shading color offset is now a customizable registry setting. See Colours.
Preferences\AutoSynchronizeTreeView (1)
This option controls whether the navigation tree tries to remain synchronized to what is being displayed in the list view. For instance, if the user changes a filter setting, or navigates by using a context menu on the list view, the navigation tree will try to update itself and expand to show the current navigation node.
Allowable values for this setting are:
0 = Disable auto synchronization of the navigation tree
1 = Enable auto synchronization of the navigation treePreferences\CompactDBThreshold (0x00a00000)
This option sets the threshold (default of 10MB) for determining if the database should be compacted at startup.
Preferneces\CompactDBTimeout (20)
This option sets the timeout before automatically compacting the database at startup if no user input is received.
Preferneces\CompactDB (1)
This option sets whether the auto-response is to compact (1) or not compact (0).
Preferences\JetEngineVersion (4)
This option lets you force which Jet Engine is used to create the main database (and compatible archive databases).
Allowable values for this setting are:
3 = Use Jet V3.x.
4 = Use Jet V4.x.Preferences\ShowNamelessIntercoms (0)
This option controls whether undefined intercoms appear in the navigation tree, and in combo boxes showing lists of intercoms.
Allowable values for this setting are:
0 = Don't show undefined intercoms
1 = Show undefined intercomsSettings\Alarm Setup\EmailFromAddress (TKSUPV)
Settings\Alarm Setup\EmailFromDisplayName (Trunk Supervisor)
Settings\Alarm Setup\EmailReplyTo (<null>)These options are strings that can appear in the headers of email (and even pager messages, if desired). The control the appearance of who the notification emails are from, and which email address will receive replies if necessary.
By default, email message appear to come from Trunk Supervisor (with an email address of TKSUPV), and the ReplyTo field is empty.
Settings\Alarm Setup\PagerFromAddress (TKSUPV)
Settings\Alarm Setup\PagerFromDisplayName (Trunk Supervisor)
Settings\Alarm Setup\PagerReplyTo (<null>)These options are strings that can appear in the headers of email (and even pager messages, if desired). The control the appearance of who the notification emails are from, and which email address will receive replies if necessary.
By default, email message appear to come from Trunk Supervisor (with an email address of TKSUPV), and the ReplyTo field is empty.
Settings\Alarm Setup\IncludeFromAddressInPagerMessages (0)
Settings\Alarm Setup\IndludeReplyToInPagerMessages (0)These options control whether the From and ReplyTo address fields are included in pager messages.
In general, it is a good idea to omit this information from pager messages as there is typically not enough room on the pager display to include these fields and still display the actual alarm messages.
Allowable values for these settings are:
0 = Omit the field from pager messages
1 = Include the field in pager messagesThese settings have been renamed in V1.6.0. They used to be called IncludeEmailFromInPagerMessages, and IncludeEmailReplyToInPagerMessages. The default values for the new settings are imported from the old settings.
Settings\Alarm Setup\EmailSMTPLoginType (0)
Settings\Alarm Setup\EmailUsername (<null>)
Settings\Alarm Setup\EmailPassword (<null>)These options are for advanced SMTP use and may be necessary if your SMTP server requires authentication in order to send email. If this is the case, you will need to supply a Username and Password, as well as changing the EmailSMTPLoginType to one of the following values:
0 = Authenication not required, Username and Password are not necessary
1 = CRAM MD5 Authentication required
2 = Authentication Login required
3 = Plain Login requiredPlease see your email administrator if it is necessary to provide a login.
These values are used for both email and pager messages.
Settings\Alarm Setup\EmailSMTPPort (25)
This option sets the SMTP port to use. Most SMTP servers use Port 25 by default, so you should not likely need to change this setting.
This value is used for both email and pager messages.
Settings\Alarm Setup\EmailXMailer (Trunk Supervisor)
Settings\Alarm Setup\PagerXMailer (Trunk Supervisor)These options set email and pager fields indicating the mailing program name. They are an optional fields and should not need to be changed.
Settings\Preferences\Colors\...
There are a large number of color setting parameters under this key. All of the colors are stored as RGB values in hex where the value 0x00BBGGRR indicates the color components for Red (RR), Green (GG), and Blue (BB), and each two digit hex number can have a value of 0x00 to 0xff (0-255).
Black is 0x00000000, White is 0x00ffffff, pure Red is 0x000000ff, pure Green is 0x0000ff00, and pure Blue is 0x00ff0000. Most of the entries consist of some combination of RGB components.
Each of the parameters names should be self-explanatory, and you can edit these color entries directly if you feel it is necessary.
Settings\Configuration\AutoTIMSTimeout (10)
This value is the AutoTIMS communication timeout value in seconds. Versions prior to V1.04.01 had a hard coded value of 5 seconds. The default value is now 10 seconds, and can be adjusted here if necessary
Settings\Configuration\RT-2M\TurnaroundTime (1000)
This value is the RT-2M response timeout in milliseconds. The default value of 1000 milliseconds (1 second) was found to suffice in testing, but can be adjusted here if necessary. The minimum response timeout that can be specified is 100 milliseconds.
Settings\Test Parameters\RT-2M\OutputFloat (1)
This value specifies whether the RT-2M outputs are connected to ground. The default non-zero (1) value leaves the outputs floating so as to avoid ground loops when the RT-2M is connected to a (balanced pair) intercom port. Specify a value of zero (0) to have the RT-2M connect the outputs to ground.
Settings\Test Parameters\RT-2M\OutputLevel (1000)
This value specifies the level in mVp (milliVolts-peak) of the signal transmitted to test a trunk. The default of 1000 (1.0 Vp) should suffice, but can be adjusted here if necessary. Any value from 100 (0.1 Vp or -20 dBVp) to 3000 (3.0 Vp or approx. 9.5 dBVp) can be specified.
Settings\Test Parameters\RT-2M\InputDeemphasis (0)
This option specifies whether to apply deemphasis to the RT-2M inputs. The default (zero) value disables deemphasis; specify a non-zero value (e.g., 1) to have deemphasis applied.
Settings\Test Parameters\RT-2M\InputMICSensitivity (500)
This value specifies the MIC sensitivity to be configured for the RT-2M inputs in tenths of a mV/Pa. The default of 500 sets the input MIC sensitivity to 50.0 mV/Pa. This parameter is likely irrelevant for the loss testing performed by the Trunk Supervisor, but can be adjusted here if necessary. Any value from 500 (corresponding to a sensitivity of 50.0 mV/Pa) to 50000 (i.e., 5000.0 mV/Pa) can be specified.
Settings\Test Parameters\RT-2M\InputVoltageDividerRatio (10)
This value specifies the ratio, in tenths, of the voltage divider circuit connected to the RT-2M inputs. The default of 10 specifies a ratio of 1.0, meaning no voltage divider circuit is present. A voltage divider circuit enables levels greater than the maximum input range supported by the RT-2M to be measured. Since the maximum input range is 100.0 Vp (Volts-peak), the default should suffice, but can be adjusted here if necessary. Any value from 10 (corresponding to a ratio of 1.0) to 1000 (i.e., 100.0) can be specified.
Settings\Test Parameters\RT-2M\PretriggerLength (500)
This value specifies the duration in milliseconds of the pretrigger signal transmitted prior to the signal used to test the trunk. The default of 500 milliseconds is intended to give the trunk under test time to react to the presence of the test signal without unduly increasing the time it takes to perform a test. Any duration from 0 milliseconds to 5000 milliseconds (5 seconds) can be specified.
Settings\Test Parameters\RT-2M\MultitoneLength (250)
This value specifies the duration in milliseconds by which to extend the signal used to test the trunk. The default of 250 milliseconds is intended to give the trunk under test time to stabilize to the test signal without unduly increasing the time it takes to perform a test. Any duration from 0 milliseconds to 1000 milliseconds (1 seconds) can be specified.
Settings\Test Parameters\RT-2M\TrunkSetupDelay (500)
This value specifies the worst case delay in milliseconds to set up a trunk. The start of the test is delayed by this amount to give the intercoms involved additional time to establish a (loopback) connection to the trunk under test. The default of 500 milliseconds should suffice, but can be adjusted here if necessary. Any value from 0 to 1000 milliseconds (1 second) can be specified.
Settings\Test Parameters\RT-2M\TrunkLatency1 (2000)
Settings\Test Parameters\RT-2M\TrunkLatency2 (3500)
Settings\Test Parameters\RT-2M\TrunkLatency3 (5000)The nature of the multitone testing performed by the RT-2M requires that Trunk Supervisor take the latency of the trunk into account when setting up the test. These values specify the series of (possible) trunk latencies, in milliseconds, that the Trunk Supervisor should consider when test a trunk, in order from shortest possible latency to longest.
The Trunk Supervisor performs an initial test assuming that the trunk latency is no longer than the shortest trunk latency configured (i.e., TrunkLatency1). If the actual latency of the trunk is shorter than this, the test will succeed and the RT-2M will be able to measure the loss of the trunk. Otherwise, the test will fail, in which case the Trunk Supervisor will repeat the test, but assuming that the trunk latency is no longer than the next longer latency configured (TrunkLatency2). If this test fails as well, then the Trunk Supervisor repeats the test one last time using the longest latency configured (TrunkLatency3).
The defaults of 2000, 3500, and 5000 milliseconds (2.0, 3.5, and 5.0 seconds) form a series of latencies intended to minimize the total time it takes to test most trunks, while ensuring that a measurement is obtained for high latency trunks such as satellite uplinks. The initial (shortest) latency of 2.0 seconds should exceed the actual latency of most trunks in practice, meaning that only one test will need to be performed for most trunks. No (usable) trunk is likely to have a latency that exceeds the final (longest) latency of 5.0 seconds. These defaults can be adjusted here if necessary, subject to the following restrictions:
- Any latency from 50 milliseconds to 30000 milliseconds (0.05 seconds to 30.0 seconds) may be specified. Latencies shorter than 50 milliseconds (approx.) will be ignored; latencies longer than 30000 milliseconds (approx.) will be truncated to 30000 milliseconds.
- The latencies must be specified in (non-decreasing) order from shortest to longest. A configured latency shorter than the previous latencies (if any) will be ignored.
For example, if the following values were configured:
Then the Trunk Supervisor would ignore the latencies specified by TrunkLatency1 and TrunkLatency3.
- TrunkLatency1=0
- TrunkLatency2=5000 (5.0 seconds)
- TrunkLatency3=2500 (2.5 seconds)
Settings\Test Parameters\RT-2M\NoiseFloor (50)
This value specifies the maximum loss (attenuation) in dB permitted when the Trunk Supervisor attempts to determine whether or not the RT-2M received the signal used to test the trunk. The Trunk Supervisor compares this value to the input headroom measured by the RT-2M after a test completes. If the headroom exceeds this value, the Trunk Supervisor interprets this as meaning that the RT-2M did not receive the signal because the actual trunk latency is longer than that assumed when the test was set up (as described above). The default of 50 dB should suffice but can be adjusted here if necessary.
The AutoTIMS communicates with the PC via a standard serial RS-232 connection. The AutoTIMS will not communicate with a PC unless it sees that CTS is asserted. This is best done by shorting RTS to CTS (pins 7 and 8) at the AutoTIMS end of the cable.
The AutoTIMS protocol is an ASCII protocol. To verify communications with the AutoTIMS you can connect a PC to the AutoTIMS, and run a terminal emulator (9600 baud, 8 data, no parity, one stop bit); then power on the AutoTIMS. You should see it display various messages, followed by a ">" prompt. You should be able to send commands to it, including just a return - it should display another prompt.
The RT-2M communicates with the PC via a null modem serial RS-232 connection. The RT-2M protocol uses hardware flow control, which means that the RT-2M will not communicate with a PC unless it sees that CTS is asserted and vice versa. As a result, the RTS output from the PC must be connected to the CTS input to the RT-2M, and the RTS output from the RT-2M must be connected to the CTS input to the PC. Failure to do so will prevent the PC (and Trunk Supervisor in particular) from communicating with the RT-2M.
The RT-2M protocol is an ASCII protocol. To verify communications with the RT-2M, connect a PC to the RT-2M, and run a terminal emulator (38400 baud, 8 data, no parity, one stop bit, hardware flow control; send line ends with line feeds). Power on the RT-2M, and wait until it finishes its bootup initialization sequence. Initialization lasts about 10 seconds, during which the RT-2M turns on all of its front panel LEDs. Only the POWER LED will remain lit when the sequence completes. The RT-2M does not display a prompt, so to verify communications, enter the command SYSTEM:INFORMATION? (in upper- or lowercase). The RT-2M should provide a response similar to the following: NEUTRIK,RT2M,5944,7.10 The actual response depends on the device's serial number and firmware version. In this example, the serial number is 5944 and the firmware version 7.10. Please note that the RT-2M will not respond unless the command is entered correctly (although it will turn on the ERROR LED on the front panel). To have the RT-2M turn off the ERROR LED and report the error(s) that caused it to turn on the LED, enter the following command: SYSTEM:ERRORS?