SELF-DIAGNOSTIC SYSTEM FOR CELLULAR-TRANSCEIVER SYSTEMS

Abstract: A self-diagnostic system for checking all functions of a cellular-transceiver system having a cellular-interface unit (10), which interface unit (10) couples a standard telephone set (T,R) to a cellular transceiver, which interface unit (10) converts the DTMF or pulse-type dialing signals into digital format for transmission to the cellular transceiver in which, the dialed number made on the landline telephone may be used to call a number over the cellular system. The present invention not only monitors and checks the proper functioning of the transceiver and associated power supply (figure 11), but will also monitor and check the interface unit (10).

Description: SELF-DIAGNOSTIC SYSTEM FOR CELLULAR-TRANSCEIVER SYSTEMS A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to facsimile reproduc¬ tion by anyone of the patent document or the patent disclo¬ sure, as it appears in the Patent & Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. BACKGROUND OF THE INVENTION The present invention is directed to a self-diagnosis system for checking all functions of a cellular-transceiver system. The present invention has especial relevance to a cellular-interface system, such as that disclosed in U.S. Patent Nos. 4,658,096 and 4,737,975, which are incorporated by reference herein. In the systems of these patents, an interface unit couples a standard telephone set, facsimile machine, modem, or other communications devices, to a cellu¬ lar, or cellular-like, transceiver, which interface unit allows for normal operation of the communications device through the radio transceiver. The interface unit may also convert DTMF or pulse-type of dialing signals into digital format for transmission to the radio transceiver, whereby the dialed number made may be used to call a number over the radio system by means of the transceiver. The system of the invention tests for the proper operation of all functions of the adapter interface unit, as well other characteristics, such as the power output of the radio transceiver, which can be varied by either signals from the transceiver or from the radio network, or the frequency at which the transceiver is utilizing, which can be changed selectively by either the transceiver or the cellular network. The diagnostic and testing system of the present invention may be used in any cellular-like system, such as a pure cellular system, or cellular-like systems, such ISDN and other personal communication systems, where a cellular- like adapter or interface unit is provided for converting the DTMF or pulse-type of dialing signals into digital format for transmission to the cellular-like transceiver associated with the cellular-like system. It is known to provide diagnostic and testing equipment for entire cellular systems. It is also known to provide a self-contained unit that tests itself. The latter is dis¬ closed in U.S. Patent Number 5,016,269 - Rogers, which is incorporated by reference herein, which discloses a cellu¬ lar-telephone, emergency call-box. This patent discloses self-diagnostics that are performed by the call-box itself. The call-box of this patent has self-diagnostics within it, and periodically reports the status of items checked to a central station through the cellular network. Rogers dis¬ closes a cellular handset and transceiver and associated auto-diagnostic system for checking on the system and for reporting back to a central station. However, this patent does not disclose the monitoring and self-diagnostic function of a DTMF converter, such as used in the above-mentioned U.S. Patent Nos. 4,658,096 and 4,737,975, nor does Rogers disclose the initiation of a ring-back tone from the central office to check on proper working of the system. The types of cellular-like systems, besides the pure- type of cellular systems, in which the present invention may be used, are those that relate generally to a wireless digital personal communications systems having a plurality of intelligent base stations and intelligent portable handset terminals, each having a predetermined radio cell coverage area, and more particularly to a digital, radio cell, radio¬ telephone, personal communications system (or PCS) having a full ISDN interface, thereby facilitating direct interconnection and switching of PCS call traffic through the ISDN interface and the public switched telephone network, or any switched network, the personal communications system having voice/data/image (or any combination thereof) and two- way full-duplex incoming and outgoing calling capability, and being fully operational and compatible with any modulation approach selected, with the intercell protocol hand-off being provided through distributed logic which is implemented in software that is resident in the intelligent portable handset terminals, the intelligent base stations, and the public switched telephone network (or any switched network) equipped with a PCS service control data base. The increasing availability of mobile and portable communications over the past decade is freeing business and residential users from the physical constraints of a totally wired telecommunications network. Particularly, cellular communications systems, together with paging and other complementary services, brought true mobility to telecom¬ munications services for the first time. Significant tech¬ nical advances in mobile and portable technologies, as well as in new technologies such as digital transmission with respect to wireless telecommunications, have substantially expanded the number and types of wireless telecommunications services using the radio spectrum that can be made available to the user. These prospective services include, but are not limited to, advanced forms of cellular telephone service, advanced digital cordless telephone service, portable facsimile services, wireless centrex, wireless private branch exchange services, and wireless local area network services, and may be used through the existing public switched network or through alternative local wired networks (such as cable television systems) . As such, digital personal communications systems can exist independently of, and in conjunction with, local wired networks, filling gaps that are existing in current communications systems, and also in creating new markets, many of which are yet to be defined. The advent of PCS will have a great impact on the future development and configuration of all telecommunications networks by significantly improving their flexibility and functionality. Accordingly, providers of PCS will have the ability to reach and serve existing and new markets nation¬ ally in an economic and responsive manner. Personal communications requirements in the United States are rapidly changing as the demand for instantaneous communications increases due to increased mobility of the user. One of the advantages of PCS is that it will use a single communications device to reach anyone, anytime, anywhere. PCS will facilitate increased mobility and flex¬ ibility of the user, since this approach solves the underly¬ ing problem of being in constant communications with user. PCS wireless will enable users not to miss important calls, as well as reduce the time and expense in returning calls. PCS combines the functionality of radio and the Public Switched Telephone Network (PSTN) technologies and in¬ frastructure, and will accommodate full-duplex capabilities (two-way incoming and outgoing calling) and hand-off between radio cells (allowing users to freely move from one radio cell to another without interrupting the user's call). It is important to remember that there has been a steady increas¬ ing demand for new PCS services and technologies for nu- merous, sometimes incompatible, applications', namely, wire¬ less private branch exchanges, smaller lighter portable cellular phones, portable fax machines, multi-channel cord¬ less telephones, and additional services which are targeting the facilitation of contacting a particular individual user (rather than contacting a particular station) . Current radio equipment and related services presently offered (i.e., cordless telephones, radio paging, and cellular radio) cannot fully meet the demands for these new types of PCS services. For example, cordless telephones are used in and around the home or office, operate on only a very few channels (10 or so) that are congested, and are limited to use in the immediate vicinity of their associated base station. Radio paging services are only one-way and have limited capabilities. Cellular and specialized mobile radio services cannot meet the full range of expected demand for PCS. Over time, PCS will have standardized equipment with common modules in hardware resulting in improved reliability in the associated equipment which will also be less vulnerable to transient interference from external sources, have automatic call registration, automatic call forwarding, voice mail, faxing capability, easy roaming features, remote data transfer, increased privacy protection/caller ID/class services, increased battery life, and common protocols. In order to best fulfill this marketplace mandate, a digital PCS is a necessity. Wireless PCS may eventually eliminate the need to have a building hard-wired for communications. Generally speaking, PCS will facilitate communications equipment with additional features. A digital PCS will facilitate improvements in technical communications equip¬ ment, systems and design. The present invention, therefore, may be used in those ISDN or other PCS systems where there is provided a cellular- type adapter or interface board that allows for the use of a standard, land-type telephone instrument in this system, or other communications device, by converting the DTMF or pulse signals thereof into digital format that may be sent to a PCS transceiver unit, or by providing other functions that may be specific to the system. For example, in dedicated alarm systems where only outgoing calls are made by the radio transceiver, the interface unit need not provide ring generation, busy signal generation, and the like. Alternatively, in those systems where only incoming calls are required, the interface unit need not convert dialed DTMF or pulse signals into digital format. Such a PCS-cellular adapter also provides all of the other functions required, such as the generation of dial tone, ringing, and the like, as the cellular interface board set forth in U.S. Patent Nos. 4,658,096 and 4,737,975. SUMMARY OF THE INVENTION It is, therefore, the primary objective of the present invention to provide a self-diagnostic system for a checking all functions of a cellular-transceiver system having a cellular-interface unit, which interface unit couples a standard, land-like telephone set, or other communications device, to a cellular transceiver, or to a cellular-like, such as a PCS or ISDN transceiver, which interface unit converts the DTMF or pulse-type of dialing signals into digital format for transmission to the cellular, or cellular- like, transceiver, whereby the dialed number made on the land-type of telephone instrument, or its equivalent, may be used to call a number over the cellular, or cellular-like, system. The present invention not only monitors and checks the proper functioning of the cellular, or cellular-like, transceiver and associated power supply, and the like, but will also monitor and check the cellular, or cellular-like, interface unit. The testing apparatus of the invention is capable of being coupled to an interface unit which couples a communi- cations device to a radio transceiver for either calling out or receiving calls through the radio transceiver, the testing apparatus having its own diagnostics for monitoring and reporting the proper functioning of the interface unit. The testing apparatus alternately couples the diagnos¬ tics to the interface unit, which said diagnostics simulates the functions performed by a communications device, such as a land line telephone, facsimile machine, modem, and the like, for generating in the interface unit respective, corresponding responses in the interface unit, in order to determine if the interface unit is operating correctly. The testing apparatus will also generate an off-hook signal to the interface unit, as well as detect the presence of a dial-tone signal generated from the interface unit in response to the of the off-hook signal. The testing apparatus will also generate a DTMF signal and send the signal to the interface unit, as well as de¬ tecting the DTMF signal output by the interface unit in response to the DTMF signal generated. The testing apparatus also generates an on-hook signal to the interface unit, as well as an off-hook signal to the interface unit during the time that the interface unit is generating its ring-signal, in order to determine that the interface unit properly disconnects the ring-signal upon the answering of an incoming telephone call. The testing appara¬ tus also generates an outgoing telephone call through the telephone network, when said the interface unit is coupled to a transceiver, and back to the transceiver, whereby the diagnostics causes the transceiver to make a telephone call to itself, with the diagnostics detecting the generation of a busy-signal by the transceiver in response to the telephone call. BRIEF DESCRIPTION OF THE DRAWINGS The invention will be more readily understood with reference to the accompanying drawing, wherein: Figs. 1A and IB show a general flow chart for the steps involved for the self-testing according to the inven¬ tion; Fig. 2 is a flow chart showing the steps involved for the subroutine of the self-testing of off-hook according to the invention; Figs. 3 is a flow chart showing the steps involved for the subroutine of the self-testing of dial tone genera¬ tion according to the invention; Fig. 4 is a flow chart showing the steps involved for the subroutine of the self-testing of DTMF tone genera¬ tion according to the invention; Figs. 5A through 5C show a flow chart for the steps involved for the subroutine of the self-testing of ring generation according to the invention; Fig. 6 is a flow chart showing the steps involved for the subroutine of the self-testing of ring-answer process according to the invention; Figs. 7A and 7B show a flow chart showing the steps involved for the subroutine of the call-test which checks for proper call-detection and answering of an incoming call according to the invention; Figs. 8A and 8B show the error-code generation subroutine according to the invention; Fig. 9 is a flow chart showing the reset subroutine according to the invention; Fig. 10 is a block diagram of the system of the invention; Figs. 11 - 15 are schematics showing the various circuits used for testing the cellular, or cellular-like, interface and transceiver by simulating the events to be tested. DETAILED DESCRIPTION OF THE INVENTION The auto-diagnostic maintenance system of the present invention is for use in cellular, or cellular-like, inter¬ face boards and systems, such as those disclosed in U.S. Patent Nos. 4,658,096 and 4,737,975. In addition, the auto- diagnostic maintenance system of the present invention may be used with other radio-transceiver systems, such as IMTS, where there is provided a wireless link between a base station and master stations, and which transceiver is asso¬ ciated with an adapter interface board, such as that dis¬ closed in U.S. Patent Nos. 4,658,096 and 4,737,975, for example, which allows for connection and normal functioning of a communications-type instrument, such as a land-line telephone, facsimile machine, modem, and the like, to the radio transceiver. The interface unit provides a number of functions depending upon its intended use. For example, in dedicated alarm systems, where only outgoing calls are made by the radio transceiver, the interface unit need not provide ring generation, busy signal generation, and the like, to the communications device. Alternatively, in those systems where only incoming calls are required, the interface unit need not convert dialed DTMF or pulse signals into digital format. According to the invention, software is provided which communicates with the microprocessor of the cellular interface board or other radio-transceiver interface board, disclosed in U.S. Patent Nos. 4,658,096 and 4,737,975, which software may be activated either manually or automatically for activating an auto-diagnostic interface board of the invention, which software diagnoses the proper functioning of all the software and hardware systems contained within the entire system of these above-mentioned patents. Every single item can be checked. For example, on the interface board, the DTMF converter will be checked, the four-line interface to two-wire connection will be checked, the busy-tone software will be checked, as well as all other functioning aspects of the interface. In addition, the transceiver will be checked, the battery will be checked, as well as any other aspects of the interface. The maintenance system of the invention is capable of making a call over the cellular, or cellular-like, network to a predetermined telephone number of a central station, or base station, which central station will then send back either a tone-back or will dial the current number of the interface system to get a busy signal. ' This will be considered a test. The invention will also send another telephone number over the cellular, or cellular-like, system to call the same or a different central station, so that it may send back a 1000 hertz precision tone, whereby the software of the present invention will compare that 1000 hertz tone to its own predetermined configuration in order to determine whether there is a line-connection and that the cellular, or cellular-like, system is operating correctly. This is a particularly useful system, since it allows the end-user to activate the phone in the event the user believes there is a problem with a phone. This test will then tell the telephone company whether or not the error is at the cellular system's central office or it is a problem with the base unit of the end-user. According to the invention, there are two different modules. The first one is the telemaintenance circuit and the second is the teletariff circuit. The telemaintenance circuit generates a multiple test, as set forth below in detail, that includes a generation of a telephone call to a predetermined number. The circuit will report the results of the test to this particular number. In addition, the circuit can dial out to its own number in order to assure that the reception and transmission of the unit is working by receiving a busy signal. These sets of tests can be initiated by the subscriber by pressing a push button that is located on the side of the unit. When the button is pressed, the LED located near the button will continue flashing identifying the test is in progress. If at the end of the test the LED continues to stay on, that indicates there is a problem with the unit. This test generally takes no more than 40 seconds maximum. On the other hand, if the LED stops blinking and turns off, it indicates that the test was successful, and that the unit is in proper working order for the items that were checked on the test. As an option, the software and hardware provide that the test can be conducted from an outside number, provided that the transmission media allows it, (i.e., that the transceiver is in working order to receive a phone number) . The second circuit consists of the following: It utilizes the tariffing signal from the cellular, or cellular- like, system and generates the corresponding tariffing pulses for a standard table phone or pay phone. The device interprets the signal coming in from the cellular, or cellu¬ lar-like, system, and does not need any local tariff. It operates in a similar manner for generating the long tones. It can be used with any cellular, or cellular-like, system that is capable of sending the tariff signals. Telemaintenance Modules Flow Chart Description The user may invoke the operational test sequence by pressing the autodiagnostic push button. When invoked, the interface board control is transferred to the autodiagnostic main subroutine of the telemaintenance module for performing the auto-testing. FIGS. 1A and IB show the DO_TEST subroutine, or the autodiagnostic main subroutine. A number of calls to various test procedures are performed. After each procedure, the error flags are checked. In the event of any failure, the test sequence is stopped. Then, the status is coded, and the result is shown to the user through four LEDs, as described below. Referring to FIG. 1A, In STEP 1, the operational test sequence starts with the initialization of variables and flags. In STEP 2, the program calls up the Hook_Test sub¬ routine. In Hook_Test, the user's telephone is disconnected from the TIP & RING lines, while the Telemaintenance Module (described below in detail) is connected in its place, to the interface board, such as that disclosed in U.S. Patent Nos. 4,658,096 and 4,737,975, in preparation for the test. STEP 3 checks for any error detected in Hook_Test. If any error was found, the test sequence stops, and the program proceeds to STEP 14 in FIG. IB. However, if no error was detected, the program calls up the Dial_Tone Test subroutine in STEP 4. STEP 5 checks for any dial tone error. If any error was found, the test sequence stops, and the program proceeds to STEP 14 in FIG. IB. However, if no error was detected, the program calls up the next test, the DTMF_Test subroutine in STEP 6. The program continues in FIG. IB STEP 7, where any DTMF_Tone subroutine is checked. If any error was found, the test sequence stops and the program proceeds to STEP 14. However, if no error was detected, the program calls up the next test, the Ring_Test subroutine in STEP 8. STEP 9 checks for any ring error. If any error was found, the test sequence stops and the program proceeds to STEP 14. However, if no error was detected, the program calls up the next test, the Ring_Answer_Test subroutine in STEP 10. STEP 11 checks for any ring-answer error. If any error was found, the test sequence stops, and the program proceeds to STEP 14. However, if no error was detected, the program calls up the next test, the Make_Call_Test subroutine in STEP 12. STEP 13 checks for any calling-out error. If any error was found, the test sequence stops, and the program proceeds to STEP 14. However, if no error was detected, the program calls up the next test, the Fin_Self_Test subroutine in STEP 15. If any error was found during the execution of any subroutine, the program jumps to STEP 14. In STEP 14, the program calls up the Error_Acc subroutine. Finally, the test sequence ends after STEP 15 has cleared all variables and flags, returning the control back to the telephone set, and resuming normal operations of the Interface. The following explanations of FIG. 2 to FIG. 9 corre¬ spond, and describe in detail, the individual test-subrou¬ tines above-mentioned. Referring to FIG. 2, the Hook Test subroutine (Step 2 of FIG. 1A) starts with the initialization of variables and flags in STEP 16. In STEP 17, the program clears any output of the LEDs. In STEP 18, the user's telephone is discon¬ nected from the TIP & RING lines of the interface board, while in STEP 19, the telemaintenance module of the invention is connected in place of the telephone. STEP 20 is a time delay to allow enough reaction time for such connection. In STEP 21, the telemaintenance module of the invention simulates and generates an off-hook. STEP 22 is a time delay to allow enough time for the off-hook. In STEP 23, the program checks the hook status of the interface board, which has now been coupled to the telemaintenance module. STEP 24 test for off-hook. If off-hook is not detected, the program continues to STEP 25, where the ERROR_FLAG is set and the MAIN_FLAG_ERROR is set to 1. However, if no error was detected, the program continues to STEP 26, where the dial tone is enabled for the next test shown in FIG. 3. Finally, this subroutine ends, and the program returns to the main subroutine Do_Test of FIGS. 1A and IB. Referring to FIG. 3, the Dial_Test subroutine starts with the initialization of variables and flags in STEP 27. STEP 28 is a time delay to allow enough time for a proper dial tone. STEP 29 tests the dial tone. If the dial tone fails, the program continues to STEP 30, where the ERROR_FLAG is set and the MAIN_FLAG_ERROR is set to 3. However, if no error was detected, the program continues to STEP 31, where the program loops back to STEP 29, testing the dial tone for at least 711 milliseconds. After no errors have been detected after the 711 milliseconds has expired, this subroutine ends, and the program returns to the main subroutine Do_Test of FIGS. 1A and IB. Referring the FIG. 4, the DTMF_Test subroutine, which tests for the proper DTMF conversion into digital data by the interface board, starts in STEP 32 by disabling the dial tone from the previous subroutine test. STEP 33 sets the first DTMF tone to 0. In STEP 34, the telemaintenance module sends the DTMF tone corresponding to this value. STEP 35 is a time delay to allow enough time for the tone to be on. STEP 36 disables the DTMF tone. STEP 37 is a time delay to allow the interface to detect the DTMF tone pulse. In STEP 38, the interface reads the tone. STEP 39 checks the received DTMF tone. If the DTMF tone sent is not equal to DTMF tone received, or no DTMF tone is received, then the program continues to STEP 40, where the ERROR_FLAG is set, and the MAIN_FLAG_ERROR is set to 4. However, if the DTMF tones are equal, the program continues to STEP 41, and the next DTMF digit is selected. In STEP 42, the program verifies that all DTMF tones have been tested; otherwise the program loops back to test the next digit. Finally, after all the DTMF tones have been tested, the subroutine ends, and the program returns to the main subroutine called Do_Test of FIGS. 1A AND IB. Referring to FIGS. 5A & 5B, the Ring_Test subroutine is shown. This subroutine tests the timing of the two pulses of the ring generated by the ring circuitry of the interface board. Referring to FIG. 5A, the subroutine starts with the initialization of variables and flags in STEP 43. In STEP 44, the telemaintenance module generates an on-hook. Step 45 is a time delay to allow the interface to detect the on-hook. In STEP 46, the interface is set to believe that an incoming call is in progress; therefore, the interface board will generate its ring sequence. The objective of STEPS 47 to 53 is to verify that the ring starts within the next two seconds, and that off-hook is not detected. In STEP 47, the timer is cleared. STEP 48 tests for off-hook. If off-hook is detected, then the test is stopped, and the program jumps to STEP 49 in FIG. 5C for error-indication. However, when on-hook is detected, the program continues to STEP 51, where the telemaintenance module checks for the ring to be active. STEP 52 tests if the ring has started. If the ring has started, the program continues to STEP 54 in FIG 5B. However, if the ring had not yet started, the program checks the timer in STEP 53. If the time is less than two seconds, the program keeps looping back to STEP 48 until the ring starts. However, if the two second timer had expired, the test stops and the program jumps to STEP 49 in FIG. 5C for indicating error. Referring to FIG. 5B, STEP 54 is a time delay. The objective of STEP 55 to STEP 59 is to verify that the ring will last for at least one 1.3 seconds, and that off-hook is not detected. In STEP 55, the timer is cleared. STEP 56 tests for on-hook. If off-hook is detected, the test stops, and the program jumps to STEP 49 in FIG 5C for indicating error. However, when on-hook is detected, the program goes to STEP 57, where the telemaintenance module checks for the Ring to be active. STEP 58 tests if the ring has stopped. If the ring has stopped, the program continues to STEP 49 in FIG. 5B. However, if the ring has not yet stopped, the program checks the timer in STEP 59. If the timer is less than 1.3 seconds, the program keeps looping back to STEP 56 until the ring stops. However, if the time has expired, the test stops, and the program jumps to STEP 49 in FIG. 5C. The objective of STEP 60 to STEP 62 is to verify that the ring will not last more than 2.5 seconds. In STEP 60, the telemaintenance module checks if the ring is active. STEP 61 tests if the ring has stopped. If stopped, the program jumps to STEP 63 in FIG. 5C. However, if the ring has not yet stopped, the program checks the timer in STEP 62. If the timer is less than 2.5 seconds then, the program keeps looping back to STEP 60 until the ring stops. However, if the time has expired, the test stops and the program jumps to STEP 49 in FIG. 5C. Referring to FIG. 5C, the objective of STEP 63 to STEP 65 is to verify that no off-hook is detected for a period of two seconds. In STEP 63, the timer is cleared. STEP 64 tests for on-hook. If off-hook is detected, then the test stops and the program continues in STEP 49 for indicating error. However, if off-hook is not detected, the program checks the timer in STEP 65. If the timer is less than two seconds, the program keeps looping back to STEP 64 until the ring starts. However, if the time has expired, then the program continues in STEP 66, where the program checks how many cycles this subroutine has tested the ring. If the ring has been tested for only one cycle, the program continues in STEP 67, where the flag called Ring_Second is set. Thereafter, the program loops back up to STEP 47 in order to test the ring for a second time. However, if the ring has been tested twice, the subroutine ends and the program returns to the main subroutine called Do_Test. If an error was detected.during any part of the Ring_Test subroutine, the program jumps to STEP 49. STEP 49 clears the incoming call status; ' therefore, the ring sequence stops. Then, the program continues in STEP 50, where the ERROR_FLAG is set and the MAIN_FLAG_ERROR is set to 5. Then, the subroutine ends, and the program returns to the main subroutine called Do_Test. Referring to FIG. 6, the Ring_Answer_Teεt subroutine is shown. This subroutine tests the response of the interface board when an off-hook is presented to the interface board during the ring-cycle, when answering the telephone for an incoming call. The objective of STEP 68 to STEP 69 is to verify that the ring will start within the next two seconds and that off-hook is not detected. In STEP 68, the timer is cleared. STEP 69 tests for on-hook. If off-hook is detect¬ ed, then the test stops and the program jumps to STEP 73. However, if on-hook is detected, the program continues with the ring active. STEP 71 tests if the ring has started. If the ring has started, the program continues to STEP 74. However, if the ring has not yet started, the program checks the timer in STEP 72. If the timer is less than two seconds, then the program loops back to STEP 69 waiting for the ring to start. However, if the two-second timer has expired, the test stops and the program jumps to STEP 73. In S 73. In STEP 74, the telemaintenance module generates an off-hook. STEP 75 is a time delay that allows the interTEP 74, the telemaintenance module generates an off-hook. STEP 75 is a time delay that allows the interface board to detect the off- hook. In STEP 76, the interface checks the hook-status. If off-hook is not detected in STEP 77, then the test stops and the program jumps to STEP 73. However, if the interface board detects the off-hook, the program continues in STEP 78. If an error was detected during any part of the Ring_Answer_Test subroutine, then the program jumps to STEP 73, where the ERROR_FLAG is set and the MAIN_FLAG_ERROR is set to 6. Then, the program continues in STEP 78. In STEP 78, the incoming call status is cleared; therefore, the interface board will stop the ring sequence. Then, the subroutine ends, and the program returns to the main subroutine called Do_Test. Referring to FIGS. 7A & 7B, the Call_Test subroutine is shown. This subroutine tests the cellular, or cellular-like, transceiver coupled to the interface board, by first check¬ ing the power, and, secondly, generating a call to its own telephone number. Referring to FIG. 7A, STEP 79 checks if the transceiver's power is "on". If the power is "off", the MAIN1_FLAG_ERR0R is set to 1 in STEP 81, and then the program jumps to STEP 93 in FIG. 7B. However, if the power is "on", the program proceeds to STEP' 82, where the interface board requests and gets the transceiver's assigned telephone number. STEP 83 is a time delay to allow reaction time for the transceiver. In STEP 84, the interface board generates a telephone call to itself. STEP 85 is a time delay to allow time for connection between the cellular, or cellular-like, network and the transceiver. In STEP 86, the interface board requests the IN USE status from the transceiver. STEP 87 checks the status of the call. If the status is not IN USE, the MAIN1_FLAG_ERR0R is set to 4 in STEP 88, and then the program' jumps to STEP 93 in FIG. 7B. However, if the transceiver is IN USE, the program proceeds to STEP 89 in FIG 7B. In FIG. 7B, the telemaintenance module checks the busy- tone in STEP 89. If the busy-tone is detected in STEP 90, then the program jumps to STEP 93 for an indication that all is operating correctly. However, if the busy-tone is not detected, the program proceeds to STEP 91, where the timer is checked. If the timer is less than 18.2 seconds, then the program loops back to STEP 86. This allows more time to the cellular, or cellular-like, network to return the busy- response. However, if the time has expired, the program proceeds to STEP 92, where the MAIN1_FLAG_ERR0R is set to 3. In STEP 93, the interface board sends an END of call to the transceiver. Then, the telemaintenance module presents an on-hook to the interface board in STEP 94. Finally, the subroutine ends and the program returns to the main subroutine Do_Test. The objective of FIG. 8A and FIG. 8B is to generate a an ERR0R_C0DE from the previously-described error flags, in such a way that the results can be output later through LEDs. Referring to FIG. 8A, the subroutine starts checking the value of one of two error flags, the MAIN_FLAG_ERROR. STEP 95 checks if MAIN_FLAG_ERROR is equal 1 or Hook Slic Error. If true, the ERROR_CODE is set to 1 in STEP 96, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 97. STEP 97 checks if MAIN_FLAG_ERROR is equal 2 or hook-ring error. If true, the ERROR_CODE is set to 2 in STEP 98, and then the program returns * to the main subroutine Do_Test. However, if false, the program continues in STEP 99. STEP 99 checks if MAIN_FLAG_ERROR is equal 3 or dial-tone error. If true, the ERROR_CODE is set to 3 in STEP 100, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 101. STEP 101 checks if MAIN_FLAG__ERROR is equal 4 or DTMF tone error. If true, the ERROR_CODE is set to 4 in Step 102, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 103. STEP 103 checks if MAIN_FLAG_ERROR is equal 5 or ring-detection error. If true, the ERROR_CODE is set to 5 in STEP 104, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 105. STEP 105 checks if MAIN_FLAG_ERROR is equal 6 or ring-answer error. If true, the ERROR_CODE is set to 6 in STEP 106, and then the program returns to the main subroutine Do_Test. However, if false, the program jumps to STEP 107 in FIG. 8B. In FIG 8.B, the subroutine starts checking the value of the second error flag, the MAIN1_FLAG_ERR0R. STEP 107 checks if MAIN1_FLAG_ERR0R is equal 1 or power-radio error. If true, the ERROR_CODE is set to 7 in STEP 108, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 109. STEP 109 checks if MAIN1_FLAG_ERR0R is equal 2 or call error. If true, the ERR0R_C0DE is set to 8 in STEP 110, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 111. STEP 111 checks if MAIN1_FLAG_ERR0R is equal 3 or busy-tone error. If true, the ERR0R_C0DE is set to 9 in STEP 112, and then the program returns to the main subroutine Do_Test. However, if false, the program continues in STEP 113. STEP 113 checks if MAIN1_FLAG_ERR0R is equal 4 or "In Use" error. If true, the ERR0R_C0DE is set to 10 in Step 114, and then the program returns to the main subroutine Do-Test. However, if false, the program continues in STEP 115. STEP 115 checks if MAIN1_FLAG_ERR0R is equal 5 or 1000 Hz. error. If true, the ERROR_CODE is set to 11 to STEP 116 Do_Test. However, if false, the program returns to the main subroutine Do_Test. Referring FIG. 9, FIN_SELF subroutine, the objective of this subroutine is to reset the interface board to its normal functioning, and to show the end of the test by flashing the LEDs four times. The subroutine starts with STEP 117, where the telemaintenance module generates an on-hook. In STEP 118, all variables and error flags are cleared. STEP 119 turns off all LEDs. STEP 120 is a time delay. STEP 121 turns on all LED's. STEP 122 is a time delay. STEP 123 permits to loop back to STEP 119, so that the flashing is performed four times. Finally, STEP 124 clears all LEDs, and then the program returns to the main subroutine Do_Test of FIGS. 1A & IB. The following is a description of the operation of the of the invention, with reference being had to Fig. 15, which is followed by the description of the individual circuits used for carrying out the above-described auto-test, which is followed by the software program for carrying out the operations detailed therein. Referring to FIG. 10, there is shown a block diagram of the telemaintenance circuit module, which is indicated generally by reference numeral 10. The telemaintenance circuit module 10 is installed in a cellular, or cellular- like, adaptor system such as that disclosed in U.S. Patent Nos. 4,658,096 and 4,737,975, and is designed to initiate a process of automatic testing from the facilities of the telephone subscriber by push-button activation or by au¬ tomatic testing at intervals of approximately 12 hours, according to the flow charts of Figs. 1A - 9, as described above in detail. The final result of this autotest will be provided to the user by way of an orange-colored light indicator (LED) installed in the right wall of the cellular, or cellular-like, adaptor. The telemaintenance circuit module 10 has the capacity of reporting the results of the test to a remote service center. This report will be accom¬ plished by way of an automatic call to the assigned number for the service center. This function requires that the ' service center be equipped with the hardware and software necessary to establish communication, and to interpret the received reports. The autodiagnostic test of the invention verifies the correct operation of the cellular, or cellular- like, adaptor, including its components, such as: principal circuits of the interface card, data cable between the radio and interface, transmission line, antenna, cellular, or cellular-like, transceiver, tollcharge circuit and supply source. The telemaintenance circuit has been configured in order to call the same number assigned to the adaptor tran¬ sceiver where the test is carried out. The autodiagnostic circuit is programmed to detect a busy or line-congestion signal as an indication that a call can be made, and that the transmission circuit is operating correctly. The telemaintenance circuit module 10 is designed to be utilized in the cellular, or cellular-like, adaptor unit in order to verify that the latter is operating correctly without necessitating sending technical personnel to the site where the equipment is installed. The telemaintenance circuit module 10 is supplied directly from the cellular, or cellular-like, interface board. The advanced telemaintenance circuit is not an autonomous circuit. Its operation depends on control signals that it receives from the auditor localized in the cellular, or cellular-like, interface board. The auditor compares the results of the tests with the parameters of the system's operating program. The auto¬ diagnostic circuit of the telemaintenance circuit module 10 conducts the following tests: Answering errors [wrong number] - This test is conducted by two alternate methods; ring voltage - the circuit generates a call and detects the presence of ring voltage that the interface card produces; Call answer - verifies that the ring stops once it is answered; Dial tone - verifies the presence of the dial tone; MFTD Operation - assures that the interface card properly detects the receipt of the MFTD [multifrequency tone detector] tones; transceiver test; reception circuit test; transmission circuit test; tollcharge circuit test - verifies the frequency characteristic of the pulses generated at 12 KHz; transceiver power supply; performance of the power supply system. These tests have been detailed above in the description of the flow charts of FIGS. 1A to 9. The telemaintenance circuit module 10 is connected to the conventional, cellular, or cellular-like, interface card by a 20-position plug connector. The test routine is initiated by way of a manual switch installed on the right side of the adaptor box. Upon finding an abnormality in the operation of the telephone, as, for example, not hearing the dial tone upon picking up the receiver, the subscriber proceeds to the adaptor box and presses a test pushbutton, which is properly identified. The telemaintenance circuit module 10 proceeds to disconnect the connection of the subscriber's telephone to the cellular, or cellular-like, interface board, and to accomplish a sequence of autodiag¬ nostic tests, as described above. The telemaintenance circuit module 10 is also programmed to initiate the test routine automatically at intervals of approximately 12 hours from the moment the cellular, or cellular-like, interface board is turned on. When the test is automatically initiated, the sequence of the outgoing test call is not generated. By means of further development, the autodiagnostic test start-up function can be initiated from a remote center. This telemaintenance function carries a modification to the operating software of the interface board, and has an aux¬ iliary development for the hardware and software of the telemaintenance center. Upon initiating the autotest routine, the orange-colored light indicator (LED) will flash to indicate to the subscriber that the test is taking place. There are pauses in the indicate flash of approximately one second between each of the tests accomplished by the circuit. The complete test will last approximately 40 seconds. Upon finishing the test, the success of the test is shown by the light indicator remaining on. In this case, the existing problem would be related to the wiring or to the telephone apparatus connected to the cellular, or cellular-like, interface board. Once the light indicator stays lit continu¬ ously, the cellular, or cellular-like, interface board returns to its normal operating condition. When a breakdown of the cellular, or cellular-like, interface board is determined from the tests, the light indicator will be extinguished indefinitely. This indicates to the user that a breakdown exists in the cellular, or cellular-like, adaptor. Once the test routine is finished, the cellular, or cellular- like, interface board returns to its normal operating condition irrespective of what breakdown was detected. The user may continue using the adaptor even with the existing limitations due to the detected breakdown. The 4-light indicator (LEDs) in the circuit of the cellular, or cellular-like, interface board will be utilized to identify the detected breakdown. This presentation is of help to the service technician who can gain access to the inside of the box in order to ascertain the nature of a possible breakdown. The combination of "on" and "off" LED's will identify the primary detected breakdown in the test. This combination will remain lit for 60 seconds once the test ends. A list of the possible breakdown codes indicated by the LED's of the cellular, or cellular-like, interface board is given below. On concluding the autotest, a call will be initiated to the telemaintenance center if a breakdown has been detected. Once the communication is established, the detected breakdown will be reported. This telemaintenance function will allow the establishment of a database for each unit. If the test was manually initiated by way of the pushbutton, the complete result of the finished test, irrespective of whether breakdowns were detected, will be reported to the tele¬ maintenance center. The following is a listing of the codes as displayed by the LED array: 4.10 ERRORCODE The sequence of the autotest is as follows. The first action accomplished by the telemaintenance circuit is disconnecting the installation of the subscriber. Then, a condition of "answer the subscriber's telephone*" is simulat¬ ed. In this condition, the correct detection of the loop closing can be checked, thus generating the dial tone. Then, the correct generation of the dial tone can be verified within a minimum frequency and level range. Next, a test of the multi-frequency tone detector of MFTD begins. This consists of the telemaintenance circuit module's autodiag¬ nostic card generating the entire sequence of 16 MFTD tones, sending it to the conventional, cellular, or cellular-like, interface board of the cellular, or cellular-like, adapter, and verifying that these tones are correctly detected. Then, a test is carried out for verifying the correct functioning of the ring generator. The ring-current is generated, verifying its frequency and level within an established minimum range. Then, the condition of answering the telephone is simulated anew, or call answer, in order to check the function of the ring circuit, which should deactivate before the telephone is answered. The next test detects the capacity of the tollcharge circuit to generate pulses at 12 KHz within a minimum frequency and level range, for the case of cellular, or cellular-like, -adapter pay telephones. The pulses generated by the tollcharge card will be detected by a precise pulse detector in the telemaintenance circuit module 10 in a manner that is well-known. For cellular, or cellular-like, adapter systems that do not have a tollcharge module,* then the connector J1.3 of the cellular, or cellular- like, interface card is configured with the bridge removed. The bridge will be installed in those units that have the tollcharge module installed. The next tests verify the functioning of the cellular, or cellular-like, transceiver. First, supply to the transceiver is verified. This test is made by means of the detection of +12 VDC derived from the data connector of the transceiver. Secondly, the transceiver is verified that it is in a condition of providing cellular, or cellular-like, access-service, indicated by the absence of the "NO SERVICE" signal. The presence of the "NO SERVICE" signal will be recognized as a breakdown. This condition can be caused by a cover defect, and not just a breakdown of the cellular, or cellular-like, transceiver. Next, a call is generated through the cellular, or cellular-like, network, to the number owned by the subscriber. The transceiver function is checked in this manner, detecting it as receiving a busy signal from the system, since, it is calling itself. In the case of finding the network congested, this will inform the transceiver of a "PATH ENGAGED" condition. The transceiver then generates a congestion (busy) tone. This tone is interpreted as a correct transceiver function, the same as the busy signal. This test will be accomplished only when the routine is manually initiated by pushbutton. This test will not be accomplished in units that initiate the process automatically. The voltage of the supply system power is also checked. If the voltage is less than 13.5 VDC, a breakdown in the supply source is detected. In Fig. 10, the main telemaintenance module 10 is coupled to the standard cellular, or cellular-like, adapter or interface board 14. Within the telemaintenance module, there are a number of individual circuits that are used for performing the self-diagnosing tests, as described above. These circuits are: The busy-signal detector 16 used during the test for proper reception of a call made by the tele¬ maintenance module during the call-back self-testing de¬ scribed above with reference to Fig. 7A; the 12,000-cycle detector circuit 18 used for tollcharge testing, which verifies the frequency characteristic of the pulses generated at 12 KHz; the MFTD generator circuit 20, which generates the DTMF signals converted by the cellular, or cellular-like, interface card, as described above with reference to Fig. 4; the ring-signal detector circuit 22, which is used for detecting the ring-signal generated by the cellular, or cellular-like, adapter interface board during the ring-test and ring-answer subroutines, described above with reference to Figs. 5A through 6; the dial-tone detector circuit 24, which detects for the proper generation of dial tone by the cellular, or cellular-like, adapter interface board 14, as described above with reference to Fig. 3; the voltage- detector circuit 28 for testing the power supply of the transceiver and the entire system; and the telemaintenance control unit 30, which is the control unit and which is also used for calling and reporting to the central reporting station the results of the autotest. The actual configuration of each of the above-noted circuits is shown in Figs. 11-14, which are described below in detail. Referring now to the FIGS. 11-14, there are shown the hardware circuits for performing the simulation tests de¬ scribed above during the entire self-testing process. Refer¬ ring to Fig. 11, there is shown the interconnection circuit of the telemaintenance circuit module 10. The part of the schematic of Fig. 11 labeled "A" shows the location where the telemaintenance circuit is hooked into the lines of TIP & RING of the conventional cellular, or cellular-like, adapter interface board. The relay labeled "RELY1" is used to disconnect the user's telephone from the cellular, or cellular-like, interface during the maintenance operation test. Instead thereof, the telemaintenance circuit is hooked up to the TIP & RING in order to perform the tests. When the "ENABLE-TEST" signal is set to HI, the transistor Q3 is forced into saturation, and then energizes RELY1, connecting the maintenance circuit to the TIP and RING. The part of the schematic of Fig. 11 labeled "B" shows the user- telephone hook-up connector, where the user's telephone can be hooked to the board in two possible ways. Jl is a two terminal connector of PI of a normal RJ11 telephone type socket. The section of the schematic of Fig. 11 labeled "C" is the audio interface circuit, which is used as an interface between the TIP and RING lines and the Audio. Tl is a telephone matching transformer. Its function is to maintain similar AC and DC current characteristics of a telephone while allowing audio signals to be received and transmitted. Z ener diodes Dl & D2 are used to cut up any signal with voltages higher than +/-4.5V. Also included is an opto- isolator SSR1 that, in conjunction with transistor Q4, offers a mechanism to close the TIP & RING circuit. When the "Conn-Loop" signal is set to HI, the transistor Q4 is forced into saturation, which then energizes SSR1, closing the circuit and performing an off-hook. The section of the schematic of Fig. 11 labeled "D" is the ring-detection circuit, which contains two main parts: U2, which is a ring-detector integrated circuit, and U9 with opto-isolator that provides a proper Cmos signal level output. A current is provide between pin 4 and pin 7 of U2 as an output signal when a ring-voltage is present at the TIP & RING lines. This current is then transformed by the opto- isolator U9, which then provides an active Low signal to the I/O. The section of the schematic of Fig. 11 labeled "E" shows the loop-current detector, which contains an opto- isolator used to detected loop current. When the test is enabled (the "Enable-Test" signal is HI in part A) and an off-hook is performed, (the "Conn-Loop" signal is HI in part C) , the TIP & RING lines go into close-circuit providing an off-hook current. This current is then transformed by U17 into an active Low signal to the I/O. The section of the schematic of Fig. 11 labeled "F" is the input-output audio circuitry composed of 1/4 of Ul, an operational amplifier IC. The main function of this circui¬ try is to isolate and pre-a plify the incoming audio signals. The output of this circuit is called "Audio-In". Also, in this section the DTMF output generated by the telemaintenance circuit of the invention is sent to the TIP & RING lines. This DTMF signal is labeled as "Tone-Out". Referring now to Fig. 12, the part of the schematic of Fig. 12 labeled "G" is the DTMF tone generator, which is composed of U4, a DTMF tone generator, and 1/4 of Ul used as an output amplifier. To generate a DTMF tone, first a four bit code is presented to the input pins labeled "DTMFO- OUT", "DTMF1-0UT", "DTMF2-0UT" and "DTMF4-0UT" in U4. Then, while keeping the four bit code, the enable signal labeled "DTMF-OUT" is changed from Low to HI level, thus allowing the tone to be generated. The audio is output at "TONE-OUT" after the audio had been amplified by U1:C. To stop the tone, the "DTMF-OUT" signal is returned to low level. The section of the schematic of Fig. 12 labeled "H" is the input/output port, the I/O Port IC labeled U8. This integrated circuit is used by the microcontroller of the cellular, or cellular-like, interface board to read the input data and to control all of the output of the telemain¬ tenance module. Ports A and C are input ports, while port B is an output port. Jumper J4 is the selector for the automatic periodic test with possible selections of 12 or 24 hours. J5 is used as an enable for the call to the "au¬ tomatic answer". The sections of the schematic of Fig. 12 labeled "1.1" and "1.2" are the power, data and control connectors, and contain J2, a 2 by 10 male header connector used to bring power, as well to send and receive data to the I/O Port. It also includes a 4 pin header connector for the external LED used to show the status of the test, and an external push button used to manually activate the test. The section of the schematic of Fig. 12 labeled "J" is the power regulator, and has U7, a 5 Volt fix-positive regulator that supplies the voltage necessary for the digital circuits. The telemaintenance module 10 contains six single tone detectors used for testing the receiving audio path, fre¬ quency and timing cadence of ROH, Dial, Busy and Congestion tones. Each of the tone detectors is composed of an opera¬ tional amplifier and a single tone detector IC. The input of the Opamp is connected to line "AUDIO-IN". The frequency of detection is set by a resistor located between pin 5 and 6 and a capacitor located between pin 6 and ground. When a valid tone matches the programmed tone by the RC, the tone detector output pin is forced from HI to Low. Section "K" of Fig. 12 shows the dial-tone detector circuit. When a valid dial tone is present at the input of U3, the "DIAL-DETECT" line is forced to go Low. Section "L" shows the busy-tone detector circuit. When a valid busy tone is present at the input of U6, the "BUSY-DETECT" line is forced to go Low. Section "M" of FIG. 13 shows a 400 Hz. tone-detector circuit. When a valid 400 Hz. tone is present at the input of U14, the "400-DETECT" line is forced to go Low. Section "N" of FIG. 14 shows a 800 Hz. tone-detector circuit. When a valid 800 Hz. tone is present at the input of U13, the "800-DETECT" line is forced Low. Section "0" shows a 1020 Hz. tone-detector circuit. When a valid 1020 Hz. tone is present at the input of U16, the "1020-DETECT" line is forced Low. Section "P" shows a 12 KHz. tone-detector circuit. When a valid 12 KHz. tone is present at the input of U12, the "12KHz-DETECT" line is forced Low. Section "Q" of FIG. 13 shows a DTMF tone decoder, which is composed of Ull, a DTMF tone detector and 1/4 of Ul used as an input pre-amplifier. When a valid DTMF tone is present at the input pin (IN-) , the control line "DTMF-STROBE" is forced Low, while the IC is decoding. After the tone has been decoded, a four bit code is output to pins labeled "DTMFO-IN", "DTMF1-IN", "DTMF2-IN" and "DTMF4-IN" in Ull. The control line "DTMF-STROBE" is then returned to HI again. Section R is an AC monitor, having UIO, a 4.5V under-voltage detector. Resistors R17 and R33 form a voltage divider that will make UIO sense voltage under 13 volts instead of 4.5 volts. The circuit works on the assumption that when the supply voltage comes from the power supply, a 14V is present at the entrance of the telemaintenance module. On the event of an AC power failure, the voltage drops to the battery back-up level, which is not greater than 13 volts. The circuit will detect the drop, and UIO will drive line labeled "AC-DETECT" to Low. The following is a listing of the source code for performing the invention. $nopi nosb db noge nomo nopr ep Snolist $include(reg252.pdf) $list t^**********-*****-******************^ Maxjack by Alexis V. Torres for Codecom Rural Comm. Inc. (C) Copyright Codecom Rural Comm. Inc. 1993 Telephone/cellular interface: Main program with the maintenance board 11-29-92 maint.asm ; These are the universal landline phone key codes. zero equ Oah [0] key code star equ Obh [*] key code pound equ Och [#] key code ; Buffer area pointers for the HS display and the TRU messages. dspbuf_start equ 80h ; Start of 16 byte LCD display buffer dspbuf_end equ 90h ; End of LCD display buffer msgbuf_start equ 90h ; Start of TRU (etc) msg buffer msgbuf_end equ Oh ; End of TRU msg buffer main flag equ ObOh ; use indirect address for test flag ;hook_slic 1 ;dial 2 ;dtmf_ 3 ;ring_test 4 ;ans test 5 main_flag_error equ Oblh ;hook_slic_error 1 ; hook error ;hook_ring_error 2 ; hook error ;dial_error 3 ; dial tone error ;dtmf_error 4 ; dtmf error ;ring_test_error 5 ; ring error ;ans_test_error 6 ; ring answer error mainl_flag equ 0b2h ; ditto ;power_radio 1 ; power radio error ;call_test 2 ; call error ;call tone 3 ; call audio error mainl_flag_error equ 0b3h ; ditto power_radio_error 1 ; spare call_test_error 2 ; call spare error call tone error 3 ; call audio spare error »*** + *** + * + *********** + * +++++ ******************** Internal Ram variable definitions t************************************************ ; Registers occupy bytes 00h-07h (reg. bank 0) ;rf ) storage pointer (also address pointer for I/O expander) ;rl pointer to storage of data from TRU ;r2 digit count ;r3 delay loop for bus timer ;r4 delay loop for bus timer ;r5 used in rohtone timer ;r6 used in send_time ;r7 used in rohtone timer ; Variable storage locations time_offl data lOh ■ .Measures off-hook time time_off2 data llh • Measures off-hook time time_off3 data 12h • .Measures off-hook time time onl data 13h • Measures on-hook time time on2 data 14h ■ Measures on-hook time ; Value of pulse dialed digit • Checks for 2 sec after in use lamp ; goes out to do cpd ■ Timer checks time between rings ;Timer generates 20hz for ringer • Timer for ringer • Releases GS line if no connect in lsec ;Same as above ■ .Stores dph for tone tables ;Stores dpi for tone tables ;Stores dph for tone tables • Stores dpi for tone tables **************************************************************** The Ram area 20h thru 29h is reserved for use by the main module either as data BYTEs or individual BITs **************************************************************** ;This byte contains the following flags ; as individually addressable bits ;Off hook flag set by coming off hook, ; cleared when processed ;Send flag • Flash flag ;Hang up flag ;40 second timer flag ;Flag for pulse dig input ;On hook flag set 700msec "After hup, cleared by coming off-hook fdtmfm bit 07h ;Dtmf input flag inds DATA 21h • Indicators - this byte contains the ; following bits: • Roam indicator ;No service indicator • Lock indicator • Reset digit display • Horn indicator ;Set by TRU only! (1 = inks done) ; 1 = onhook ints disabled for 500ms ; auto test ; after first offhook to deglitch the ; contact bounces indasc DATA 22h • Indicators & audio switch control this ; byte contains the following bits: muse bit lOh ;In use indicator flags3 DATA 28h More flags- this byte contains the following individually addressable bits frohtimeout bit 40h Set when rohtone has been on 1 minute fcall bit 41h Set when call incoming, clear if not f one sec bit 42h Set when off hook for one sec so change in inuse lamp won't cause remote hangup if phone taken off hook quickly after local hangup roh_on bit 43h Turns rohtone on & off fspecl bit 44h ;Flag for special use with specific TRU processed in update_displays every 71.1 ms, calls sped fspec2 bit 45h Flag for special use with specific TRU processed in on- or off-hook timers every 277.8 usec, calls spec2 fremote_hup bit 46h Indicates remote hup for 700 msec delay flocktimer bit 47h Flag to lock after 2 seconds *********************************************** Implemented TRU tasks ****** * *********** * ***** * ********** ** ** ** * * **** ** * * ************* f_cmds DATA 29h ; Optional TRU specific task numbers ; TRU tasks are for calls from the mam into the TRU module. Task l: a.) Power loss check for NEC 3700 (see naeOl) b.) Send change in hook switch status to OKI and also send initial CLR for the Motorola (see oee02 and mae04) c.) Call rdbus routine to read indicator status in the Audiovox TRUs (see taeOl and tbeOl) d.) Monitor for silent alert mode in Audiovox CTX-3100A and set silent alert mode if necessary (see tbeOl) Task 2: a.) Dual NAM switching for NEC 3700 (see naeOl) Task 3: a.) Power loss check for NEC 3700 (see naeOl) b.) Send any change in hook switch status to OKI and Motorola (see mae04 and oee02) c.) Call rdbus routine to read indicator status in the Audiovox TRUs (see taeOl and tbeOl) d.) Monitor for silent alert mode in Audiovox CTX-3100A and set silent alert mode if necessary (see tbeOl) Task 4: a.) Call rdbus routine to read indicator status in the Audiovox TRUs (see taeOl and tbeOl) b.) Monitor for silent alert mode in Audiovox CTX-3100A and set silent alert mode if necessary (see tbeOl) **************************************************************** The Ram area 2Ah thru 2dh is reserved for use by the TRU modules either as DATA bytes or individual BIT variables. **************************************************************** ;Bit 78h through 7fh **************************************************************** More internal (BYTE addressable) ram variables **************************************************************** ; Delays looptest for 2ms after loopsw ; closes to allow SLIC to respond ; Delays display update to every 71.1ms ; Handset LCD display buffer pointer ; TRU message buffer pointer **************************************************************** The following bytes are reserved for the TRU modules for use only as DATA bytes (not BIT addressable) **************************************************************** ; Stack occupies bytes 40h-5fh * * * ** *********** * ** * ****** * ********* ** ***** *** ****** ** **** ** ** Digits dialed are stored in bytes from 60h to 7fh permitting a total of 32, including the SND code used as a terminator. ************************************************************** ; Only [0] or (1] are valid, else FFh ; First three locations in the digit ; buffer (emergency numbers, area code ; start of 7digit number, etc.) **************************************************************** 8051 portl & port3 bit definitions, (common to all units) **************************************************************** ; Dial tone pwm ; 20hz pwm for ringer ; Input , 0 = power supply is failing ; Loop current sense, (ExtlntO) ; Input: shows ground on ring lead ; Input:digit ready from DTMF decoder **************************************************************** Power up entry point, and interrupt routine vectors: **************************************************************** org OOOOh ; Reset vector jmp init org 0003h ; ExtlntO service vector jmp offhook_edge ; Off hook, flash, & pulse dial db 0ffh,0ffh,0ffh,0ffti,0ffh ; Fill for Eprom and emulator org OOObh ; TimerO (tlO) svc vector jmp onhook timer ; To keep track of how long on hook db 0ffh,0ffh,0ffh,0ffh,0ffh org 0013h ; Extlntl service vector jmp intl service ; Usually to read data from TRU db Offi θf-h,Of_h,Offh,Offh org OOlbh ; Timerl (thO) svc vector jmp offhook timer ; For periodic timer ints db 0ffh,0ffh~0ffh,0ffh,0ffh org 0023h ; Serial port svc vector jmp ser j port_service ; Usually to read data from TRU db 0ffh,0ffh,0ffh,0ffh,0ffh org 002bh ; Timer2/ext2 svc vector jmp timer2_service db 0ffh,0ffh,0ffh,0ffh,0ffh Load high counter Load low counter Low byte for timer comparator High byte for timer comparator PCAO: software timer PCA1: (Dial Tone) off for now PCA2 (20 hz pwm) is off now Off-hook int timer not running yet On-hook timer not running ; Initialize byte variables ; Initialize onhook interrupt timers ; Initialize offhook interrupt timers Clear all the flags Clear all the flags Clear all the flags Initial vals Initial vals 0 = no pulse digit(s) available now 0 = no TRU task commanded 1= Assume phone on hook on power up 0 = TRU init not completed yet 0 = No incoming call (ALERT) yet Clear handset LCD display buffer Clear TRU messages buffer Do TRU specific initializations Low byte for watchdog match word High byte for watchdog match word PCA4:Enable comparator &interrupt Enable watchdog timer Start PCA counter Start on hook timer ; Wait 2.55 second for TRU to wake up. Clear the dialed digits location, -. then point RO to digits buffer start (60h), and clear R2 (dialed digits ; count). time wakeup: call watchdog mov a,time on2 ; Get elapsed time ; Wait here 2.55sec for tru wakeup ; Check GS-LS jumper, 0 = LS 1 = GS ; Save start mode ; TRU module here, so INTMASK can be ; evaluated at assembly time *************************************************************** Start, and Re-Entry point following hang up *************************************************************** ; Endless loop until we either detect an incoming call or we lift ; the handset to dial out. hookchk: ; if auto test activated ; Load command ID ; Do taskl for TRU, if needed ; Brif off hook ; Back if no incoming ring detected ; Answer ring, we went off hook during ; an ALERT (incoming call) state! firstl: jmp first do test: ; set the tone error busy or lOOOhz ; set the tone error busy or lOOOhz clr error_flag mov rl,#main_flag mov a,@rl ; read first flag anl a,#0O000O01b ; check if hook was done call start hook test ; hook test test_hook: jb error_flag,rou_error call dial_test ; dial test test_dial: jb error_flag,rou_error call start_dtmf ; dtmf test test dtmf: jb error_flag,rou_error call start_ring_test ; ring test test ring: jb error_flag,rou_error call start_ring_ans_test ; ring answer test test ring_a: jb error_flag,rou_error call make_call ; call test jb error_flag,rou_error jmp until_fin tim ; exit without errors rou error: call erτor_acc ; load error variable ; jmp wait_end until_fin_tim: setb test end clr trO " mov time_on2,#0 -Every 10 msec while on hook mov time_onl,#0 • Reset for next 36 mov test min,#0 ; 10 msec x 255 = .255 sec setb trO ~ wait end: call watchdog ; be here until 1 min expire mov a,test_min cjne a,#23,wait_end ; .255 x236 = 60.18 call fm_self ; return to normal jmp hookchk ; return to normal If******************************************* start hook test- start hook test ************************************************ start_hook_test: mov rl,#main flag ; read main flag mov a,@rl orl a,#00000001b mov @rl,a ; set the off-hook flag setb enable_test • disconnect the telephone clr conn loop call write_io m_b ; and connect module call reset_io_m ; reset the maintanence board call write_io m b call write io m c clr loopswitch_ ;Other side has discoimected call write_px2 test_hup: setb fremote_hup call hup mov lamps_temp,#0 call write io c ; update the LEDS mov r6,#10 nose: ; delay module mov r6,#0ffh ; delay module loop ma: mov r6,#0ffh ; delay off hook loop_m_off: mov r7,#0ffh djnz r7,$ call watchdog djnz r6,loop m off mov r6,#0ffh ; delay off hook loop_m_off2: mov r7,#0ffh djnz r7,$ call watchdog djnz r6,loop_m_off2 mov r6,#0ffh ; delay off hook loop m off3: mov r7,#0ffh djnz \r7,$ call watchdog djnz r6,loop_m_off3 mov r6,#0ffh ; delay off hook loop m off4: mov r7,#0ffh djnz r7,$ call watchdog djnz r6,loop_m_off4 mov r6,#0ffh ; delay off hook loop_m_off5: mov r7,#0ffh djnz r7,$ call watchdog djnz r6,loop_m off5 test fhook: jb fhook,detected_hook ; if hook detected ok ; not off-hook det error jmp hook_error detected_hook: clr exO ; Disable offhook int til dial tone to ; prevent dialing due to bounce clr hookswout ; Show off-hook to TRU setb hookswout ; Ditto clr fhook ; Clear the flag dt_delayl: call watchdog jnb lc_,still_off_hook jmp hook_error ; fail off hook still off_hook: jb f_start,dt_delayl ; Will be set after 500ms deglitching clr ieO ; Clear offhook int flag just in case setb exO setb fdtone ; 1 = the Dial Tone is on call dtone ; Enable the Dial Tone ret ; exit from hook test hook_error: mov rl,#main_flag_error mov @rl,#l ; hook slic error setb error flag ret ************************************************* dial_test check the dial tone **** * ********************************************* dial test: ret .************************************************* > ;start_dtmf - start the dtmf .**** * ** * *********************** * ***************** call get_test test 5: test 6: test 7: test 8: test 9: test a: test b: ;es3 ;esd ;es7 ;esf ; exit without errors ; dtmf error ;start_ring_test - start the ring test .************************************************* start_ring_test: ; init the ringing .** • * * * ** ********* ***** ** • *** * **** * *** * ** ******* ** ;start_ring_ans_test - answer the ring . *•**** * * *** * ** *******•***•• *** ****************• ** start_ring_ans_test: ; init the ringing ; read main flag ; set the ring test flag ; wait here until ring start again ; if ring answer exit ; if cero ring present ; wait 2 sec to stop ; 2 sec expire ; answer the ring ; delay to allow time to set fanswer ; read mainl flag ; set the call test flag ; if radio ok line should be low(O) ; set the power line error ; function to read the phone number ; delay to allow time to send number ; to interface ; generate a call to its phone number ; Get current pointer ; Read msg in buffer ; Read msg in buffer ; Read msg in buffer ; Read msg in buffer ; Read msg in buffer ; Read msg in buffer ; Read msg in buffer ; Set send flag ; make a call ; enable Q4 ; do not mute ; hook slic error ; hook ring error ; dial error ; dtmf error ; ring detection error ; rmg answer error ; check calls flag ; power radio error ; xxx error ; busy tone error ; muse error ; lOOOhz tone error jmp exit error exit_error: ret ************************************************ fin self - return to normal ** * *** * * *** * * ** **** * ********* ***** * * **** ** * * **** fin self: clr conn_loop ; present on hook to the call writejo j m c : interface call hup clr enable_test ; connect the the telephone call write_io_m b ; and disconnect module clr test_enable ; init maint test clr test_end ; finish test clr error_flag ; error flag jnb error_flag,turn on_led clr ext_led ; turn off external led while testing call write_io_m c ; turn on/off the external led call loop_bad turn on led: setb ext_led ; turn off external led while testing call write_io_m c ; turn on/off the external led call loop_bad clr extjed ; turn off external led while testing call write_io_m c ; turn on/off the external led call loop_bad setb extjed ; turn off external led while testing call write_io_m_c ; turn on/off the external led call loop_bad clr ext_led ; turn off external led while testing call writeJo_m_c ; turn on/off the external led call loop_bad setb extjed ; turn off external led while testing call write o_m c ; turn on/off the external led call loop_bad test 4on: clr extjed ; turn off external led while testing call writeJo_m_c ; turn on/off the external led call loop bad ret loop_bad: mov r7,#0ffh ; delay to allow time to set fanswer wait_emb: mov r6,#0ffh djnz r6,$ call watchdog ; Clear previous TRU messages ; Disable offhook int til dial tone to ; prevent dialing due to bounce ; Show off-hook to TRU ; Ditto ; Clear the flag ;NOTE:INT0 & TIMERO have been suspended ; at this point - do not use any tru ; specific function which relies on ; these interrupts. ; Perform any TRU specific commands ; Will be set after 500ms deglitching ; Clear offhook int flag just in case ; Brif still off hook after 500ms ; Phone put back on hook ___ 500 msec ; Reenable offhook int (DT is on now) ; Brif not INUSE, we are ready to dial ; If already INUSE probably answered ; an incoming call by coming offhook ; We are off hook for 500ms lets generate a dial tone, make dt: setb fdtone ; 1 = the Dial Tone is on call dtone ; Enable the Dial Tone call get ; Get a character or exit if hang up jb inuse,check_prefix clr fdtone mov ccapml,#0 jmp wait ; Brif TRU isn't locked ; Brif locked, only # (unlock) is valid ; Brif not a [0] ; Go to store [0] as prefix ; Brif not a [1] either ; Go to store [1] as prefix ; Leave prefix slot unchanged (FFh) ; But up the digit count ; Store current digit and get another one until time to send them out. ; Brif digit buffer is not full yet ; Brif buffer is full, w/o storing ; Store the digit ; Advance digit buffer pointer ; Check the entered digits and analyze them for valid sequences. ; Assure it is off ; Point to 1st digit slot ; Brif first digit entered ; Else check if time to send ; Brif not [#] (lock, unlock, etc.) ; Point to 2nd digit if first is [#] ; Brif second digit entered ; Else check if time to send ; Brif not [#][#] (lock or unlock) ; Two #'s might be lock or unlock ; Three #'s mean locking ; Do not lock if already locked ; [#][#][#] means locking ; Abort if not [#][*] sequence ; Else get the third digit also ; Brif third digit entered ; Else check if time to send ; Load function number, then go to ; Switch to alternate NAM ; Abort on invalid number (dial) sequences, nosend: clr funlocktimer ; Turn off unlock timer # sign set it ; As if on hook ; Go to ExtlntO service ; just like off hook again ; Brif any digit was dialed after ## ; Else go to check if time to send ; Will send after 2sec w/o SND code ; to avoid unlock code being sent like ; a valid number ; Get here if the digit sequence entered did not qualify as any ; of the special function (lock, unlock, dual NAM, etc) options. ; Brif sw7= 1, interntnl calls enabled ; Enable sending after 4 sec if sw7= 0 ; And back for next digit ; Test for prefix in ace ; Brif not [0] ; Else get the first real digit ; Brif not [1], may be operator call ; International call! Starts with 01-.. ; Back for more, only timer sends now! ; Get prefix digit again ; Brif prefix is not 0 ; Brif digit(s) also were dialed ; Else it may be a call to operator ; Brif not 3 digits ; Else if emergency, inform, etc. ; Brif second digit is 1 ; Get third digit ; Brif third digit is not 1 ; It must be an emerg., send it ; Ten digit was dialed? ; Send on 10th unless international ; Brif less then seven digit was dialed ; Prepare to send in 4 sec ; Get 2nd digit ; Is it a #1 ? ; Brif so, could be area code, or local ; Get 2nd digit again subb a,#10 ; Is it a 0 ? \ ~ get_next ; Brif so, maybe area code, maybe local clr fsendtimer ; Don't want another, send 5sec later jmp send it get_next: call get ;Get a new digit jmp store it ;Do all the checks with the new digit ************************************************* Dialing done, send the number out ************************************************ ; Check if the TRU is locked, and abort if no unlock code was entered. send it: jb lock,sendl ; Brif TRU is not locked locked: ; Get third digit ; Brif any digit entered ; Don't send if no unlock code entered ;Mute rx audio ;Put send at end of digits ;Clear code ;Put clear code first to clear any ; digits from TRU memory in case ; handset has entered some first ■ Reset pointer to show storage ;Put prefix in ace ;Skip prefix if it is ff ■ Write to the bus ■ Abort dump if hangup ;Keep on til SND code ;Set send flag ;Unmute rx audio ; Dialing done, conditionally echo digit to TRU, then wait for ; further possible digits (extension, etc.), or let the interrupts ; take over the show. wait: call get ;Check for any digits from MJ phone jnb sw_data,wait ■ Discard if data after snd is disabled call wrbus ■ Else send data to TRU jmp wait ■ Loop til we or other party hangs up ************************************************* Dial Tone Generator ************************************************* ; This routine selects and generates the proper dial tone, ; corresponding to our current (roam, holler, etc) status. ret .********************************** * ****** *** ***** ; Get a digit from the handset keypad . * ************ * ******** * ********* * **************** ; This routine processes the digit input and/or process flags. ; On return - returns data in ace get: push psw getl: ;Flag indicates which functions apply "Perform any TRU specific commands ; Wait for a pulse. If the pulse was not flagged as a pulse dial input ; by EXTINTO (Off_Hook_Service), we check for a DTMF digit input. If it ; was a pulse dial input then we continue counting pulses, until 250 ms ; has passed after receiving the last pulse. At that point we consider ; assembling the pulse dial digit completed, so we copy it into the ace, ; and set the fdig_ready flag. • Clear dial tone flag ■ Turn off dial tone ;If there was an input -Clear carry for subtraction ;See if 213.3 msec (3x71.1 ms) passed ;If not yet, then digit not complete ■ Clear carry for subtraction ;See if additional 36.7 msec ; (132x277.8 usec) has passed (total ; time of 250 msec) ;If not yet, then digit not complete ;Put digit in a ■ Clear for next dig ;To show a digit ready -Clear the flag ; If a DTMF dial digit is ready, copy it into the ace. Check for special ; conditions, flash, hang up etc. Branch on special conditions, or continue ; checking for more pulse(s), and/or completed digits. ; Check for flash (200 = pulse = 700ms). ;If no flash • Clear flash flag ;Turn off dial tone ;If dial tone on just a send for last ; number redial ;If send flag is set don't put digits, ; just a send ■ Clear dial tone flag "Correct stack pointer ■ Leaving subrout without ret • Output all digits + send ; Transmit only a SEND code, but not the digits, if ; either the Dial Tone or the Send flag is high. • Clear dial tone flag ;Send code • Send flag ; Restore flags ■ Correct stack pointer ; Back for digit(s), hangup etc. ; If we did not dial a complete phone number yet, and 40 second passed ; since the last key punch, then we start a 1 minute holler tone. ■ Check for (28 x 71.4 ms = ) 2sec ■ Correct stack pointer ■ Leaving subrout without ret ; Do not unlock, if already unlocked • As if on hook ;Go to ExtlntO service -Just like off hook again • Flocktimer added to allow lock to timeout on less than 4 digits. Go lock • label must be added to TRU and also setting of flocktimer (if necessary). Brif not 71.4 ms timer in r6 Check for (28*71.4ms = 2 sec) ; Correct SP ;Look again if no digit in ■ Clear the digit ready flag ; Restart timers on every digit input ************************************************* Get a digit from the handset keypad *************** * ********************************* ; This routine processes the digit input and/or process flags. ; On return - returns data in ace get est: push* psw ; If a DTMF dial digit is ready, copy it into the ace. Check for special ; conditions, flash, hang up etc. Branch on special conditions, or continue ; checking for more pulse(s), and/or completed digits. ■ Clear dial tone flag ;Turn off dial tone ■ Clear dtmf input flag ;Put digit in ace ;Keep only low 4 bits ;To show a digit ready ■ Clear the digit ready flag ; Restart timers on every digit input ********************************************************************** send dtmf - send a dial tone ********************************************************************** send_dtmf: call watchdog clr dtmf_out ; enable the dtmf tone call writeJo_m_b setb dtmf_out ; enable the dtmf tone call writeJo_m_b ret clr_dtmf - send a dial tone ******************************* * * * * ** **** ** *** * *** * ******** * ********** disable_dtmf: clr dtmf_out ; enable the dtmf tone call write io_m b ret delay dtmf: ; delay the DTMF tone clr trl mov time_off2,#0 mov time~offl,#0 setb trl wait until dtmf: mov a,time_off2 call watchdog cjne a,#4,wait until dtmf ; wait 40 msec to stop the dtmf ret ************************************************* ROH tone generator ************************************************* ; 40 sec has passed after we lifted the handset w/o dialing any digits, ; or since we have dialed the last digit. We shall generate an ROH tone ; (interrupted at 80 msec intervals) for 1 minute or until we hang_up, ; whichever happens first. rohtone: ; Loop here for 1 minute, or until hang_up. ; leave loop open til ring ground ; Get here if we are in Loopstart mode, looptest: mov b,#40 ; Set up 2 sec delay (40 x 50 ms) looptl: mov a,time_on2 ; Get current onhook time add a,#5 ; Add 50ms to present time loopt2: call watchdog ; Refresh watchdog cjne a,time on2,loopt2 ; Minor delay is 50 ms djnz b,looptl Wait 2 sec total clr loopswitch_ Close loop in every 2sec to check call write_px2 if phone was put back on hook mov looptestjimer2,#215 Load 2.22msec delay (8x277.8 usec) loopt3: mov looptest imer,#Offh ; To allow enough time for the SLIC djnz looptest imer,$ ; chip to indicate the hook status call watchdog ; Refresh watchdog djnz looptest imer2,loopt3 jb lc_,looptest_end ; Brif no loop current (back on hook) setb loopswitch_ ; Open loop switch again call write_px2 jmp looptest ; Wait here until hung up looptest_end: clr frohtimeout ; 0 = has been hung up, or in GS mode mov time onl,#0 ; Reset on hook timers mov time~on2,#0 jmp start ; Start new ************************************************* Subroutine for hang up ************************************************* hup: ; sn't nee e an c ears t e bu fer ; on the Motorola unnecessarily. ;Put end code ; Send it to TRU first, then reset flag ;in case digits sent or alert answered • Show on hook to TRU ;Ditto ■ Don't do timing if loop start ;Get delay time back ■ Clear carry flag for next ;Wait 750 ms to allow loop to open ; and pbx to see it as disconnect. ; jmp to next instruction in any case jnc hup3 ;No carry til time_on2 greaterthan ace ; (in case bus write took more than ; 750 ms) hup4: ************************************************* TRU status update * ************************************ * * * ********* ; Routine updates TRU status every 71.4 ms, and turns ringer ; on and off. Also checks for 3.9 second interval after a ring. • Check special flag • Special routine in TRU section ; check if test started ;Hold values for comparison later ; No real lamps for the Maxjack! • Roam indicator (just for storage) ;Noserv indicator (just for storage) ;Lock indicator (just for storage) ;Inuse indicator (just for storage) call writejo c ; update the LEDS jb sw dialtone,not maint ;If option sw is out ( = 1) ; not maintenance module test push: call read Jo m a ; read push button anl a,#OOθiθθδθb cjne a,#Oh,not_push setb test_enable ; init maint test setb fremote hup ; set remote hup for 700ms setb loopswitch_ • Other side has disconnected call write_px2 not_push: jnb test_enable,not_maint ; check if test started go o_self: jnb test_end,not_error_yet ; if error was found jnb error_flag,pass_ok testjed: mov rO,#error_code mov a,@rO rl a rl a rl a rl a mov lamps emp.a call writejo c ; update the LEDS setb extjed ; turn on external led 1 minute jmp writeJo_c pass ok: clr extjed ; turn on external led 1 minute jmp writeJo_c not_error_yet: jb extjed,clr led setb extjed ; turn on external led while testing jmp writeJo_c clrjed: clr extjed ; turn off external led while testing write to_c: call writeJo_m_c ; turn on/off the external led not_maint: mov a,lamps emp ; Hold values for comparison later jb frohtimeout,compare mov c,ap2 Check we are in ALERT state, anl cJapl (i.e.: incoming call waiting) jnc compare Brif not ALERT (no incoming call) jnb fonhook,compare Brif off hook, don't ring bell! clr loopswitch_ Close loop switch if ALERT state, call write_px2 (incoming call is waiting) jb fcall,reset ring imer Brif ringing is already in progress setb fcall 1 = start ringing (ALERT detected) mov bell imer,#0 Reset timers mov bell~timer2,#0 setb fbellsoimd ;Flag bell sounding mov dptr,#table_20 ;Point to 20 hz table for ring mov lowpoint,dpl ; Save ringer table starts ; We get here if the other party hang-up and we did not put the phone ; back on hook within 2 seconds. ;When carry, 100 ms ;Brif ring PS is already turned off ;Else turn off ring PS now ;Out to port ;Out to port ;8 x 25 ms = 200 ms ■ Ready to do subtract ;When carry, 200 ms ;Stop pwm ;Leave output pinlow.pwm has run 100 ; ms longer than ring ps to smooth out ; waveform ;0 = not ALERT, assure no ringing ;Brif loop start ;GS didnt answer ring Reload Watch Dog Compare Word ************************************************* ; Disable ints ; Point to start of current page ; Current page ************************************************* TimerO (TL0) on-hook interrupt service routine ************************************************* ;Stop offhook timer ■ Clear pending ints by offhook timer ;If already muted skip this setb mute ;Mute rx audio to prevent false ; decoding of audio ring as dtmf, ; also prevent audio feedback call write_px2 ;Out to port ■ Check flag ;Call special routine in TRU section ;In 71.1 ms ;Every 71.1 ms ;Skip outgoing GS init on incoming call ; Brif not in GS mode ;Don't look for ring ground to start ; GS until really hung up ■ Groundstart service was requested ;Init timer ■ Subscriber has released ring ground ;25 ms (90 x 277.8 us) ;Every 25 msec ;Reset for next count of 90 ;1 sec (40 x 25 ms) ■ Open loop in 1 sec if sub didn't ; complete loop ; Brif ALERT state to generate ringing ; Else just do timers update ; We shall ring the bell if the TRU is in ALERT state, (an incoming ; call is waiting to be picked up). ring control: jb fbellsound,timing ring When bell not sounding during ring cycle, check for ring ground to indicate answer due to ringing pulses jb ring_ground_,timing_ring If no ring ground,time the ring.Now ignore the pulse on ring ground as ringer stops Incs every 25 ms Observe any ring ground after 25 ms 29 x 277.8 us = 8.1 ms Ready to subtract No carry til 8.1 ms after ring stops. Only ignore ring ground 8.1 ms ;If ring ground indicates came off hook ; during silent lime, start 20 hz ; again to force ring trip ;Every 277.8 usec ;25 msec (90 x 277.8 us) • Reset for next 90 • Every 25 msec ;Brif bell is not sounding now ; The on time ringer modified from 1.95 sees to 1.975 sees, because the ring ; stops at the positive peak which causes a continous ringing. This problem ; was producing with 5 ringer box applying with maxjack. (ssh) ;Get elapsed "bell on" time ;Brif less then 79x25ms= 1.975 sees ;45 x 277.8 us = 12.5ms (total 1.987s ;Ring stops after 1.987secs on negative ; peak, chops off last quarter cycle ; for proper ring trip • Enable pwm ;0 = the bell not sounding ■ Point to table of null tone (nulltone ; causes ringer to have zero AC out, ; only battery) mov lowpoint,dpl ;Save the null table start mov highpoint,dph mov ccapm2,#01000010b "Enable pwm clr ea clr no_ring call write_px2 setb ea call watchdog jmp reset_bell imers ■ Reset timers ringer_off: mov a,belljimer2 cjne a,# 120,onhook Jimers ;4 sec with no ring (160 x 25) start_bellsound: call resetjo call write_pxl call write_px2 clr ea setb no_ring call write_px2 setb ea mov ccapm2,#0 "Enable pwm mov dptr,#table_20 ■ Point to table for 20 hz mov • lowpoint,dpl ■ Remember where table starts mov highpoint,dph mov ccapm2,#01000010b ■ Enable pwm test relayl: ************************************************* Timerl (THO) off-hook interrupt service routine ************************************************* ; Check for a DTMF digit, and read it from the MT8870 if there ; is one available. jmp ttime ; and just do offhook timing task Brif DTMF digit already was read Else read it now 1 = DTMF digit received! 1 = DTMF digit being processed ; Check elapsed offhook time, update displays in every 71ms, and ; start-end ROH tone as required. ttime: inc time_offl ; Bump minor offhook timer (@ 277.8us) mov a,time offl ; Get minor offhook time ■ JMP TEST HOOK Brif 256*277us= 71.1ms Bump major timer (every 71.1ms) Do update every 71.1ms Get major offhook time Brif _ 256*71.1ms = 18.2sec Bump total offhook timer (@ 18.2sec) ; Get major offhook time ; Brif _ 14*71.1ms= 995ms passed ; so change in INUSE lamp won't cause ; hangup if phone taken off hook too ; soon after hangup Brif we originated the call (no ROH) Brif we are INUSE (no ROH either) Bump minor ROH start/end timer Brif = 35*277.8us= 10ms passed Bump minor ROH on/off timer Reset for another pass (10ms) Brif m 10*10ms= 100ms passed Toggle ROH on/off every 100ms Reset for another on/off phase ; Get total elapsed offhook time ; Brif = 2x18.2 =36.3sec passed ; Get additional major time too ; Brif = 40sec total offhook ; 1 = ROH period started ; Get total offhook time again ; Brif = 5*18.2=91sec passed ; Get additional major time too ; Brif ____ 91 + (127*71.1 ms) = lOOsec ; 1 = ROH period expired ; Brif not timing 500ms after "first" ; Get elapsed offhook time ; Brif _ 285ms elapsed ; Brif _ 500ms elapsed ; Reenable onhook ints after 500ms ; Get here only after 500ms passed following the first offhook after ; every hang up. tdoneO: jnb lc ,tdonel ; Brif offhook now test trO: clr trl ; Else stop the off hook timer setb trO ; and start on hook timer tdonel: pop ace ; Restore pop psw reti ************************************************* External Interrupt 0 service routine offhook_edge: t loop_ringl: mov r6,#0ffh ; Turn off onhook jimer and flag ; Turn off onhook_timer and flag ; in case onhook Jimer int pending ■ Discard pending EXO (LC_) interrupt -Start off-hook timer ;Clear hangup flag for safety • Reset offhook timer • Timers incremented by thO interrupts ;Unmute rx audio ;Brif wasn't hung up ; coming back off hook clr fonhook -Clear the flag, it was hung up, now ;2 x 10 = 20 msec • Clear carry for subtraction ;20-200 msec is pulse ;Just a glitch • Contains the number • Possible digit flag ■ Reset on-hook timers so they can be ; restarted on hang up ************************************************* PCA Interrupt Routine ************************************************* ; PCA interrupts are generated by using module 0's (software timer) ; compare/match option on every low count = FF match. This way we can ; generate an interrupt at the end of each page, OOFF-0100, OlFF-0200 ; etc. which gives us an interrupt at every (256*1.085us) 278us. ; This Maxjack implementation is using conditional assembly to produce ; a modified PCA service routine for TRUs with extremely high data transfer ; rates (Audiovox requires the alternate PCA routine). "Going to simulate third interrupt ; priority level "Defined in TRU section ;To execute the reti ;Look at tone pwm ;Look at ring pwm • Just look at pwm bit • Skip next part if no tone or ring ; output • Initialize pointer ;Get data from table • Reset index this is end of table ;So index will be right • Read first entry ;Put data in tone pwm ;Put data into ring pwm -only tone ; or ring pwm is running at any given ; time mc dptr ■ Point to next table entry for next ; time ■ Reset the module 0 flag • Disable ints ■ Reload low match and suspend ; comparator ;Get last page ;Point to next page ;Load high match and restart comparator • Enable ints again ■ Restore original ints ;Look at tone pwm ;Look at ring pwm • Just look at pwm bit ;Skip next part if no tone or ring ; output ; If we are generating Dial Tone now, then get the current ; value from the selected tone table, and send it to the PCAl ; so that proper DTMF frequency is generated on CEXl (pl.4). • Initialize pointer ;Get data from table • Reset index, this is end of table ;So index will be right • Read first entry ;Put data in tone pwm ;Put data into ring pwm only tone or ; ring pwm is running at any given ; time inc dptr "Point to next table entry for next ; time ;Reset the module 0 flag -.Disable ints • Reload low match and suspend ; comparator ;Get last page ■ Point to next page • Load high match and restart comparator • Enable ints again Snoge ************************************************* I/O Support Routines ; Pop rO ; Restore interrupt status ; Save interrupt status ; No interrupts ; Push rO ; A ; Low address byte for I/O chip pxl pins ; Pop rO ; Restore interrupt status ; Data from px2_temp to px2 ; Save interrupt status ; No interruptions ; Push rO ; B ; Keep the input bits high ; Low address for I/O chip pxl latch ; Restore rO ; Restore interrupt status ; Data from px2_temp to px2 ; Save interrupt status ; No interruptions ; Push rO ; B setb al mov a,lamps_temp anl a,#11110000b rl a rl a rl a rl a mov r0,#00h ; Low address for I/O chip pxl latch movx @r0,a setb aO setb al pop 0 ; Restore rO pop ace pop ie ; Restore interrupt status ret read_px2: push ie ; Save interrupt status clr ea ; No interrupts clr io_select push ace push 0 ; Push rO clr aO ; C setb al mov r0,#0h ; Low address for I/O chip px2 pins movx a,@rO anl a,#11110000b ; Mask the output bits anl px2_temp,#00001111b ; Mask the input bits in px2_temp orl px2jemp,a ; Combine inputs/outputs into one byte setb aO setb al pop 0 ; Pop rO pop ace pop ie ; Restore interrupt status ret readJo_m_a: ; Data from px2_temp to px2 push ie ; Save interrupt status clr ea ; No interruptions setb io_select ; push ace push 0 ; Push rO clr aO ; b clr al mov r0,#00h ; Low address for I/O chip pxl latch movx a,@rO setb aO setb al clr io_select pop 0 ; Restore rO ; pop ace pop ie ; Restore interrupt status ret * write io m b: ; Data from pxl Jemp to pxl ; Save interrupt status ; No interruptions ; Push rO ; B ; Low address for I/O chip pxl latch ; Restore rO ; Restore interrupt status ; Data from px2jemp to px2 ; Save interrupt status ; No interruptions ; Push rO ; B ; Low address for I/O chip pxl latch ; Restore rO ; Restore interrupt status ; Save interrupt status ; No interrupts ; Push rO ; Control ; Low address for I/O chip px2 pins ■ Pop rO ; Restore interrupt status ; Save interrupt status ; No interrupts ; Push rO ; Control ; Low address for I/O chip px2 pins ; Pop rO ; Restore interrupt status ************************************************* Support Routines ** * ** * * ** *** * *** * * * *** * ** **** *** * * * **** * ****** * ** ; Generic messages between the TRU and Celjack can be save to aid ; in debugging. This message buffer is from 90h to FFh. clr nsg: ; Clear copy of handset's LCD display from ram display buffer . clr dsp: push ; Save Rl mov rl,#dspbuf_start ; Point to message buffer start mov dsp_ptr,rl ; Save buffer start clr_dspl: mov @rl,#0ffh ; Fill with FFh mask inc rl ; Point to next location cjne rl,#dspbuf_end,clr_dspl ; Til end of display buffer pop 1 ; Restore Rl ret ; Some TRUs must save the handset LCD display info, in a local display ; buffer. save_dsp: push ; Save Rl ; Get current pointer ; Brif message buffer is not full yet ; Repoint to start when full ; Save msg in buffer ; Advance pointer ; Update pointer for next time ; Restore Rl

Claims: WHAT WE CLAIM IS : CLAIM 1. In a cellular, or cellular-like, transceiver apparatus comprising a cellular, or cellular-like, tran¬ sceiver, a cellular, or cellular-like, interface unit, and a standard, land telephone-like set coupled to said cellular, or cellular-like, transceiver, said interface unit converting DTMF or pulse-type of dialing signals into digital format for sending to said cellular, or cellular-like, transceiver, whereby the dialed number made on the land-type of telephone may be used to call a number over the cellular, or cellular- like, system, the improvement comprising: auto-diagnostic means for monitoring and reporting the proper functioning of said cellular, or cellular-like, transceiver and said cellular,, or cellular-like, interface unit; means for alternately coupling said auto-diagnostic means to said cellular, , or cellular-like, interface unit; said means for alternately coupling said auto-diagnostic means comprising means for uncoupling the connection of said standard, land telephone-like set from said cellular, or cellular-like, interface unit when said auto-diagnostic means is coupled to said cellular, , or cellular-like, interface unit; said auto-diagnostic means comprising means for simu¬ lating the functions performed by said standard, land telephone-like set for generating in said cellular, , or cellular-like, interface unit respective, corresponding responses in said cellular, or cellular-like, interface unit, in order to determine if said cellular, or cellular-like, interface unit is operating correctly. CLAIM 2. The cellular-transceiver apparatus according to claim 1, wherein said means for simulating the functions performed by said standard, land telephone-like set com¬ prises means for generating an off-hook signal to said cellular, , or cellular-like, interface unit. CLAIM 3. The cellular-transceiver apparatus according to claim 2, wherein said auto-diagnostic means comprises means for detecting the presence of a dial-tone signal generated from said cellular, , or cellular-like, interface unit in response to said generation of said off-hook signal. CLAIM 4. The cellular-transceiver apparatus according to claim 1, wherein said means for simulating the functions performed by said standard, land telephone-like set com¬ prises means for generating a DTMF signal and sending the signal to said cellular, or cellular-like, interface unit. CLAIM 5. The cellular-transceiver apparatus according to claim 4, wherein said auto-diagnostic means comprises means for detecting the DTMF signal output by said cellular, or cellular-like, interface unit in response to the DTMF signal generated by said means for generating a DTMF signal. CLAIM 6. The cellular-transceiver apparatus according to claim 1, wherein said means for simulating the functions performed by said standard, land telephone-like set com¬ prises means for generating an on-hook signal to said cellu¬ lar, or cellular-like, interface unit. CLAIM 7. The cellular-transceiver apparatus according to claim 6, wherein said auto-diagnostic means comprises means for simulating the presence of an incoming telephone call to said transceiver, in order to cause said cellular, or cellu¬ lar-like, interface unit to actuate its ring generator; said auto-diagnostic means comprising means for detecting the ring-signal produced thereby. CLAIM 8. The cellular-transceiver apparatus according to claim 7, wherein said means for simulating the functions performed by said standard, land telephone-like set com¬ prises means for generating an off-hook signal to said cellular, or cellular-like, interface unit during the time that said cellular, or cellular-like, interface unit is generating its ring-signal, in order to determine that the cellular, or cellular-like, interface unit properly discon¬ nects the ring-signal upon the answering of an incoming telephone call. CLAIM 9. The cellular-transceiver apparatus according to claim 1, wherein said auto-diagnostic means comprises means for for generating an outgoing telephone call through said cellular, or cellular-like, interface unit and said tran¬ sceiver, through the cellular, or cellular-like, telephone system, and back to said cellular, or cellular-like, tran¬ sceiver; said auto-diagnostic means further comprising means for detecting the generation of a busy-signal by said cellular, or cellular-like, transceiver in response to said telephone call; said means for generating an outgoing tele¬ phone call calling the telephone number which has been as¬ signed to said transceiver with which it is operatively coupled. CLAIM 10. A testing apparatus for testing the proper operation of a cellular, or cellular-like, interface unit, which cellular, or cellular-like, interface unit is capable of being coupled to a land-type telephone or telephone-like instrument, said cellular, or cellular-like, interface unit capable of converting DTMF signals or pulse-type dialing signals from a land-type telephone instrument coupled thereto into digital data format for sending the digital data to a cellular, or cellular-like transceiver, said testing apparatus comprising: diagnostic means for monitoring and reporting the proper functioning of said cellular, or cellular-like, interface unit. CLAIM 11. The testing apparatus according to claim 10, wherein said testing apparatus further comprises means for alternately coupling said diagnostic means to said cellular, or cellular-like, interface unit; said diagnostic means comprising means for simulating the functions performed by a standard, land telephone-like instrument for generating in said cellular, or cellular-like, interface unit respective, corresponding responses in said cellular, or cellular-like, interface unit, in order to determine if said cellular, or cellular-like, interface unit is operating correctly. CLAIM 12. The testing apparatus according to claim 11, *< wherein said means for alternately coupling said diagnostic means comprises means capable of uncoupling the connection of a standard, land telephone-like instrument from said cellular, or cellular-like, interface unit when said diag¬ nostic means is coupled to said cellular, or cellular- like, interface unit. CLAIM 13. The testing apparatus according to claim 11, wherein said means for simulating the functions performed by said standard, land telephone-like instrument comprises means for generating an off-hook signal to said cellular, or cellular-like, interface unit. CLAIM 14. The testing apparatus according to claim to claim 13, wherein said diagnostic means comprises means for detecting the presence of a dial-tone signal generated from said cellular, or cellular-like, interface unit in response to said generation of said off-hook signal. CLAIM 15. The testing apparatus according to claim 11, wherein said means for simulating the functions performed by said standard land telephone-like instrument comprises means for generating a DTMF signal and sending the signal to said cellular, or cellular-like, interface unit. CLAIM 16. The testing apparatus according to claim 15, wherein said diagnostic means comprises means for detecting the DTMF signal output by said cellular, or cellular-like, interface unit in response to the DTMF signal generated by said means for generating a DTMF signal. CLAIM 17. The testing apparatus according to claim 15, wherein said means for simulating the functions performed by sai standard, land telephone-like instrument comprises means for generating an on-hook signal to said cellular, or cellular-like, interface unit. CLAIM 18. The testing apparatus according to claim 10, wherein said diagnostic means comprises means for simulating the presence of an incoming telephone call to said tran¬ sceiver in order to cause said cellular, or cellular-like, interface unit to actuate its ring generator; said diagnostic means comprising means for detecting the ring-signal produced thereby. • CLAIM 19. The testing apparatus according to claim 18, wherein said diagnostic means further comprises means for generating an off-hook signal to said cellular, or cellular- like, interface unit during the time that said cellular, or cellular-like, interface unit is generating its ring-signal, in order to determine that the cellular, or cellular-like, interface unit properly disconnects the ring-signal upon the answering of an incoming telephone call. CLAIM 20. The testing apparatus according to claim 10, wherein said diagnostic means comprises means for generating an outgoing telephone call through the cellular, or cellular- like, telephone network, when said cellular, or cellular- like, interface unit is coupled to a transceiver, and back to said cellular, or cellular-like, transceiver, whereby said diagnostic means causes said cellular, or cellular-like, transceiver to make a telephone call to itself; said diagnostic means further comprising means for detecting the generation of a busy-signal by the cellular, or cellular- like, transceiver in response to said telephone call; said means for generating an outgoing telephone call calling the telephone number which has been assigned to the transceiver coupled to said cellular, or cellular-like, interface unit. CLAIM 21. A method of testing for the proper operation of a cellular, or cellular-like, interface unit by means of a diagnostic unit, which cellular, or cellular-like, interface unit is capable of being coupled to a land-type telephone or telephone-like instrument, said cellular, or cellular-like, interface unit capable of converting DTMF signals or pulse- type dialing signals from a land-type telephone instrument coupled thereto into digital data format for sending the digital data to a cellular, or cellular-like transceiver, said method comprising: (a) monitoring and reporting the functions performed by said cellular, or cellular-like, interface unit. CLAIM 22. The method according to claim 21, wherein said step (a) comprises: (b) alternately coupling said diagnostic unit to said cellular, or cellular-like, interface unit; (c) simulating the functions performed by a standard, land telephone-like instrument for generating in said cellular, or cellular-like, interface unit respective, corresponding responses in said cellular, or cellular-like, interface unit, in order to determine if said cellular, or cellular-like, interface unit is operating correctly. CLAIM 23. The method according to claim 22, wherein said step (b) comprises uncoupling the connection of a standard, land telephone-like instrument from said cellular, or cellular-like, interface unit when said diagnostic unit is coupled to said cellular, or cellular-like, interface unit. CLAIM 24. The method according to claim 22, wherein said step (c) comprises generating an off-hook signal to said cellular, or cellular-like, interface unit. CLAIM 25. The method according to claim to claim 24, further comprising detecting the presence of a dial-tone signal generated from said cellular, or cellular-like, interface unit in response to said generation of said off-hook signal. CLAIM 26. The method according to claim 22, wherein said step (c) comprises generating a DTMF signal and sending the signal cellular, or cellular-like, interface unit. CLAIM 27. The method according to claim 26, further com¬ prising detecting the DTMF signal output by said cellular, or cellular-like, interface unit in response to the DTMF signal generated. CLAIM 28. The method according to claim 26, wherein said step (c) comprises generating an on-hook signal to said cellular, or cellular-like, interface unit. CLAIM 29. The method according to claim 21, wherein said step (a) comprises simulating the presence of an incoming telephone call to said transceiver in order to cause said cellular, or cellular-like, interface unit to actuate its ring generator; and for detecting the ring-signal produced thereby . CLAIM 30. The method according to claim 29, wherein said step (a) further comprises generating an off-hook signal to said cellular, or cellular-like, interface unit during the time that said cellular, or cellular-like, interface unit is generating its ring-signal, in order to determine that the cellular, or cellular-like, interface unit properly discon¬ nects the ring-signal upon the answering of an incoming telephone call. CLAIM 31. The method according to claim 21, wherein said step (a) comprises generating an outgoing telephone call through the cellular, or cellular-like, telephone network, when said cellular, or cellular-like, interface unit is coupled to a transceiver, and back to said cellular, or cellular-like, transceiver; said step of generating an outgoing telephone call causing said cellular, or cellular- like, transceiver to make a telephone call to itself; and further comprising detecting the generation of a busy-signal by the cellular, or cellular-like, transceiver in response to said telephone call. CLAIM 32. In a radio-transceiver apparatus comprising a radio transceiver, an interface unit, and a communications device coupled to said radio transceiver, said interface unit operatively coupling said communications device to said radio transceiver for either calling out or receiving calls through said radio transceiver, the improvement comprising: auto-diagnostic means for monitoring and reporting the proper functioning of said radio transceiver and said interface unit; means for alternately coupling said auto-diagnostic means to said interface unit; said means for alternately coupling said auto-diagnostic means comprising means for uncoupling the connection of said communications device from said interface unit when said auto-diagnostic means is coupled to said interface unit; said auto-diagnostic means comprising means for simu¬ lating the functions performed by said communications device for generating in said interface unit respective, corre¬ sponding responses in said interface unit, in order to determine if said interface unit is operating correctly. CLAIM 33. The cellular-transceiver apparatus according to claim 32, wherein said means for simulating the functions performed by said communications device comprises means for generating an off-hook signal to said interface unit. CLAIM 34. The cellular-transceiver apparatus according to claim 33, wherein said auto-diagnostic means comprises means for detecting the presence of a dial-tone signal generated from said interface unit in response to said generation of said off-hook signal. CLAIM 35. The cellular-transceiver apparatus according to claim 32, wherein said means for simulating the functions performed by said communications device comprises means for generating a DTMF signal and sending the signal to said interface unit. CLAIM 36. The cellular-transceiver apparatus according to claim 35, wherein said auto-diagnostic means comprises means for detecting the DTMF signal output by said interface unit in response to the DTMF signal generated by said means for generating a DTMF signal. CLAIM 37. The cellular-transceiver apparatus according to claim 32, wherein said auto-diagnostic means comprises means for simulating the presence of an incoming telephone call to said transceiver, in order to cause said interface unit to actuate its ring generator; said auto-diagnostic means comprising means for detecting the ring-signal produced thereby. CLAIM 38. The cellular-transceiver apparatus according to claim 32, wherein said auto-diagnostic means comprises means for generating an outgoing telephone call through said interface unit and said transceiver, through the radio telephone system with which said transceiver is associated, and back to said transceiver; said auto-diagnostic means further comprising means for detecting the generation of a busy-signal by said transceiver in response to said telephone call; said means for generating an outgoing telephone call calling the telephone number which has been assigned to said transceiver with which it is operatively coupled. CLAIM 39. A testing apparatus for testing the proper operation of an interface unit, which interface unit is capable of being coupled to a communications device for operatively coupling the communications device to a radio transceiver for either calling out or receiving calls through the radio transceiver, comprising: diagnostic means for monitoring and reporting the proper functioning of said interface unit. CLAIM 40. The testing apparatus according to claim 39, wherein said testing apparatus further comprises means for alternately coupling said diagnostic means to said interface unit; said diagnostic means comprising means for simulating the functions performed by a communications device for generating in said interface unit respective, corresponding responses in said interface unit, in order to determine if said interface unit is operating correctly. CLAIM 41. A method of testing for the proper operation of an interface unit by means of a diagnostic unit, which interface unit is capable of being coupled between a commu¬ nications device and radio transceiver, so that the communi¬ cations • device may make outgoing calls or receive incoming calls by means of the radio transceiver, said method com- prising : (a) monitoring and reporting the functions performed by said interface unit. CLAIM 42. The method according to claim 41, wherein said step (a) comprises: (b) alternately coupling said diagnostic unit to said interface unit; (c) simulating the functions performed by a communica¬ tions device for generating in said interface unit respec¬ tive, corresponding responses in said interface unit, in order to determine if said interface unit is operating correctly. CLAIM 43. The method according to claim 42, wherein said step (b) comprises uncoupling the connection of a communi¬ cations device from said interface unit when said diagnostic unit is coupled to said interface unit.

Inventors: ORTIZ LUIS R, TORRES ALEXIS, ORTIZ, LUIS, R., TORRES, ALEXIS
Applicants: TELULAR INT INC, TELULAR INTERNATIONAL, INC.
Application year: 1994
Main classification: H04M1
IPC codes: H04B7, H04B17, H04M1, H04M3, H04M11, H04W24, H04W84