AT90LS8535 Digital Answering Machine

Brian Glassmeyer and Eric Melin

Introduction

We were given the task of designing something cool using the AT90LS85835 8-bit microcontroller for our final project in EE476. We decided that an answering machine was interesting because it involved interfacing many analog parts, a reasonable amount of coding, and would leave us with a finished product that actually does something. The answering machine is one of few everyday microcontroller utilities that can be implemented fairly easily and we are really happy with our final product. We also realize that we share a common fear of analog circuitry and felt this would force us to gain working knowledge of this material.


High Level Design -

Our answering machine is designed to:

Record – on phone pickup start recording
Playback – on Button 7 push
Stop Playback – on Button 6 push
Skip Messages – on Button 5 push
Delete Messages – on Button 4 push
Program/Hardware Design -

The main tasks in this design were to record voice and play it back, address the SRAM, and store/read from the SRAM. We achieved recording by using the ADC provided with the AVR microcontroller. We sampled voice at a rate of 6000 samples / second giving us just under voice quality recording.

To make it more realistic, we used a regular telephone as our microphone for input into the ADC. We did not use external phone lines because we did not want to deal with ringing circuitry and there is no phone line access in the EE lab. Through testing, we discovered that the phone operates on a supply from 6V-18V through its red wire. Voice input results in a current modulation in the green wire of the phone cord. By using a 7V supply, we assured that the peak voltage across a 330Ohm resistor on the green wire would be less than our ARef of 4.096V. A lot of debouncing of the hangup receiver is required in software.

Due to budget restraints, we ordered a 128kx8 SRAM from digikey. With the above sampling rate, this allows us to record and save 21.8 seconds (128ksam / 6000sam/sec = 21.8sec).

We needed to order an external counter to address this much memory. To sddress 128k memory locations, we need 17 bits. Our external counter provided the 12 lower bits (only requiring two inputs itself) while we drew the higher 5 bits off the microcontroller. These higher 5 bits give us instant access to 32 different locations. The lower 12 bits can only be incremented or cleared. This means we may waste a maximum of 4096 address bits at the end of a message. This is merely .68 seconds and is hardly an issue.

The 8 bit samples are sent to a DAC through a bus connected also to the microcontroller and the SRAM. The DAC sends its output through an opamp to a simple external speaker. The use of one data bus allows messages to be heard while first being recorded and while being played back. During playback, however, you must remember to set the microcontroller to Hi-Z in order to prevent multiple drivers to the single bus.


Testing Methods -

Realizing the amount of external hardware that would be interacting, we approached our testing in several stages. We wrote individual test codes for every external component (these codes are linked below). Only after we successfully operated and controlled each of these seperately did we combine them into one project. We never fully debugged this code, but only used it as a means to observe the counter and ram were working. We then used simple tests again to verify and correct any wiring issues.

-Our first full test was to input voice and directly output it through the DAC (the SRAM was bypassed on the bus).
-The second test was to record the voice into the SRAM and display the bits on the LEDs.
-We automatically started and stopped recording using the analog comparator on the green wire of the phone cord.
-Combining these we eventually built up our record and play functions.
-The delete function was then added.
-Implemented skip meant we needed memory management using dynamic tables and flags.
-Fool-proofing our design involved finding remote errors that could occur in extreme situations.


Results of the Design -

The answering machine can record up to our full 21 seconds and play it back in clearly understandable output. We can record anywhere from one 21.8 second message to thirtytwo .68 second messages. This leaves an incredible amount of flexibilty for an answering machine where message lengths vary unpredictably.

Multiple messages are recorded one after another. Using the play button will begin with the first message and play until the end of the last message. The delete button will erase all of the messages at once (just like a cassette tape answering machine). The stop button will cease any playing and return to the beginning of the message queue. The skip button will cease the current message and begin playing the next message in the queue.

Cool Extra Features:

Recording will stop automatically if the end of the SRAM is reached preventing circular overwriting.
Play will stop and end of last message preventing extra garbage from being played.
Skip will not play beyond last message.
Play and skip will not work if there are no messages present.
Picking up the phone during play will cease play and start recording at end of message queue.

Software Designed -

Digital Answering Machine
Include file
Test DAC conversion
Test Counter
Test RAM

Answering Machine Schematic (and pics) -

Schematic
Full view of layout
Close-up of surface mount contraption

Spec Sheets and References

ram spec
counter spec
8535 spec
howstuffworks.com

What We Would Do Differently

We would order a counter and RAM that was not surface mount. In order to make these chips usable we made an interesting contraption. We placed the surface mount chip ontop of a wire wrap socket. Soldering short leads to its pins, we folded the wires around the sides of the socket and wire wrapped them to the posts underneath. This results in a DIP-like package shown above in the schematic and pics section.

We would implement the debouncing of the input capture from the beginning to facillitate testing. Getting a clean pickup and hangup of the phone caused many problems.


Extensions

We thought of many extensions to this project if we had more time.
Use serial interface with computer for larger storage capabilities (but we prefer the stand-alone approach not dependant on the computer).
We would have liked to implement more powerful memory management. Currently, our delete is an all-or-nothing format. We would like to be able to individually delete one message at a time. In order to accomplish this, we would need to shift all messages after the deleted message forward to fill the gap. This would be more effective for our short memory than dynamic links.
Interface with the phone network w/ ringer circuitry to answer real phone company calls. An intro message would then be appropriate.
Adding beeps between messages for distiction.


Link: http://instruct1.cit.cornell.edu/courses/e...ts/s1999/melin/