The CCID project was completed in 1994. It would be another 1-2 years before such a product became commercially available (I wish I had royalty rights for it!). Today, many cordless phones include this feature. The project was submitted to the Philips Semiconductor Dream Machine Design Contest in September 1994. It was not awarded placement. Because the following project description was written at that time, some of its content may be outdated.
Cordless Caller ID (CCID) Project Abstract
The Cordless Caller Identification project, herein after referred to as "CCID", combines the convenience of a cordless phone with the information of caller identification. Most cordless phone users who subscribe to the caller ID service do not have more than one caller ID "box". For this reason, the convenience of a cordless phone is easily nullified. If the cordless handset is away from its base unit (and the caller ID box), the user must return to the caller ID box to see who is calling prior to answering the phone. To illustrate this point, assume that the base unit for the cordless phone and the caller ID box are located in the kitchen and the user is working in the garage (or garden, patio, living room, watching TV, bathroom, etc.). When the phone rings and the user wishes to know who is calling, he must return to the kitchen to see the caller ID box, which defeats the purpose of a cordless phone! The user may as well have a wired phone if he wishes to see the caller ID information prior to answering the phone.
The CCID project eliminates this problem by combining an integrated, full featured caller ID system and a cordless telephone. When the phone rings, the caller ID information is decoded and displayed on the base unit and transmitted to the handset unit. This eliminates the need to return to the caller ID "box" prior to answering the cordless phone. Although the prototype CCID system is built into a consumer-grade cordless telephone system (see photos), the CCID system could be manufactured as a cordless telephone add-on accessory.
The prototype CCID system utilizes two 8XC75X microcontrollers - the base unit contains a '752 while the handset unit uses a '750. These two microcontrollers were selected for the following reasons:
Base unit (87C752)
2K ROM, 64 bytes RAM
number of I/O pins
included in evaluation kit
Handset unit (87C750)
low power consumption
open drain I/O pins
1K ROM, 64 bytes RAM
included in evaluation kit
Using these two microcontrollers enables the system to obtain the necessary performance while minimizing software overhead and reducing the number of required external support components. In addition to the microcontrollers, each unit in the CCID system (the base and handset) require only two additional ICs and a few discretes to achieve full functionality (see schematics).
Although caller ID is a well known and mature consumer product, the CCID project is unique for the following reasons:
The system is cordless.
The caller ID FSK demodulation is accomplished in software which eliminates the needs for a dedicated FSK demodulator device, thus reducing cost, pin count, etc.
The system is fully integrated into an existing cordless telephone (see photos).
The complete system is very inexpensive (see BOM).
As mentioned above, the CCID project utilizes specific features found in the selected 8XC75X microcontrollers. Revision 1.5 of the base unit software uses almost all 2K bytes of ROM and all 64 bytes of RAM. The power requirements and small package size of the handset unit make the 87C752 an obvious choice.
Since the caller ID FSK demodulation is done in software, the need for a discrete FSK demodulator and its support components is eliminated. Additionally, the internal pull up resistors found on many of the '750 and '752 ports are used to replace discrete resistors, where practical. The major peripheral components (the 24C04 and LCD display on the base unit and the MAX877 and LCD display on the handset unit) require a minimal number of external components.
The cost of the CCID system has been minimized by eliminating the use of a discrete FSK demodulator (and support hardware) and replacing it with an LM339, which is just about the cheapest IC available. Additional savings is realized by doing the ring signal processing in software. See the BOM and cost estimate for further details.
The need for low power consumption in a battery operated cordless handset is obvious. Power consumption has been minimized by turning-off the display and microprocessor when not in use. Also, the low power version of the LM339, the LP339, was incorporated to reduce the quiescent power consumption of the CCID handset hardware. Large pull up resistors and low power components help reduce the quiescent current drain on the handset battery to less than 100µA. The '752 runs at a "slow" 6MHz to help minimize the power requirements. The "power-down" mode of the '752 is used to further reduce power consumption. Extensive testing has shown no noticeable degradation in battery life.
Raw processor performance is not a major consideration in the CCID system. However, it should be noted that the reliability of the FSK demodulation is a direct function of processor speed. A slower processor would not be able to provide the noise margins which were achieved with the 12MHz 87C752. The first iteration of the CCID prototype was developed with a 6MHz oscillator and the results were found to be unreliable. The ability to simply swap crystals and modify software was most certainly valuable.
Again, a major feature of the CCID system is that the caller ID FSK demodulation is done in software. Another software feature is the commonality of the base unit architecture with that of the handset unit. Much of the core software (FSK demodulation and display drivers) were directly transported from the base unit software. All software code segments, drivers, and subroutines were developed and tested out of the CCID system (see Software Testing and Validation).
There were no accidents in developing the software. Each instruction, code segment, subroutine, memory location, and register was engineered to perform a specific task under various constraints such as execution time, ROM space required, and transportability. Each and every line of assembly code is commented with the number of cycles required for execution and an explanation of its function. The error trapping and error handling functions were developed as if CCID were a medical device.