Please title this page. (No286p66.htm)

Although the IBM AT keyboard port is the primary means of user input for PCs, you can also use it as a power supply and communications link for small low-power computer peripherals. In this two-part article, we will present a system model around which such peripherals can be designed. For illustration, the application we'll design is a Caller ID peripheral device huilt around Motorola's MC68HC(7)05P9 microcontroller This device is a 68HCOS-based CPU, with two KB of EPROM/OTP, 128 hytes of RAM, a 16 bit Timer System, 16-hit bidirectional I/O, and other features. (For more information on the MC68HC(7)05P9, see http://mot-sps.com/csic/selguide/ hcOS/705p9.htm.) The application is capable of receiving Caller ID transmissions and displaying the receivecl data on an AT-compatible computer. This month, we'll focus on the Caller ID protocol and hardware-design issues. In the next installment, we'll zero in on the software. The application consists of two parts:

Coller ID Protocol

Caller ID is a service that transmits information (such as a telephone number and name) about a calling party to a called subscriber. Caller ID-capable equipment at the subscriber's premises capture.s, processes, and displays the data. Most Caller ID subscribers are residential customer.s who use the service to screen incoming calls. Caller ID is also used by commercial subscribers to automate the retrieval of customer records from inhouse databases. The widespread acceptance of this service in both the residential ancl commercial subscriber markets has led to the development of many different types of Caller ID devices, including Caller ID adjunct boxes, computer peripherals, and telephones with Caller ID functionality.

There are a number of requirements imposed on a service provider that govern Caller ID transmissions. The first of these is that the transmission of Caller ID data is permitted whether the equipment at the customer's site is in the on-hook or off-hook state. This requires the service provider be able to detect the state of a subscriber's equipment and adjust the transmission of data accordingly. Since transmitting data while the customer's equipment is in the off-hook state requires the interruption of an ongoing call, the issues that must be addressed for transmitting to equipment in the two states are different. This has led to the development of a signaling and transmission protocol for the off-hook state that is more sophisticated than the protocol for the on-hook state. As a result devices capable of receiving Caller ID data while the subscriber's telephone is off-hook costs more than on-hook-only devices. Given that on-hook-only devices were offered first (and that it costs more for both the service provider and the subscriber to support the off-hook state), most Caller ID capable equipment in service today only supports the on-hook protocol. For this reason, we'll only address in this article the design of applications that are capable of supporting on-hook protocol.

The transmission of Caller ID information is governed by a set of specifications developed by Bellcore. These requirements, known as the Voicehand Data Transmission Interface (VDTI), define the encoding, timing, and formatting of Caller ID data, and the electrical characteristics of analog signals used to transmit that data. The VDTI allows data transmissions for the on-hook case to occur with o without power ringing. The more common of the two cases is when the transmission of data is preceded by a power ring. The VDTI specifies that data transmission occur in the silent interval between the first and second power rings of a call. A power ring need not consist of a single continuous tone. Some service providers signal their subscribers with a series of short tones instead of one continuous tone. The burst of tones occurs within the period of time normally allotted for a single tone, thus replacing the single power ring. The burst is then followed by a silent interval and another burst. This type of signaling is known as; "distinctive ringing." The VDTI allows service providers that use distinctive ring ing patterns to transmit Caller ID data as long as the silent interval is of a minimum length. If a provider's signaling does not meet these specifications, the transmission of Caller ID data is not supported. Figure 2 illustrates the timing specifications that service providers must meet in order to transmit Caller ID data. The VDTI is composed of a messageassembly layer, data-link layer, and physical layer. At a service provider's facility, a block of Caller ID data flows down from the message-assembly layer, through the data-link layer, and finally down to the physical layer where it is converted into a modulated analog signal. As a block travels through the interface, each layer prepends and appends data to the original block until it reaches the physical layer. This process is similar to that used by protocol stacks such as TCP/IP.

The message-assembly layer--the highest level of the interface--specifies a message format for a block of Caller ID. The information contained in the block is determined by the level of service to be provided to subscribers. The data-link layer defines the framing format and error correction methods that are applied to the raw digital bit stream that is transmitted to the subscriber. At the lowest level, Caller ID data is transmitted over telephone lines as a modulated analog signal. The physical layer specifies the signal's modulation and its electrical characteristics.

The Message-Assembly layer

The message-assembly layer segments the data within a Caller ID data packet. The layer defines two formats for packets; the Single Data Message Format (SDMF) and the Multiple Data Message Format (MDMF). The SDMF is the simpler of the two formats and will be discussed first. The message-assembly layer forms an SDMF packet by prepending a two-byte header to a Caller ID data packet. The first byte of the header is the packet's Message Type parameter value. This value alerts a Caller ID device as to the type of information that is contained in the accompanying data block. There are currently three values defined for the Message Type parameter of SDMF packets. A packet with a Message Type value of Ox04 contains the number of a calling party, a value of 0x06 indicates a Message Waiting Indicator packet, and a value of 0x0B has been reserved for future applications. The next byte in the header is the Message Length Parameter. This parameter, as its name suggests, contains the number of bytes of data that remain in a block. Figure 3 shows the structure of an SDMF frame.

The message assembly layer also specifies the arragement of information within the data portion of a frame. The data portion of an SDMF frame consists of ASCII codes arranged in three fields representing the date, time, and number of an incoming call. The date field (which is the first piece of information in the data block) consists of four bytes. The first two bytes are ASCII codes for the digits representing the month, and the other two represent the day. Any months or days that can be represented by a single digit are preceded by a zero. The next four bytes are ASCII codes for digits representing the time. The first two bytes are the ASCII codes for the digits representing the hour, and the remaining two represent the minutes. The value in the hour field are allowed to range from zero to 23. The minutes can range from zero to 59. The remaining ten ASCII codes represent the digits of the telephone number of the incoming call If the incoming call is a local call and lacks an area code, the area code portion of the number field is filled by default with the ASCII code for three zeroes. Figure 4 illustrates the arrangement of information within an SDMF packet.

The message-assembly layer's second format, the MDMF, is more complex and versatile than SDMF. It is capable of delivering more data concerning an incoming call, such as the name of a calling party. Though both formats share some features, such as the Message Type and the Message Length parameters, the structure of the MDMF is more flexible, and it more readily accommodates the development of new provider services.

As with the SDMF. the Message Type parameter is the first byte of an MDMF packet. Since MDMF is designed to provide a wider variety of information than SDMF, there are six Message Type values specified for it instead of the three defined for SDMF. The Message Type value identifying a Caller ID data block is 0x80, 128 decimal. The Message Length parameter, the next byte in the frame, specifies the number of bytes that follow in the data block. After the Message Length parameter, the structure of an MDMF packet differs from that of an SDMF. At this point, the message block is broken up into smaller messages called "parameter messages." Each parameter message is composed of a Parameter Type value, a Parameter Length value, and an accompanying data block that contains a specific type of information, such as the number of an incoming call. Each piece of information that is transmitted in an MDMF packet, such as the time and date, calling number, and the calling name! is packaged within its own parameter message. This encapsulation of data enables a service provider to selectively add or omit information from Caller ID transmissions.

As its name suggests, the Parameter Type value is used to identify the type of data contained in a parameter message. There are currently 17 Parameter Type values defined for MDMF. The values of most interest to Caller ID capable cquipment are 0x01. 0x02. and 0x07, which identify a time and date. number, and name parameter. respectively. The Parameter type is followed by the Parameter Length value, which contains the remaining number of bytes in the parameter message s data block. Figure 5 illustrates the format of a parameter message.

As mentioned earlier, each parameter message contains a specific piece of information, such as the time and date of an incoming call. If a parameter message carries a type of information supported by MDMF, the data within it is represented and arranged the same way as its counterpart in SDMF. A calling party's name (a data type not supported in SDMF) is transmitted as ASCII codes for the letters comprising the name.

The Data-link layer

The data-link layer formats the data to he transmitted into a trame for the next layer helow it--the physical layer. The data-link layer also clefines Caller ID's signaling and error-detection functions. At its lowest level. this layer prepends a start bit and appends a stop bit to each hyte of data that it has received from the message-assemhly layer. The layer also specifies that data hc transmitted LSB first. The layer prepends a preamble sequence and appends a checksum to each frame of data that is transmitted. The preamble serves as the signaling mechanism to alert and condition the customer's equipment for receiving a transmission. The preamble sequence for the on-hook protocol consists of two parts: a Channel Seizure Signal and a Mark Signal. The Channel Seizure Signal is transmitted first and consists of 300 bits of alternating 0s and 1s. The sequence begins with a 0 and ends with a 1. The Seizure Signal is followed by the Mark Signal, which consists of 180 marks or high bits. The checksum that is appended to each frame serves as a transmission's error-detection mechanism. Though the data-link layer provides for error detection, no provision is made for error correction. The on-hook protocol does not provide a mechanism for a subscriber's Caller ID device to request a retransmission of data from the central office. Therefore it will discard a frame if an error is detected. Transmission errors are detected by calculating a checksum value as data bytes are received, then comparing the value to the checksum value sent in transmission. If the two values are identical, there is a high probability that the transmission is error free. The detection of an error is not absolute because the Caller IDs error-detection algorithm is not capable of detecting every possible transmission error. After being processed by the data-link layer a Caller ID frame appears as in Figure 6.

The Physical Layer

The physical layer defines the electrical characteristics of the analog signal used in the transmission of Caller ID data frames over a telephone network's lines. The physical layer also defines the method of modulating the signal. The physical layer specifications require that data be transmitted to a subscriber's equipment as an asynchronous serial binary bit stream at a rate of 1200 baud +/-1 percent. Data is actually delivered to a subscriber's equipment by means of a binary frequency-shift-keyed (BASK) modulated analog signal. During a transmission a logic 1 is coded by a frequency of 1200Hz +/-1 percent, while a logic 0 is coded by 2200 Hz +/-1 percent.

This concludes the discussion of the structure and theory of the Caller ID protocol. At this point, we'll turn our attention to applying this information in the development of an application based on an MC68HC(7)05P9 microcontroller.

Keyboard Caller ID Device Hardware Design Overview

The Keyboard Caller ID device's hardware design is divided into two functional blocks:

The Caller ID data-acquisition block serves as the applications interface to the telephone line. This block receives the Caller ID analog signal, demodulates it, and converts it into a digital stream. The design of this block is centered on Motorola's MC1455447 Calling Line Identification Receiver with Ring Detector device (which, when used with a few passive components, is capable of performing these functions). The digital stream produced by the MC145447 is passed to the keyboard interface block, which is primarily implemented with a Motorola MC68HC705P9 microcontroller. The MC68HC705P9 parses the stream into individual bytes and converts the data into IBM AT keyboard scan codes for transmission to the host. These scan codes are sent to the host through its keyboard interface. The host computer interprets the scan codes as a series of keystrokes that are processed by CALLERID.EXE. This block also provides the device's interface to the host computer's keyboard interface by emulating the signals used in keyboard-to-keyboard interface transactions and the IBM AT keyboard interface protocol.

Until Next Month

We will continue our discussion of the application's hardware design in the next installment by examining each of these blocks in detail. We'll also present both the Windows 95 software and firmware that make the system work.

**Figure 2:** Timing specifications for data transmission with power ringing.
0.2-3 seconds	0.5-1.5 seconds	Variable	>=200ms	1.8-3 seconds
	Silent Interval Between Power Rings
Continuous Power Ring or Distinctive Ring Pattern		Data Transmission		Continuous Power Ring or Distinctive Ring Pattern

**Figure 3:** SDMF and MDMF frame structure
Message Type Parameter	Message Length Parameter	Caller ID Data

**Figure 4:** SDMF data-block format.
Date	Time	Ten Digit Phone Number

**Figure 5:** Parameter message structure.
Parameter Type Byte	Parameter Length Byte	Caller ID Specific Information