DTMF Decoder

The main system is the user interface and control system. The phone line was chosen as the method of interfacing because it has distinct advantages over other systems in communicating information from a distance. The next image serves as a block diagram for not only the remote access interface but the overall system as a whole.

BD_System.JPG

System flow and activation begins at the top left of the block diagram with the answering machine picking up a call from the user dialing in remotely. The answering machine controls the connection and disconnection of the phone line to the DTMF decoder automatically.

The user presses the keys on their touch tone enabled telephone in a specific sequence. The DTMF decoder circuit is connected to the phone line and it interprets the DTMF signals on the line and forwards them to the main microcontroller in the form of a four bit binary number. The controller running the main firmware determines if the correct input sequence was entered by the user and interfaces directly with the individual subsystems. The subsystems also have a local activation capability such as a pushbutton switch to control its functionality.

The subsystems are independent of one another and can operate in parallel if an activation signal is given from either the controller or from the local activation switches.

The RS-232 interface with the computer and the decoded DTMF display are both examples of future work for the system and are not implemented on the prototype. The open air microphone also shown in the block diagram has been removed for lack of relevance and because of the noise it introduces on the line. The flow of the microcontroller software is shown below.

DecoderSoftwareFlow.JPG

When a user dials into the system remotely they are in the user interface portion of the system flow. DTMF signals are decoded and forwarded to the microcomputer processor. The microprocessor stores the last four signals received in memory. If more than four button presses are detected the microprocessor begins again writing over the first button press stored in memory. For example, if the sequence entered by the user was:

1, 7, 5, 3, 6, 2

The microprocessor would see this sequence in memory as:

6, 2, 5, 3

This is because of the previously described wrap around effect built into the program software. When the user has entered what they believe to be the correct code the pound key (#) is pressed on the phone pad and the microprocessor looks at the code it has stored in memory as described above. The received code is then compared against a firmware defined code. If the code does not match, the software begins counting the failed access attempts.

If the failed attempt count reaches three, the microprocessor enters a three minute lockdown mode where further remote access to the system is denied. This lockdown mode is designed to discourage unauthorized access to the system. If the user believes that they have pressed a wrong key, they can clear the code stored in memory by pressing the star (*) key with no penalty. If the pound button is pressed and an incorrect code was entered, there is no way for the user to delete the failed attempt, except by hanging up and redialing. If the system is in lockdown mode when a person attempts to dial in the system, it will not respond until the three minute lockdown has finished running its course.

Once the correct code sequence has been entered and confirmed correct by the microprocessor, the user is granted access to activate any number of the desired subsystems. The subsystems are numbered 0-9, *, and #.The subsystem to activate is chosen by DTMF decoding just as the code was entered. At this point in the program any key press will activate a subsystem and a subsystem can be activated multiple times if the user desires. As the subsystems are self contained, they only require a pulse to begin their respective tasks.

To disconnect from the system, the user simply hangs up the phone that they are calling from. The subsystems will finish their jobs with no need for the user to stay on the line.

DTMF Component Sizing & Specifications

The DTMF decoder chosen for this project is a CM8870 made by California Micro Devices (CMD). This chip is used in many pre-constructed systems that have little or no functionality greater than that provided by the chip itself. The CM8870 requires a small external component count and is more reliable, easier to use and implement, than software defined DTMF decoders. Although now discontinued by CMD the CM8870 has had many pin for pin knock off chips created to fill its wake and are available for as little as fifty cents. At the time of this writing the original chip is still available through various online and after market distributors for a cost of approximately $3.

The CM8870 is a CMOS device and has a 5 Volt binary output for easy interfacing to a microprocessor. This chip is capable of decoding all sixteen DTMF tones, including A, B, C, and D which are more commonly used in European countries. It has low power consumption and an on chip amplifier for weak inbound DTMF tones. The greatest boon to using this chip is the adjustable acquisition and release times of decoded DTMF signals. This allows the chip to be used with a variety of microprocessors and is ideal for future upgrades. As this is an after market product ten have been purchased for testing and future implementation. They are also available for use in the case that replacements are required.

By using a band-split filter, the signal is broken into two sine wave components. The peaks of each sine wave are counted over some known time frame. This will tell the user the period of each sine wave. By knowing the period, users can know the operating frequency of each sine wave. Once the frequencies are calculated, they are compared against valid DTMF frequency ranges. The next figure shows the valid frequency combinations for DTMF signals.

DTMFtable.JPG

If a valid frequency is found to correspond to the row and column of a DMTF tone, a binary output is placed on the output of the CM8870. A control line is driven high on the chip to indicate that a valid code has been decoded and is present on the four bit binary port. This decoded DTMF tone will remain present on the output port until the CM8870 receives an enable signal from the microprocessor controlling circuitry. At this point, the CM8870 will start the DTMF decoding process over. A table listing the binary output for a decoded DTMF signal is given below in the next image.

DTMFdecoded.JPG

Microprocessor Specifications

The microprocessor chosen for this project is the ATtiny2313 made by Atmel as a part of their AVR line of products. The Atmel line of AVRs was chosen based on several factors. These chips can be programmed in Assembly, C, or C++ languages. The majority of development environments and compilers for this line of processor are open source and free. The Atmel processors are easy to learn to use and are cheaper to get started with then PICs or Basic STAMP modules.

The chip burning hardware can be easily assembled, or a burner can be purchased for as low as $23. All Atmel AVRs use the same 6 and 10 pin compatible programming lines and can be programmed with the same hardware. Software developed for one can easily be ported over to another, particularly when coded in C. Finally the Atmel chips are generally cheaper and boast higher functionality than their nearest competitors. All of this helps to meet the modularity requirements of the system defined in the specifications section given above.

The ATtiny2313 was chosen from among all the AVRs because it gave more functionality then required for the prototype. With its eighteen digital I/O pins, on chip timer, oscillator, 2 kb Flash memory, and low power consumption it is the ideal chip of choice. It has also been used in several other projects by me with a high degree of success and reliability. The pinout of this microprocessor is shown below in the next image.

Tiny2313.JPG

The ATtiny2313 runs the program as described above and the final schematic used to interface it with the CM8870 can be seen in the figure below. Also of note in the following schematic is the audio isolation circuitry used to connect the phone line to the CM8870.

A typical phone line uses rapidly changing high voltages for signals. This allows information to be transmitted a great distance with little signal loss. The drawback is that the voltages used on the phone line are above the maximum operating conditions specified on my circuit’s datasheets. To overcome this problem an audio-isolation transformer and several diodes along with a simple resistive/capacitive network is used to rectify the phones high voltage signal down to levels that are usable by the rest of the DTMF decoder circuitry.

DecoderSchematic.JPG

RHA Implementation Details

The remote home access system was prototyped and functional in July of 2007. Since then the initial system has changed to interface better with the ATtiny2313 microprocessor and isolation from the phone line was added to protect the circuit. The isolation circuit also acted as a filter for much of the noise that was initially present on the system. A wall phone jack was dissected and cut down to the bare minimum size and shape so that a standard RJ-11 phone plug could be easily connected to the circuit. The prototype was soldered together on standard 2.75 mm proto-board using point to point soldering. The inside of the decoder can be seen in the following two figures.

DecoderBox.JPG

DTMF Decoder in it's box

DecoderCircuitry.JPG

Underside of the DTMF decoder

The entire unit was placed inside of a RadioShack project box measuring 50 x 100 mm. A hole was cut to access the RJ-11 plug and a size K coaxial DC power jack was added to the side of the box. The software named Phone.asm was successfully tested with this module and is included as the first section on code at the end of the appendix. The completed unit can be seen below.

Decoder.JPG

Testing was initially performed with a direct phone tap connection. The system was then hooked up to the answering machines RJ-11 output port for the remainder of testing. Decoded DTMF binary output was observed on LEDs hooked up to the ATtiny2313 microprocessors output port. Initial tones were generated using the phone that the system had a direct connection to. Once the system was hooked up to the answering machine, testing was done by calling the home line from a cell phone and letting the system operate as before described.

DTMF signals were reliably decoded and would stay latched in the system for the programmed time frame. When the system was tested by bypassing the audio isolation circuitry rapid and frequent faults were detected by the DTMF decoder. The reliability of decoding also went down. Software debouncing was tested & improvements were observed, but not significantly. The audio isolation was reattached and the circuit has worked since then.

The prototype was designed to drive LEDs as simulated subsystems, and to occupy as little space as possible. As a result, there was not enough room inside the initial project box to add screw terminals for making connections to the outside world or to the subsystems. Smaller components on a properly designed Printed Circuit Board (PCB) will allow for such connectors to be added in the future.

Additional testing was performed using a laptop to generate DTMF tones. The circuit failed to recognize any tones and it is believed that the program written on the laptop was not generating the tones correctly. This was confirmed by trying to use the laptop’s DTMF tones to dial a local phone, which it was unable to do.

For demonstration, the circuit was interfaced to a cell phone using a phone jack and a cannibalized cell phone headset. The circuit performs correctly but is much more susceptible to noise when it is connected to the cell phone, than it is when it is connected the home line. It is believed that this is due to the addition of the open air microphone on the cell, as well as the cell phone's poor reception quality. The next figure shows the DTMF decoder interfaced with a cell phone.

Decoder_Demo.JPG

The faults in the circuit due to driving it from a cell phone line are significant enough that the main program was removed from the ATtiny2313 and replaced with a port forwarding program. This will be used during the demonstration to illustrate correctly decoded DTMF tones.

The code for this module is currently being rewritten in C++ to enable easy porting over to a larger microprocessor. The current version of this systems software is named HomeAutomation.c and is included at the end of the software section in the appendix.

The test results met the required design criteria for a proof of concept system. A PCB with additional signaling circuitry as well as ample space for external connectors can now be produced with confidence in the performance of the resulting system.

While the system is intended to help my wife around the house, remote activation of the system is also possible. The drawback to remotely accessing the system is that the user does not receive any feedback to indicate that the system performed correctly. Future improvements to the system will include a method of user feedback most likely in the form of web accessible security cameras.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License