(Page 1 of 1 in this chapter) Version

Chapter 4

Verifying the Installation

4.1 Introduction
4.2 Using The LEDs To Check Power Connections
4.2.1 Checking the LEDs
4.3 Verification Procedure Using swish
4.4 Troubleshooting

4.1 Introduction

Once you have installed your hardware and software and have rebooted your system, verify that the system is operational before you continue. To do so, examine the boards's LEDs, and exercise your board's functions using the CT Access swish utility.

4.2 Using The LEDs To Check Power Connections

Once you have plugged the adapter cable into the board, connected the external power supply properly, and powered your system on, you can check that the power is properly connected by watching the LEDs located on the board's end bracket. The LEDs, and their positions and meanings, differ from board model to board model.

4.2.1 Checking the LEDs

The LEDs (shown in Figure 17) should behave as follows:

In addition to the LEDs on the end bracket, there is a set of red and green diagnostic LEDs on the face of the board (shown in Figure 18). They indicate the following:

4.3 Verification Procedure Using swish

To verify that a CX 1000 board is operational using swish:

  1. Determine the device number of the board you wish to test.

    • Under Windows NT, you assign your boards their device numbers during installation. For details, see Section 3.2. 

      

    • Under OS/2, the device number of a board is determined by the position 
in which the board's I/O address appears in the AGCX environment 
variable in config.sys. Devices are numbered from 0 upward. For 
example, if two boards are referenced in the variable as follows:

      

      
    set AGCX=m:0x0640,0x2140
      
...then the board at 0x0640 is device number 0, and the board at 0x2140 is device number 1. For details, see Section 3.3.
      

    • Under UNIX, the device number of a board is determined by the order 
in which you select its address during installation. For details, see 
Section 3.4, Section 3.5, or Section 3.6.

      

      

    • Start up the swish utility in interactive mode. To do so, enter the following at the operating system prompt: 
      

      
 swish
      
The swish utility starts up, and displays its prompt:
      
 swish:
      
The utility is ready for you to begin entering commands.
      

    • Direct the utility to open the switch and assign a handle to one of your boards. Enter one of these commands:
      

        

      • Windows NT: swi.OpenSwitch handle=agcxsw swno

        

        

      • UNIX: swi.OpenSwitch handle=agcx swno

        

        
... where:
      

        


      1. Enter the following command to reset the board to a known initial state (replacing x in the command with the handle of the board you are testing):
        

        
 ResetSwitch x
        
The swish: prompt reappears.
        

      2. Enter the following command to read the types of line interfaces installed on the board (replacing x in the command with the handle of the board you are testing):
        

        
 QueryHybridId x local:0:0..n
        
...where n is the number of line interfaces your board has, minus 1. For example, if you had a CX 1000-24 board with handle x, you would enter:
        
 QueryHybridId x local:0:0..23
        
...since this board type has 24 line interfaces.
        
The type of each line interface should appear on your display:
           Hybrid IDs:
           16:0: 0x1f   16:1: 0x1f   16:2: 0x1f   16:3: 0x1f
           16:4: 0x1f   16:5: 0x1f   16:6: 0x1f   16:7: 0x1f
           16:8: 0x1f   16:9: 0x1f   16:10: 0x1f   16:11: 0x1f
           16:12: 0x1f   16:13: 0x1f   16:14: 0x1f   16:15: 0x1f
           16:16: 0x1f   16:17: 0x1f   16:18: 0x1f   16:19: 0x1f
           16:20: 0x1f   16:21: 0x1f   16:22: 0x1f   16:23: 0x1f        


        
Note:  This display will differ from board model to board model.

0x1F indicates a local phone line interface with ringing capability.
        

      3. Repeat this test for each CX 1000 board you have installed in your system.
        

        
Note:  Make sure to assign each board a unique handle.


      4. When you have finished testing your boards, enter the following command to exit the utility:
        

        
 exit 
        
The operating system prompt reappears. 
      

      

      

      4.4	 Troubleshooting
      

      


      This section describes how to troubleshoot your CX 1000 installation. 

      


      
 Problem
      

      		
 Troubleshooting
      


      
 Board does not initialize or all commands to board fail
      

      		
 Look for a startup message to determine whether the driver found the board. If not:
      

·	 Check DIP switch settings. Is the correct address set?
      

·	 Look for address conflicts. The CX 1000 boards occupy 16 contiguous bytes of I/O space starting at the base address specified during installation. Does this range overlap with other boards in your system?
      

 If you have more than one CX 1000 board and one works but another does not, try swapping their addresses to determine whether there is an address conflict.
      


      
 Static or noisy voice channels
      

      		
·	 Check system's MVIP clock configuration. One and only board on MVIP bus must be bus master; all others should be slaved to the bus. Some boards, when configured as clock slaves, require that the board acting as bus clock master be booted first (i.e. require a stable clock on start up). CX 1000 boards may act either as clock master or as clock slave. The CX 1000 board clock mode is software configurable. Refer to Section 2.4.1 for more information. If necessary, simplify your system by disconnecting any boards from the MVIP bus that are not directly relevant to the experiment you are performing.
      

·	 Ensure that all boards are using the same encoding law. For CX 1000 boards, you can change the encoding law using the configuration program or script (see Chapter 3). For AG resource boards, the encoding law is configured via the AG configuration file.
      

·	 Check that the PC and external power supplies are properly grounded. See Section 2.5 and Section 2.6 for more information.
      


      
 Conferencing commands (or switch connections involving conference streams) fail
      

      		
·	 Ensure that your board supports conferencing.
      

·	 The board's EEPROM chip may be improperly programmed. Call NMS Developer Support.
      


      
 Local phone interfaces malfunctioning
      

      		
·	 Ensure that an adequate power supply is connected with the correct polarity. All local line interfaces require 24V DC talk battery to operate, and a ring voltage containing both -24 V DC and 93 VAC to generate sufficient ring signals. 
      

·	 Check the LED(s) on the bracket to ensure power is connected properly. If the LED is not lit, check the cables connecting power to the board. For more information about the LEDs, see Section 4.2.
      

·	 Ensure that the talk battery feed is enabled. Talk battery feed is controlled by the A-bit in the appropriate timeslot of the signaling stream. For more information about the talk battery feed, see Appendix B.
      

·	 Ensure that you are testing the correct board. To learn how board numbers are assigned to boards, see Chapter 3.
      

·	 Check the cable connecting the line interface to the local.
      

·	 Query the timeslot of the line under test for line interface ID. Make sure that the line interface you are addressing is a local line interface. For more information about querying the boards configuration, see Chapter 6.
      

·	 Check the signaling received from the local. When proper power is supplied and talk battery is enabled (by setting the A-bit in the transmit signaling), the receive A-bit should go high when the local is taken off-hook. For more information about line interface signaling, see Appendix B.
      

·	 Check for sidetone. If sidetone is present, the station is properly powered. If there is no sidetone, check your power supply, all connections, and transmit signalling.
      

·	 Try performing the same steps with the same telephone on a different line interface. If successful, the original line interface is probably defective.
      

·	 Try performing the same steps with a different telephone. If successful, the telephone is defective.
      

·	 Try ringing line 0 (and no other line). The LED located on the line interface on the board should turn on and off indicating ring. (See Section 4.2.1 for the location of this LED.)
      


      
 Everything is hooked up and powered properly, but my application still does not work
      

      		
·	 Check your switch connections on all your boards. Ensure that multiple boards are not driving the same MVIP timeslots.
      

·	 Draw a switch model diagram for your system. Include each switch on the bus. Ensure that the appropriate switch connections are made.
      


      
 Gain commands fail.
      

      		
·	 Requires the Siemens Musac chip. Check to see if this chip is present on the board, and call NMS Developer Support.
      



      


      

      

      

      

      

      


      
 
    (Page 1 of 1 in this chapter)  Version
      


      
 



      
tech_support@nmss.com

      

Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.