Circuit Cellar INK #83 June 1997
By Dave Ryan & Asher Hazanchuk
On- and Off-Hook
Caller ID Using DSP
Phone companies have already made on-hook caller ID popular. But, you can also quite easily gain this feature off-hook. After reviewing caller ID basics, Dave and Asher show us how to implement it using DSP.
aller Identification, (caller ID or CID), is an added feature of the telephone system that visually indicates who is calling. The display, usually a custom LCD with 2-4 lines of information, might look like :
08 :16AM 8/18 Call#14083708504 Dave Ryan
Before picking up the phone, you can identify the caller. Unwanted calls can therefore be filtered out.
Two primary messaging formats are supported. SDMF (single data message format) displays the date, time, and phone number of the calling party. In addition to displaying these features, MDMF (multiple data message format) gives the caller’s name as it appears in the telephone book. This information arrives via two methods off delivery – on- or off-hook.
On-hook delivery transmits information between the first and the second rings of the incoming call. This method is widely implemented in analog systems and is commercially available.
Off-hook delivery, is also called SCWID (spontaneous call waiting with caller ID) or CIDCW (caller ID with call waiting). When a third party tries to connect with two parties already engaged with each other, information is only transmitted if an acknowledgment is received from the party to be interrupted. This method is not commercially available.
In addition to the various call-waiting signals transmitted from the SPCS (stored program control system), a special CAS (customer premises equipment alerting signal) is also sent. The basic data is transmitted using FSK (continuous phase binary frequency shift keying).
This fairly simple system only requires circuitry to detect the ringing current, demodulate the FSK signal, and display the resulting data.
Figure 1 shows the delivery of FSK data sandwiched between the first and second rings. The larger amplitude, lower frequency waveforms at the beginning and end of CAP TIM BUF (Captured Time Buffer) are the ringing pulses.
FILT TIME1 (Filtered Time 1) shows the ringing pulses in greater detail. The smaller amplitude, higher frequency waveform is the FSK data.
A somewhat idealized simulation of the data is shown in Figure 2a.
The data alternates between 1, 0, 1, and 0. The power spectral density plot shows this signal’s frequency content in the frequency domain.
Of course, real-world data is never as clean idealized situation. Figure 2b shows actual received data.
It’s easy to see that the amplitudes of the high and low-frequency segments are quite different. In addition, noise is superimposed on the signal, most noticeably on the peaks and troughs.
SDMF AND MDMF
Although SDMF displays only the date, time, and phone number, MDMF give the caller’s name as well. In fact, via MDMF, any ASCII data may be transmitted.
Figure 3 shows a simplified overview of the MDMF. The channel seizure is a series of alterning 1s and 0s that are only supplied in the on-hook case. Off-hook as, data transmission starts with the mark signal, which is a series of 1s.
Parameter words are not limited to one message. There may be many parameter messages, each consisting of a parameter type, length, and word.
Just to complicate matters, optional mark signals may be sent between frames. At the end of every transmission is a checksum we describe in detail later. Notice that the parameter length can vary.
Figure 4 illustrates an on-hook solution. An FSK band-pass filter filters signals, and the FSK demodulator converts the analog signal into binary data.
The SDMF/MDMF section removes the start and stop bits and determines the messaging format. Data is stored in SRAM or displayed on the LCD.
The display is uually a small LCD capable of showing the caller’s date, time, telephone number, and name. It usually has enough memory to store 30-99 calls.
The system is usually battery powered since the time of system operation is generally limited to the time between the first and second ring. Once the call is answered, the system may be put in power-down or standby mode.
WHY DSP ?
Digital signal processing isn’t necessary for on-hook operation. Relatively simple and cost-contained analog solution exist. DSP makes much more sense for off-hook operation.
The difficulty arises in accurately detecting the special CAS tone in the presence of VOX. The chip must avoid inadvertent detection due to the similarity with speech (the Talk Off problem).
This type of system hasn’t been widely implemented in analog solutions primarily because implementing a cost-contained, manufacturable, an robust solution is difficult.
With digital filters, the manufacturing difficulties associated with using critically matched components (e.g., resistors, capacitors, inductors, etc.) are largely avoided. In addition, the solution may now be made adaptive.
Variant, implementations then becomesimply a matter of software upgrades. Of course, there are tradeoffs. A/D conversion must be supported with its ancillary requirements, and so must D/A conversion. However, usually a DSP solution seems superior.
BUILDING A CALLER-ID SYSTEM
The simplest way to get caller ID is to purchase a ready-made evaluation board complete with firmware. However, it’s certainly possible to write the software and buid the hardware.
While building the hardware is reasonably straightforward, software development is a little more complex. You’ll definitely need some firmware development tools (e.g., an emulator, assembler, linker, and debugger).
You can see the system in Figure 5 and 6. The system blocks for it are :
The operation is relatively simple and should be possible anywhere you can subscribe to caller ID.
After power is applied and the reset button pushed, the LCD should display " ready ". Check FSK levels on TP3. The FSK signal’s amplitude should be ~3Vp-p when the FSK data is being received between the first and the second ring. Adjust R31, if necessry. Then, read the LCD for the information.
Figure 7 shows the delivery FSK data in the off-hook mode.
The larger amplitude, lower frequency waveforms at the beginning of CAP TIM BUF are the call-waiting and CAS tones. After a gab, the FSK data is seen.
During this gap, the DSP generats by an ACK. This ACK is not shown, as the DSO was connected to the receive side. FILT TIME shows the call waiting and CAS tone in greater detail.
Comparing the on- and off-hook sections in Figure 4,
we see many differences. In addition to the modules used in on-hook selection, there’s a CAS filter for the high- and low- band portions of the CAS signal, and special CAS detector timing.
Once the CAS tone is detected, an acknowledgment must be returned via a DTMF generator. It’s also necessary to determine if the system is on or off-hook.
Operation in the off-hook mode is not as simple, due to the extra communication involved.
Connect P2 to line 2 or a CIDCW simulator, if available. A simulator is mandatory for additional development, since it involves at least 3 lines.
Again, a scope TP3 to check FSK levels. On line 2, you should hear a call-waiting tone followed by the special CAS tone, ACK is sent, and the SPCS or simulator transmits data.
A software FSK demodulation function is integrated into the DSP as you see in Figure 4. The FSK ferquencies are 1200± 12 and 2200± 22 Hz. After all the protocol and handshaking complete, the data is sent using FSK.
This means there are no phase discontinuities and only two frequencies involved in the FSK signal. The lower frequency 1200 Hz represents a mark (logic 1), and the higher 2200 Hz represents a space (logic 0).
There is no parity or error checking beyond checking a checksum sent at the end of transmission. A start bit (0) and a stop bit (1) added to each 8-bit transmitted word.
The transmission rate is 1200 bps and demodulation is similar to a standard low baud-rate V.21 Bell 103 modem.
After FSK demodulation, the obvious concerns are the data format (see Table 1) and how to decode it.
The message type is 80% (128 or MDMF). Data therefore sent as parameter words where the parameter type and length are binary and the calling name and number are ASCII.
The last word of SMDFs or MDMFs is the checksum. The checksum is the 2’s complement of the modulo 256 sum of the binary representation of all other words in the message including message type and length as well as the parameter type and length.
Remove the start and stop bits. To obtain the 2’s complement, XOR with %FF. If you use Table 1 and hex calculations, the checksum is :
CS = XOR (MOD(sum(80,27,01,08,…,20,52,79,61,6E) ,100),FF)
CS = XOR (MOD(7A8, 100), FF)
CS = XOR (A8,FF)
CS = %57
In a practical application, the calculation is less cumbersome due to the natural modulo 256 nature of a byte.
Since there’s no error correction, the practical application of the checksum is to compare the received checksum with the calculated one. If they don’t agree, then the data is bad and should generally not be displayed.
A software CAS-detection function is integrated into the DSP as shown in Figure 4. It distinguishes the periodic nature of voiced VOX.
CAS frequencies are 2130± 5% Hz and 2750± 5% Hz, making it a DTMF signal. However, the CAS frequencies are quite distinctly beyond the range of normal signaling DTMF frequencies.
The signal is first filtered with CAS high-filter 2750± 5%Hz and also CAS low-filter 2130 ± 5% Hz. The resultant outputs are rectified and tested for minimum amplitude requirements.
If the requirements are met for both frequencies, a timer checks for CAS duration. For detection, the amplitude must constantly exceed minimum requirements for a period longer than a predetermined gating limit.
The CAS-detector ISR services the CAS detection (see Listing). This portion first saves the accumulator and status register, and then, the data is retrieved from the codec.
The codec register ext6 is double buffered, which means that there are really two ext6 registers – ext6-0 and ext6-1. The assembler only reads ext6, which is why we have an apparently redundant load of ext6 to push the data out.
Next, the filters are called. Since the biquad structure is used, the filters are used three times to give a net sixth-order filter.
This process repeats twice-once for each filter. The final portion of the casint ISR restores the accumulator and status register.
The basic biquad structure filters the core. This portion of the code is structured so the tap updates and actual filter calculations are performed within the biquad subroutine.
The first section of this code updates the input taps or delays. The newest sample of data x(n) or data at time n replaces the older x(n), which is saved as x(n-1) or the current sample delayed by 1 (i.e.,n-1). This process repeats for all taps.
Autoincrement performs filter computations (coeff * sample).
Also, a single-cycle MPYA (multiply and accumulate) instruction is used.
The fundamental equation is : y(n) = b0*x(n) + B1*x(n-1)+b2*x(n-2)+a1*y(n-1)+a2*y(n-2) where bi and ai are the filter coefficients and x(n) is the current sample . x(n-1) is the previous sample and x(n-2) is the second previous sample . y(n) is the current output, y(n-1) is the previous output and y(n-2) is the second previous output.
The last code section updates the output taps or delays in time. The newest output y(n) (i.e., output data at time n) replaces the older y(n) and is saved as y(n-1) or the current output delayed by 1 (i.e.,n-1).) . y(n-1) is saved as y(n-2). The process is repeated for all output taps.
Our display is off-the-shelf dot-matrix LCDwith 16 characters x 4 lines. It is logically organized with 2 lines of 32 characters with overrun. It can display any ASCII character and many other characters.
The low-level drivers and controller are mounted on the LCD module. You just need a relatively simple high-level software driver to instruct the LCD which character to display and where to place it.
The DSP bit bangs the ASCII data to the LCD controller using the DSP’s external data bus. The LCD is a relatively slow device, far slower than normal DSP operations, so updating the LCD presents minimal overhead to the DSP. Communication is done via a specialized series of LCD instructions. Once the LCD is initialized, the data is transmitted.
Call progress is sequential. A ring must be detected first. Once the call is established, only one of two events can happen – either a call interrupt occurs or does not occur.
When the SDMF or MDMF data is received, it should be displayed. A state machine takes care of the logical progress of the call. At the end of the call, a disconnection occurs and the entire cycle repeats.
Again, due to the multitasking features common to DSPs, normal call progress, especially on- /off-hook monitoring, system supervision, memory for calls received, and display tasks, can be handled by a single DSP.
For the sake of simplicity, we didn’t add memory storage to this demo. The external bus addressing capability enables this feature to be easily added.
TAKE IT FURTHER
The system described is elemental. Many value-added features are possible (e.g., ring only on certain callers). Such features are easily added as controller functions.
Just let your imagination lead.
Dave Ryan is a systems engineer in Zilog’s data communications. He works on their next-generation 50 MIPS fixed-point processor-class device. You may reach Dave at firstname.lastname@example.org
Asher Hazanchuck works in SDP system engineering and applications at Zilog. He has 15 years of DSP experience in image processing and compression, digital answering machines, cell phones, caller ID, magnetic-stripe readers, and DSP architectures.
J.D. Gibson, Principles od Digital and Analog Communications, MacMillan, New-York, NY 1993.
Bellcore, Technical Reference TR-NWT-000031 and NWT-001188.
Bellcore, Generic Requirements GR-30-CORE.
Bellcore, Special Reports SR-TSV-002578 and SR-TSV-002476.
210 Hacienda Ave.
Campbell, CA 95008-6600
Fax : (408) 370-8056.ftp://ftp.circellar.com/pub/Circuit_Cellar/1997/Issue_83/CIDDSP.ASM [Shift-Click to download the source]
Texas Instruments DSP Caller Id Application Report SPRA462 [Shift-Click to download the pdf file (233 ko)]
email@example.com For any comments
22 août, 2009