Car Alert System

(CAS)

Final Design Report

Design Team 2
Chris Dyer
Dan Paul
John Shuman

Faculty Advisor: Dr. James Grover

Date submitted: 5/1/06

1
Abstract:
Modern car alarm systems are designed to notify those in the immediate vicinity
of the attempted burglary. The flaw with these systems is notification does not always go
to the most important person, the owner. The Car Alert System will bridge this gap
between alarm and owner through implementation of a modem. This modem, combined
with a processor, will be interfaced with an aftermarket alarm system to place an actual
phone call to the owner with voice notification that the alarm is sounding. Vehicle
owners that have an alarm system with remote-start capabilities will have expanded
conveniences. The Car Alert System will also make the remote starter accessible from
any location through a simple touch-tone telephone call to the car.

Key features
• Accessible from any touch tone phone
• Can run system in an un-started car for 1 week
• Able to use alarm system’s original equipment along with touch-tone
phone
• Password and dialed phone number are fully configurable

2
Introduction:
Statement of Need: It is inadequate to have an alarm system that only brings
attention to individuals within the surrounding area and not the owner who is outside the
alarm’s audible range. Outside of the audible range, an owner does not have the
capability of physical interaction with the alarm.

Problem Definition:
Goal:
• A remote starter and car alarm that allows remote user interaction
through a touch-tone telephone call.

Objectives:
• The user must be able to change the number dialed by the system via
phone call.
• The system must leave a call connected until the owner enters a
command or a preset timer expires.
• The complete system must recognize user inputs from any touch-tone
phone and respond with the appropriate command in the car (i.e.
disengage the alarm, start or stop the car’s engine, and lock or unlock
the electric door locks).

Constraints:
• The complete system must fit in a concealed location of any car.
• The system must remain active in an un-started vehicle for a period of
one week without threatening the vehicle’s starting capabilities.
• System must have a way to disable automated alarm notification and
remote interaction.

3
Design Requirements:
Requirement Specifications:
• The system must place a phone call to the vehicle’s owner using the
GSM/GPRS modem when the car’s alarm begins sounding.
• The system must maintain a connection to the owner’s phone until the
owner enters a specific command or when the preset timer runs out.
• The complete system must recognize the audio tones from any touch-
tone phone, convert it to a digital signal, send a digital signal to the
alarm system, and respond with the appropriate command in the car.
• The system must be configured to enter a low-powered “sleep” mode
while not actively sending or receiving information and must “wake
up” when a call is present or an outgoing call must be sent.
• The system must be fully powered from a vehicle’s 12VDC electrical
system. Currently 12VDC and 5VDC are required for equipment.
• The processor must match the 97 bit code created by the alarm’s
factory radio receiver.

4
Accepted Technical Design:
Hardware:
In the fall semester of 2005, the decision was made to go with the design in
Figure 1 below to best accomplish the design goals. A few modifications had to be made
to the design to allow the system to perform in the desired way. The updated design can
be seen in Figure 2. It displays how information is passed between the different systems
and how power is distributed. Each aspect of the design and the changes that occurred
will be discussed in detail in later portions of this report. The most significant
components of the design included below are the remote starter/alarm system, Rabbit
microcontroller, GSM/GPRS modem, and voice chip.

Figure 1. Accepted Design Block Diagram

5
 Figure 2. Final Design Block Diagram

The after-market alarm that was chosen for this design was the Pro Series Deluxe
62 Remote Car Starter with Alarm System from Bulldog Security. This system was
chosen for its simplicity and compact nature. Also, there was existing knowledge of the
alarm system and its communication techniques, thereby saving research time. The first
step in this design was to determine how the alarm system communicated with itself and
the car in order to execute commands. It was found that the alarm system uses radio
frequency (RF) to transmit commands from the factory transmitter to the alarm system’s
RF decoder. The decoder takes in the frequency information and outputs a digital logic
signal to the control module. The control module has a microprocessor that then
interprets the logic pattern and opens or closes the corresponding relays to execute the
desired command. This process can be seen in Figure 3.

6
 Alarm RF
Decoder

SIGNAL

GND
LED
+5V
4-button
Factory Vehicle Ignition Harness
Transmitter
Digital Logic
Signal Alarm Control
Module

Figure 3. Data flow of Bulldog Security System

In order to make the after-market system perform through phone commands, it

would have to think it was receiving signals from its own factory components. It was
decided the easiest way to “trick” the alarm system would be to match the digital logic
signals sent from the RF decoder to the alarm’s control module. In order to match the
logic signals, it had to be determined what they were. To obtain the patterns, a digital
probe was connected to the signal line in Figure 3 and screen captures were taken on a
mixed signal oscilloscope. As can be seen in Figure 4, the factory transmitter has four
buttons, therefore, four different logic patterns were captured.

Figure 4. Pro Series Deluxe 62 Remote Car Starter with Alarm Transmitter [4]

7
 It was found that each button of the factory transmitter produces a 97 bit code in
Non-Return to Zero (NRZ), Transistor-Transistor Logic (TTL). In other words, a 97 bit
pulse from 0 to +5V is sent to the alarm control module for each button. For example,
the “Arm” button (Button 2) pattern can be seen in Figure 5. The pattern is repeated for
as long as the button is depressed with approximately 18.6ms between patterns, Figure 6.
Each individual bit of the pattern remains high or low for at least 640 μs . This value was
obtained using cursors on the mixed signal oscilloscope and can be seen in Figure 7. The
patterns for each button only differ in the last 13 bits; the first 84 serve as security
encryption and recognition for the alarm system and are the same for all four buttons.

97 bits

Figure 5. 97 bit logic pattern produced by “Arm” button

8
 Figure 6. Delay time between pattern repetitions

Figure 7. Display of one bit period

Once the different logic patterns were obtained, a method was needed to produce
equivalent patterns that would “trick” the alarm system’s control module into performing
requested tasks. To produce these patterns, the Rabbit 3000 Microprocessor was chosen.
This 8-bit processor was chosen as part of a GSM/GPRS development board that is

9
manufactured by Rabbit Semiconductor. The development board can be seen in Figure 8.
It is geared toward aiding in cellular communication projects.

Figure 8. GSM/GPRS development board [6]

In particular, the Rabbit 3000 has 54 parallel I/O lines, 46 of which are configurable.
This number of I/O lines will come in very handy when discussing the voice chip circuit
that requires 13 pins alone. The processor operates at 29.4 MHz which is plenty fast
enough to reproduce a pulse with a bit period of 640µs. To show this operating
frequency is fast enough, please see Table 1. A small computer program will allocate
one of the processor’s pins to produce the desired logic patterns. Through the use of

10
timers and delays, the pin will be driven high and low for the required amounts of time
that will produce patterns identical to those sent from the alarm’s RF decoder. This pin
assignment, as well as all others, can be seen in Tables 2 and 3.

Table 1. Verification of Processor Speed

11
 Table 2. Rabbit Microprocessor Pin Assignments (Header J1)
Pin Pin Name Default Use Alternate Use Notes Project Use
1 GND
2 STATUS Output (Status) Output
External data
bus
(ID0-ID7)
3-10 PA[7:0] Parallel I/O
Slave port data
bus
(SD0-SD7)
11 PF3 I/O QD2A
12 PF2 I/O QD2B
QD1A
13 PF1 I/O
CLKC
QD1B
14 PF0 I/O
CLKD
15 PC0 Output TXD DTMF RX
Serial Port D
16 PC1 Input RXD DTMF TX
17 PC2 Output TXC modem TX
Serial Port C
Header J1

18 PC3 Input RXC modem RX

19 PC4 Output TXB modem TX
Serial Port B
20 PC5 Input RXB modem RX
21 PC6 Output TXA Serial Port A
(programming
22 PC7 Input RXA port)
Serial Clock F
23 PG0 I/O TCLKF
output
Serial Clock F
24 PG1 I/O RLCKF
input
25 PG2 Output TXF
Serial Port F
26 PG3 Input RXF
27 PD4 I/O ATXB
28 PD5 I/O ARXB
29 PD2 I/O
30 PD3 I/O
31 PD6 I/O
32 PD7 I/O
Logic pattern
33 PD0 I/O
output
34 PD1 I/O

12
 Table 3. Rabbit Microprocessor Pin Assignments (Header J2)
Pin Pin Name Default Use Alternate Use Notes Project Use
Reset output
1 /RES Reset output Reset input from Reset
Generator
Voice chip
2 PB0 I/O CLKB memory
address 1
External
Voice chip
IA0 Address 0
3 PB2 I/O memory
/SWR Slave port
address 2
write
External
Voice chip
IA1 Address 1
4 PB3 I/O memory
/SRD Slave port
address 3
read
External
Voice chip
IA2 Address 2
5 PB4 I/O memory
SA0 Slave port
address 4
Address 0
External
Voice chip
IA3 Address 3
6 PB5 I/O memory
SA1 Slave port
address 5
Address 1
Voice chip
External
7 PB6 I/O IA4 memory
Header J2

Address 4
address 6
External
Voice chip
Address
8 PB7 I/O IA5/SLAVEATTN memory
5Slave
address 7
Attention
Voice chip
AQD1B
9 PF4 I/O memory
PWM0
address 8
Voice chip
AQD1A
10 PF5 I/O memory
PWM1
address 9
Voice chip
AQD2B
11 PF6 I/O memory
PWM2
address 10
AQD2A Voice chip
12 PF7 I/O
PWM3 START/STOP
I7 Voice chip LOW
13 PE7 I/O
/SCS PWR MODE
DTMF switch to
14 PE6 I/O I6
Relay
I5 vehicle ignition
15 PE5 I/O
INT1B input
I4
16 PE4 I/O alarm LED input
INT0B
MOSFET
17 PE3 I/O I3
switch to DTMF

13
 I1 I/O Strobe 1 alarm siren
18 PE1 I/O
INT1A Interrupt 1A input
I0 I/O Strobe 0
19 PE0 I/O
INT0A Interrupt 0A
20 PG7 I/O RXE
Serial Port E
21 PG6 I/O TXE
Serial Clock
22 PG5 I/O RCLKE
E input
Serial Clock
23 PG4 I/O TCLKE
E output
External
24 /IOWR Output
write strobe
External
25 /IORD Input
read strobe
(0,0)--start
executing at
address zero
(0,1)--cold boot
from slave port
(1,0)--cold boot
from clocked
Serial Port A Also
SMODEO, connected to
26-27
SMODE1 SMODE0=1, programming
SMODE1=1 cable
Cold boot from
asynchronous
Serial Port A at
2400 bps
(programming
cable
connected)
Input to
28 /RESET_IN Input Reset
Generator
Maximum
29 VRAM Output Current
Draw 15 uA
Minimum
30 VBAT_EXT 3 V battery Input battery
voltage 2.8 V
3.15-3.45 V
31 +3.3V Input
DC
32 GND
33 n.c.
34 GND

14
 In the original design, the processor’s 97 bit signal line was going to be hard-
wired directly into the alarm’s factory signal line as seen in Figure 9.

Alarm RF
Decoder
+3.3V CMOS +5V
to TTL

SIGNAL
Armed System LED

GND
LED
+5V
uC
Alarm Control
Module

Figure 9. Original 97 Bit Signal Line Connection

However, this had to be changed during the actual implementation due to heavy
interference. When the two lines were spliced together, there was a significance amount
of feedback/crosstalk between the processor and the alarm systems RF decoder. In order
to deviate from this problem, a +5V single-pole, double-throw (SPDT) relay was used.
The alarm’s signal line was attached to the normally closed terminal of the relay so that if
the Car Alert System was disabled, the alarm system would still work with its factory
equipment. The microprocessor’s signal line was attached to the normally open terminal.
When the Car Alert System tries to send a 97 bit signal to the alarm, the software first
triggers another pin and turns on a MOSFET. The MOSFET completes a ground
connection for the relay which, in turn, excites the coil and switches the contact from the
normally closed position to the normally open position. The implemented signal line
connection with the relay can be seen in Figure 10 while the MOSFET circuit controlling
the relay can be seen in Figure 11.

15
 Alarm RF
Decoder

NC
Armed System LED
+3.3V CMOS +5V SPDT
to TTL Relay
NO

GND
+5V
LED
OUTPUT
uC

Alarm Control
Module

Figure 10. Actual 97 Bit Signal Line Connection

Figure 11. MOSFET Switch for Relay Circuit

16
 Each header of the development board (J1 and J2) is shown with their pin
assignments and destinations within the Car Alert System in Figures 12 and 13.

Figure 12. Schematic for Header J1 of RCM3100

17
Figure 13. Schematic for Header J2 of RCM3100

18
 Once a plan was in place as to how the pulses would be created, a decision was
needed as to how the processor would know when to send the logic patterns to the alarm
control module. In other words, the user’s input command on their touch-tone telephone
needed to be converted into a signal recognizable by the microprocessor. When a button
is pressed on a touch-tone phone, the “beep” that sounds is composed of two frequencies.
It is known as a dual-tone multiple frequency (DTMF) tone. The frequencies that are
assigned to each number of a telephone’s keypad can be seen in Table 4.

Table 4. DTMF Frequencies

1209Hz 1336Hz 1477Hz 1633Hz
697Hz 1 2 3 A
770Hz 4 5 6 B
852Hz 7 8 9 C
941Hz * 0 # D

For this design, a DTMF decoder will take in the tone created through an RCA jack and
will output an ASCII value in serial data format. The DTMF decoder module used for
this design is the DTMF to RS232 Decoder (part # DTMF232) from DSchmidt
Technologies.
Since the DTMF decoder is only used during active calls it was decided to shut it
off to conserve power while no call is present. In order to do this, a MOSFET circuit was
used that serves as a switch to the decoder. An output pin of the microprocessor is set
high when a call is present and turns on the MOSFET, thereby completing the ground for
the DTMF decoder. The circuit can be seen in Figure 14.

19
 +12V

DTMF
decoder

uC +3.3V CMOS +5V

to TTL

1M

Figure 14. MOSFET circuit to control DTMF decoder power

The modem that was chosen for this project is the Enfora GSM/GPRS Spider SA
GL Modem shown in Figure 15. It is the mediator between all components of the design
in that all information between the user and the microprocessor passes through it. The
biggest attraction to this modem is that it directly accepts Subscriber Identity Module
(SIM) cards. Since subscriber information is held on the SIM card instead of
programmed in the modem itself, it makes changes very easy to implement. Whether the
ownership of the modem changes, the user wishes to change carriers, or wishes to change
the “modem’s” phone number, it can all be done by simply changing the SIM card
instead of reprogramming the modem.

Figure 15. SIM card placement in GSM/GPRS modem [2]

20
 Obviously, all modems have the ability to answer calls and transmit data, but not
all have audio interfaces to them. The Spider SA GL has a 2.5 mm microphone/speaker
port that will pass audio information through it. This port is what was used for passing
the DTMF tones created by the user’s touch-tone phone and the voice commands
outputted from the voice chip. The DTMF tones pass through the modem and are fed
into the RCA microphone port of the DTMF decoder to create the ASCII values needed
by the microprocessor. In a similar manner, all programmed verbal phrases are fed into
the 2.5mm port on the modem from the voice chip’s output pin. This can be seen in
Figure 16.

DTMF
decoder
microprocesso
r
modem
voice
bank
Figure 16. Audio flow through 2.5mm port of modem [1,2,3,5]

All of the above audio data is simply passed through the modem, not controlled or
manipulated by the modem itself. Digital data that directly affects the modem are ASCII
based AT commands. These commands drive the modem and are sent to it from the
microprocessor through RS232 Serial communication. This connection is laid out and set
up on the development board within the GSM/GPRS development package. Figure 17
displays the connection of the modem to the development board. The modem is powered
using a +5V regulator, stepping down the car’s +12V supply.

21
 Figure 17. Modem’s connection to development board [6]

The voice record/playback device chosen for this design is the ISD25120P from
Winbond Electronics. It has 10 memory addressing bits that allow for a total possible
duration of 120 seconds. The total amount of time needed for this project is
approximately 72 seconds. Therefore, this chip covers the current demand and leaves
room for expansion. Table 5 shows a complete list of the verbal phrases and their
duration times used within the Car Alert System. This voice chip operates at +5V,
therefore can be implemented directly on the development board.

22
 Table 5. Verbal phrase message list
MSG# Duration Message Associated function
Your alarm is sounding. If you would like to silence
1 8 and disarm your car, press 1. If you would like to do DialMain
nothing and end this call press 2.
If you would like to disarm the alarm, press 1. If you
would like to arm the alarm, press 2. If you would
like to turn the car on, press 3. If you would like to
2 21 turn the car off, press 4. If you would like to change CallMain
your security password, press 5. If you would like to
change the outgoing phone number, press 6. If you
would like to end the call press 7.
3 2 The alarm is now armed. AlarmSC
4 2 The alarm is now disarmed. AlarmSC
5 2 The car is running. Car
6 2 The car is off. Car
7 3 Please enter the new outgoing phone number. ChangeDialed
8 3 Please re-enter the phone number to confirm. ChangeDialed
9 3 The outgoing number has been changed. ChangeDialed
I'm sorry, the 2 entries do not match. The phone
10 5 ChangeDialed
number was not changed.
11 3 Please enter the security password. PasswordCheck
12 3 I'm sorry, that was not the correct password. PasswordCheck
13 3 Please enter the new security password. ChangePW
14 3 Please re-enter the password to confirm. ChangePW
15 2 The password was changed. ChangePW
I'm sorry, the 2 entries do not match. The password
16 4 ChangePW
was not changed.
17 3 Please press any key. CallMain

72 =Total duration of messages in seconds

Each phrase is retrieved by signaling its personal address using the 10 address bits of the
chip. A complete schematic of the voice record/playback device can be seen in Figure
18.

23
 Figure 18. Voice Chip Schematic

A couple minor circuits are needed as logic translators in addition to the

development package because as described in Figure 2., 3.3V, 5V, and 12V systems all
have to communicate with one another.
When the alarm sounds on the vehicle, some type of trigger is needed to tell the
processor and modem to place a call to the vehicle’s owner. It was decided to tap into the
+12V line of the alarm’s siren to serve as the indicator. This line was chosen because it
is continuously “hot” only while the alarm is sounding, it does not pulsate like the horn
wire. However, because the line is at +12V when it is on, it is much too high for the
microprocessor to handle. Therefore, a circuit is needed to step down the voltage. A
simple voltage divider circuit was implemented to handle this conversion. Choosing this
route uses few components and eliminates the need of a supply line to a MOSFET or
relay. The circuit can be seen in Figure 19.

24
 Siren
100k
+3.3V +12V Alarm

uC 38k

Figure 19. Alarm to processor circuit (12 to 3.3)

The same type of configuration was used for checking the vehicle’s engine state, running
or not running. Users have the option to call their vehicle to check to see if the remote
starter has been engaged or not. The same principle as above applies except the +12V
ignition wire from the alarm will be used instead of the siren wire. The +12V of the
ignition wire will be stepped down to +3.3V so the microprocessor can handle it
efficiently.
A different type of circuit is needed for the microprocessor to communicate
effectively with the alarm system. The alarm system uses +5V (TTL) logic while the
microprocessor only outputs +3.3V (CMOS) logic. In order to duplicate the +5V logic
patterns created by alarm’s factory transmitter, the Rabbit microprocessor’s voltage must
be converted to +5V. In order to keep the design simple, it was decided to use an existing
integrated circuit (IC) to make the conversion. The IC that was chosen was the Hex Non-
Inverting TTL Buffer from Fairchild Semiconductor (part #MM74C902). This chip takes
the CMOS logic signal outputted from the microprocessor and converts it to the required
TTL logic for the alarm. A total of three of these chips are used, each having 6
input/outputs. The chips are used for all outputs from the processor (+3.3V) to the voice
chip, alarm system, etc. (+5V). A schematic of the TTL buffers can be seen in Figure 20.

25
 Figure 20. CMOS to TTL Logic Translator Schematic

A third circuit needed for this design involves the LED signal line of the alarm
system and the microprocessor. While the alarm system is armed, the LED on the RF
decoder blinks. Only while the alarm is armed will this light blink and therefore will
serve as a great indication as to whether or not the alarm is armed. By taping into the
LED signal line, the microprocessor can monitor the alarm’s state. The allocated I/O pin
of the processor was configured to sample the line for two periods of the time the LED
normally blinks. So, similar to checking the vehicle’s engine state, the vehicle owner can
call the system to check whether or not the vehicle is armed. The Car Alert System sends
a verbal phrase confirming the car is armed if +5V is sensed on the LED signal line. The
system sends a verbal phrase stating the opposite if no voltage is seen on the LED signal
line within the two period time span. The problem lies in that the LED is fed with +5V
while the microprocessor is designed for +3.3V. Another simple voltage divider was
used to make the conversion. The circuit below is installed in between the LED signal
line of the alarm system and the microprocessor, shown in Figure 21.

26
 Alarm RF
Decoder
1.5k
+3.3V +5V

SIGNAL

GND
LED
+5V
Armed System LED

3.8k
uC
Alarm Control
Module

Figure 21. LED to processor circuit (5 to 3.3)

One aspect considered while choosing all of the above methods for this design
was power consumption. Because this system is installed in a vehicle, battery life and
starting capabilities of the vehicle are a factor. It was specified that the system must
remain active in an un-started vehicle for seven days without affecting the vehicle’s
starting capabilities. Table 6 displays power characteristics of each component of the Car
Alert System at different instances in time (i.e. idle states, active states, etc.).

27
 Table 6. Power Characteristics
Item Required Given Current draw Notes Supply Source
75mA unloaded
RCM3100 8-24V DC 12V 1A max for +3.3V and +5V combined Car
120uA "sleepy" mode (unloaded)
20mA active
DTMF 7-24V DC 12V 10mA idle Car
0mA chip turned off (no connected call)
225mA 1TX 1 RX DC/DC
140mA 1RX converter
MODEM 5-9V DC 5V
45mA idle (Car's 12 down
35mA sleep to 5)
25mA powered up Development
VOICE 5V DC 5V
10uA powered down Board
23mA system armed (LED blinking)
ALARM 12V DC 12V Car
18mA idle (alarm disarmed)

20% safety factor

Total current drawn by active development
board: 100mA 120mA
(processor at 29.4MHz)
Total current drawn from entire system:
*calculations are for an idle system 58mA 70mA
(no active calls are present and alarm is armed,
processor at 32.768kHz, DTMF off)
Total worst case current drawn by entire
system
368mA 442mA
(all components are fully active w/ processor at
29.4MHz)

Taking the idle system scenario with the 20% safety factor, the total amp hours
for seven days of operation can be written as: 70mA × 24h × 7 d = 12 Ah . Another
variable is that all vehicles have different batteries at different ratings. In order to show
the seven day period is not out of scope for any vehicle, a lower end car battery will be
used in the next calculation. The battery used for this calculation has the following
ratings:
Table 7. Battery used for 7 day calculation
Reserve Capacity (RC) 40
Amp Hour 28
Cold Cranking Amps 600
Max Amps 2400

28
The battery described in Table 7 has an amp hour rating of 28Ah. In other words, this
battery is capable of supplying 70mA for a period of 2.3 weeks or 167mA for a period of
1 week. Either way, the battery is sufficient to handle the 70mA load of the Car Alert
System for one week. (This calculation assumes zero leakage current in the battery and
zero current draw of other systems in the vehicle.) A schematic of the Car Alert
System’s complete power distribution can be seen in Figure 22.

Figure 22. Car Alert System Power Distribution Schematic

To summarize the hardware design, a complete parts list can be seen in Table 8.

29
 Table 8. Complete parts list
Qty. Refdes Part Num. Description
1 R4 29663CE 1K Resistor .25 W
2 R8 29760CE 1.5K Resistor .25 W
2 R9 30736CE 3.8K Resistor .25 W
1 R1 31237CE 5K Resistor .25 W
2 R2,R3 29911CE 10K Resistor .25 W
2 R11,R14 30955CE 38K Resistor .25 W
2 R10,R13 29997CE 100K Resistor .25 W
1 R5 31202CE 470K Resistor .25 W
2 R12,R15 1M Resistor .5W
6 C2,C3,C4,C5,C6,TBD 15342CE .1uF Capacitor
1 C9 .33uF Capacitor
1 C8 11077CE 4.7uF Capacitor
1 C1 199179CE 22uF Capacitor
1 C7 199291CE 220uF Capacitor
3 102824CE Panel Mount Fuse Holder
3 FU1,FU2,FU3 103907CE 1A Fuse
1 SW1 76241CE Toggle Switch
1 SPK1 31958CE 16ohm Speaker
1 MIC1 320004CE Electret Microphone
2 LED1 141129CE Panel Mount LED
1 U2 IDS25120P ISD2500 Series Voice Chip
1 U1 DTMF232 DTMF to RS232 Converter
1 U3 101-0948 GSM/GPRS Application Kit
3 U4,U5,U6 MM74C902 CMOS to TTL Buffer
1 VR1 LM7805C 3-Terminal Positive Voltage Regulator (5V)
2 BUZ11 30A, 50V, 0.040 Ohm, N-Channel Power MOSFET
1 BULLDOG SECURITY DELUXE 62 Starter & Alarm Combo
1 6" x 9" x 5" metal enclosure
1 3-Ft. Gold Series Stereo Y-Cable, Phono Plugs to 1/8" Jack
1 1/8" Stereo Jack to 3/32" Stereo Plug Adapter
1 flat head nylon screw (qty 10)
1 nylon tapped spacer (qty 4)
1 nylon hex nut (qty 10)
1 flat head nylon screw (qty 10)
1 9-Position Female Interlocking Connector
1 9-Position Male Interlocking Connector
1 CR1 SPDT 1A-5VDC relay
1 R16 270 Ohm resistor
1 R18 220 Ohm resistor
1 R17 270k Ohm resistor
1 90 degree power connector

30
Software:
With the aforementioned hardware, software is needed to control the hardware in
the desired ways. Below is a brief listing of each of the functions that will be necessary
for the Car Alert System to function properly. Each function and subroutine is described
with the function calls inside each function.

void main()
This function holds the calls to the initialization parameters for the modem and board as
well as the monitoring loop to detect any change in state. These state changes are either
an incoming call from a user to the car or the alarm being set off.

Function Calls: void ModemSetup(), void UserBlock(), void StopVC(), int CallTimer(),
void VoiceChip(long)

Void ModemSetup
This function sets up the modem to all the pre-determined parameters such as all the
audio output levels and automatic answering. It will write the command to the modem,
check to make sure it completed correctly, and then proceed to the next command.

Function Calls: none

int CallTimer(void)
This function polls the modem for the active, or last call, timer using the AT%CTV
command described below. The response is then parsed to pull out the timer value. This
result is converted to an integer and returned.

Function Calls: none

void DialMain()
This function turns on the DTMF module, dials the outgoing phone number and then
reads the menu to the user. The alarm can either be disarmed and then end the call or

31
ignore the alarm, get a status of the car and then end the call. At the end of the function,
the DTMF module is once again turned off.

Function Calls: void StopVC(), int CallTimer(), void VoiceChip(long), void

Alarm(char*), void EndCall()

void CallMain()
This function turns on the DTMF module allowing for translation of keys on the phone.
Then PasswordCheck is called to prompt the user for the system password. The current
state of the car is reported once SystemStatusCheck is called. The functional menu is
read where the alarm can be armed/disarmed, the car can be turned on/off, the password
and outgoing phone number can be changed or the call can be ended. Upon returning
from these functions the menu will be repeated.

Function Calls: void StopVC(), int CallTimer(), void VoiceChip(long), void

Alarm(char*), void EndCall(), void PasswordCheck(), void SystemStatusCheck(), void
Car(char*), void ChangePW(), void ChangeDialed()

void Alarm(char*)
This function calls AlarmStatus to check the current state of the alarm system. The based
upon the user's command of arming or disarming the alarm and the current state of the
alarm, the necessary command is sent to the alarm box. AlarmSC is called to verify that
the appropriate action has been taken.

Function Calls: char* AlarmStatus(), void CommToCar(char*), void AlarmSC()

void AlarmSC()
This function rechecks the status of the alarm but with a built in timer. This timer is to
keep from reading a false positive after disarming. If the alarm was tripped since its
initial arming, the signal LED will blink a number of times signaling which zone on the

32
alarm tripped. In order from reading this falsely, the timer was adjusted to wait until after
this period.

Function Calls: void VoiceChip(long), void StopVC(), char* AlarmStatus()

char* AlarmStatus()
This function checks for the signal LED to blink showing that the alarm is armed. The
current status of the alarm is returned.

Function Calls: none

void Car(char*)
This function calls CarStatus to check the current state of the car's ignition wire. The
based upon the user's command of turning on or off the car and what the car is currently
doing, the necessary command is sent to the alarm box. CarStatus is called once again to
verify that the appropriate action has been taken.

Function Calls: char* CarStatus(), void CommToCar(char*), void StopVC(), void

VoiceChip(long)

char* CarStatus()
This function polls the ignition wire on the car to determine if the car is running and then
returns the current status.

Function Calls: none

void EndCall()
This function calls SystemStatusCheck to check the status of the car. Then the command
to end the active call is given and the DTMF module is shut down.

Function Calls: void SystemStatusCheck()

33
void ChangeDialed()
This function prompts for a new outgoing number to be entered. As each key is read by
the processor a response tone will be repeated back. The number must be repeated twice
in order to be changed. An audio tone will alert the user as to whether the number was
changed. On a successful number change the new user number will be stored in the
userblock.

Function Calls: void StopVC(), void VoiceChip(long), void UserBlock()

void PasswordCheck()
This function prompts the user for the security password. As each key is read by the
processor a response tone will be repeated back. If either the user password or the master
password is entered within the time limit then the user is allowed to continue. If the
password is not entered correctly, a flag is incriminated. Three wrong guesses and the
call is terminated.

Function Calls: void VoiceChip(long), void StopVC()

void ChangePW()
This function prompts for a new password to be entered. As each key is read by the
processor a response tone will be repeated back. The password must be repeated twice in
order to be changed. An audio tone will alert the user as to whether the password was
changed. On a successful password change the new user password will be stored in the
userblock.

Function Calls: void VoiceChip(long), void StopVC(), void UserBlock()

void CommToCar(int)
This function takes in the code denoting which button code on the alarm's keychain
device should be simulated by the processor. A relay must be switched so that the alarm

34
system gets its input from the processor instead of the alarm box so a control signal is
sent for the duration of the simulated signal transmission. The logic pattern is sent out to
the processor 10 times to ensure the command was read.

Function Calls: none

void SystemStatusCheck()
This function checks the current status of the car and reports it back to the user. It
performs this by calling the tree of Alarm and Car functions designed to poll the system.

Function Calls: char* AlarmStatus(), char* CarStatus(), void StopVC(), void

VoiceChip(long)

Void WritetoUserBlock(void)
This function takes the user specified password and outgoing phone number and saves it
into the userblock section of memory on the chip. This allows for the changes to be kept
even after a power cycle.

Function Calls: none

Modem Software:
Some of the commands issued were performed by the software internal to the
modem. These commands are known as AT commands. The AT commands used are
described below.

ATD[number];
This command will tell the modem to dial the number in the command. (Substitute
everything between the brackets for the number to be dialed)

ATH
This signals the modem to hang up an active call.

35
AT%CTV
This polls the modem for the call timer. If there is an active call, the response gives the
current call timer. If there is no active call, the response gives the previous call timer
value. In the event that there has been no call since power up of the modem, there is no
number in the response.

AT
This is a modem readiness check command. If the modem is operational, it will respond
with OK.

ATE1
This turns on the echoing of entered commands to the modem.

AT$VGR=24
This sets the microphone receiver gain to 24dB.

AT$VGT=12
This sets the speaker transmit gain to 12 dB.

AT$VLVL=5
This sets the speaker volume to 5 dB.

AT$VST=10
This sets the sidetone volume to 10 dB.

ATSO=1
This sets the automatic answer of the modem to pick up after 1 ring.

AT+CHUP
This will end a connected call.

36
AT+VTS=*
This will make the modem beep as if the pound key was pressed.

Once the above software is implemented, the flow chart in Figure 23 will be in
effect.

Figure 23. Car Alert System signal flow

37
Testing Procedures:

1. Recognizing a received call

The modem must be able to receive a call as well as signal when a call has connected. In
order to verify this, two simple tests were performed. One test was done to let the
processor know when an outgoing call was answered and another was performed to know
when an incoming call is answered by the Car Alert System. When the alarm trips and an
outgoing call takes place, the software must wait for the owner to answer his/her phone.
The way this is done is by prompting the user to press any key on the touch-tone key pad.
From the time the modem dials a number, the processor continuously sends a command
to the voice chip that will repeatedly ask the user to press a button. When the call is
answered, the user hears the request to press a button and does so. This serves as
verification that the call was answered and the user is listening. From here, the code
executes as designed. A different test is performed to detect an incoming call. Within
the super-loop structure of main, there is a function that repeatedly checks the call timer
on the modem. The modem, like any other cell phone, has a timer that increments
whenever a call is present. Within main, the Car Alert System has a function that
monitors this timer. If the timer is incremented, it signifies a call has come in to the
system and the modem has answered. When the change in time is detected, the code
executes as designed and reads the main menu of options to the user.

2. Sending a call
The modem must be able to send a phone call to any number stored in memory in case of
the alarm tripping. This was tested by writing a small portion of code that retrieves a 10
digit phone number from memory and sends it to the modem. The modem then dials the
number. This test was repeated for multiple phone numbers and executed successfully
each time.

3. Alarm to processor voltage divider

The factory alarm system’s siren and ignition lines operate at +12V while the processor
operates at +3.3V. A voltage divider had to be placed on the input to the processor to

38
step down the voltage from the alarm to the processor. This was tested simply by bread-
boarding a resistor divider network and applying it with the +12V from the alarm system.
The output voltage was measured and found to be the desired +3.3V.

4. LED to processor voltage divider

The factory alarm system’s LED signal line operates at +5V while the processor operates
at +3.3V. A voltage divider was placed on the input to the processor to step down the
voltage from the LED to the processor. This was tested similar to that of the ignition and
siren lines. A resistor divider network was bread-boarded and applied +5V. The output
was found to be the desired +3.3V.

5. Processor to alarm logic translation

The processor’s +3.3V logic signals would not be picked up by the alarm system’s +5V
logic detector alone, they needed to be amplified. This amplification was done via
CMOS to TTL logic translator chips. The chips were bread-boarded and a +3.3V DC
biased square wave with a frequency of 29.4 MHz was applied to it. The resultant signal
was tested to make sure it outputted the desired +5V and did successfully.

6. Processor signal sending

The 97 bit code sent from the processor needed to be properly amplified and be
recognized easily by the alarm system. In order to show the proper bit periods were
achieved and the logic level retained, one of the 97 bit patterns was sent out on one of the
processors I/O lines by writing a small portion of code. The resultant signal was
analyzed on an oscilloscope. The bit periods as well as the logic levels were measured to
make sure they met specifications. An image of the captured bit pattern can be seen
below in Figure 24.

39
 Figure 24. Actual bit pattern obtained for ‘Start’ button

It can be seen that all 97 bits are accounted for and meet the required time periods
(640us).

7. Processor controlled DTMF power

The DTMF decoder does not need to be constantly fed power. It only needs to be on
when signals need to be decoded. To do this, a pin on the processor was set to go high.
When this happens, the +3.3V output is fed to the CMOS to TTL buffer. The buffer
outputs +5V which turns on a MOSFET. When the MOSFET is on, it completes a
ground connection for the DTMF decoder which turns it on. This was tested by bread-
boarding the MOSFET and applying +5V to its gate terminal. The resultant output was
measured to make sure the ground was achieved, allowing the DTMF decoder to turn on.
The circuit used can be seen in Figure 14.

8. Voice chip circuit output

The voice chip works through ten addressing bits. Depending on the binary sequence
applied to the chip, it will play a different message. In order to test the voice chip, each
phrase was recorded on it and played back through a 16 ohm speaker. Then, to test if a

40
certain message could be played when desired, different binary patterns (0011001110,
0000110100, etc) that corresponded to different messages were applied to the chip. A ten
input dip switch helped make this test easier and can be seen in Figure 25. By setting the
individual switches, it mocked the signal that normally comes from the microprocessor.

Figure 25. DP-H-10 dip switch

41
Financial Budget:
Table 9 below depicts the estimated and actual costs for the labor portion of this
project. Before the implementation semester (Spring 2006) began, it was estimated that
10 hours a week would be sufficient time to complete the project. It didn’t take much
time to realize this estimate was too low. Right from the start, difficulties were
encountered with the software language used for programming the Rabbit
microprocessor. The language used was Dynamic C, a language strictly used by Rabbit.
During the design semester (Fall 2005), it was assumed this language was similar to a
language already familiar to the design team, ANSI-C. Within the first week, it was
found much more time would be needed for the project, mainly to allow for the learning
curve involving Dynamic C. As it turned out, Dynamic C was not nearly as similar to
ANSI-C as anticipated. In addition to the software issue, other problems arose involving
ground loops and interference but these will be discussed further in the Conclusion and
Recommendations section of this report. It was then estimated that 12 hours a week
would be more appropriate for completing the project on time.

Table 9. Labor cost

Design Team No. of
Member weeks Initial Revised Actual
Chris Dyer (EE) 20 $2,000.00 $2,400.00 $2,400.00
Dan Paul (EE) 20 $2,000.00 $2,400.00 $2,400.00
John Shuman (EE) 20 $2,000.00 $2,400.00 $2,400.00
Total Cost $6,000.00 $7,200.00 $7,200.00
*Estimated at $10.00 per hour

At the opening of this project, a material budget was set at $225.00, $75.00 a
person, by the university. Any cost over this amount had to be raised or paid out of
pocket by the team. Table 10 displays where all money was spent for the Car Alert
System. Cells colored white are parts that were bought by the university or supplied from
the university’s stock room. Items colored in green are items that were donated to the
project from companies or persons known to the team. Cells colored in yellow are all
parts that were purchased out of pocket by the design team. The breakdown for one
system came to $57.81 paid by the university and $673.12 paid by DT2. The majority of

42
the cost came from the software license incorporated with the GSM/GPRS Application
kit.
Table 10. Material cost

43
Project Schedule:
The Figures 26 – 29 are the schedules for the design phase of the project from the
fall semester. Figures 30 – 35 detail the hardware, software and system integration
phases of the implementation semester. Figures 36 – 41 are the actual timelines for the
implementation of the project. There were a few changes from the planned schedule but
they were minor. The MAX232 from the DTMF decoder was removed from the design
when it was discovered that the output signal can be captured before the chip much easier
than anticipated. The only other changes from the original time schedule was the amount
of time spent on tweaking the project. Changes were being made up until the day of the
presentations.

44
Design:

Figure 26. Design Gantt Chart – Alternative Design

45
Figure 27. Design Gantt Chart – Alternative Design Schedule

46
Figure 28. Design Gantt Chart – Accepted Design

47
Figure 29. Design Gantt Chart – Accepted Design Schedule

48
Implementation:

Figure 30. Implementation Gantt Chart – Hardware

49
Figure 31. Implementation Gantt Chart – Hardware Schedule

50
Figure 32. Implementation Gantt Chart – Software

51
Figure 33. Implementation Gantt Chart – Software Schedule

52
 Figure 34. Implementation Gantt Chart – System Integration

Figure 35. Implementation Gantt Chart – System Integration Schedule

53
Actual:

Figure 36. – Actual Gantt Chart - Hardware

54
Figure 37. – Actual Gantt Chart - Hardware Schedule

55
Figure 38. – Actual Gantt Chart – Software

56
Figure 39. – Actual Gantt Chart – Software Schedule

Figure 40. – Actual Gantt Chart - System Integration

57
Figure 41. – Actual Gantt Chart – System Integration Schedule

58
Design Team Information:

Chris Dyer – Electrical Engineering

cjd4@uakron.edu

Dan Paul – Electrical Engineering

dlp9@uakron.edu

John Shuman – Electrical Engineering

jns8@uakron.edu

Faculty Advisor – Dr. James Grover

jgrover@uakron.edu

59
Conclusions and Recommendations:
This project was designed to fulfill the requirements set forth by ABET’s and the
Electrical and Computer Engineering Department’s criteria for an acceptable senior
design project. The design process involved making adjustments based on system
priorities when conflicts occurred. Optimization of power was a major issue in the
design of the system because of the car’s limited supply in an un-started vehicle. The
system also had to be user friendly. Menus dictated to the user had to be simple enough
to accurately describe the options at hand yet short enough to minimize recording space
on the voice chip. The capability to isolate the computer system from the factory alarm
system was also very important. In the event that the user is going to be away for an
extended period of time and does not want to return to a dead car battery, the notification
toggle switch would be flipped. The system also needs to be hidden for security reasons,
therefore should not take up considerable space in the car. A few pictures of the final
product of the Car Alert System can be seen in Figures 42-43. Figure 44 displays all the
connections that are made between the vehicle and the Car Alert System.

Figure 42. Car Alert System Outside of Box

60
 Figure 43. Finalized Car Alert System

Dash LED 97 bit Signal IGN Line

SIREN Line (empty) Alarm LED

+12V GND Relay GND

Figure 44. Connections between CAS and vehicle

61
 After completing the project, several considerations have been made for the next
revision of the Car Alert System. As briefly described in the Financial Budget section of
this report, there were some grounding issues encountered. Since all the components in
the design had to be connected to the same ground, some ground loops were introduced.
This was a problem because once in the car, there would only be one ground available for
everything, the car’s negative battery terminal. It was because of these ground loops
there was some heavy interference on the modem’s audio line heard by the user. A
monotone buzzing sound was heard because of the feedback. Once the ground loops
were eliminated, much of the buzzing was reduced but was not completely gone.
Because of all this, it was thought that the next revision of the system should incorporate
some filtered grounding to reduce the feedback through the modem even more, if not
eliminate it entirely.
A second recommendation for future models would be to use a PIC
microprocessor instead of a Rabbit. One, the PIC uses ANSI-C for its programming and
would be much easier to implement and test. Two, the development board purchased for
this project was “overkill” in terms of what was available and what was actually needed.
The development kit was capable of much more than what was actually needed to
perform the required tasks. In other words, a great deal of cost could be eliminated by
using a PIC and creating specific printed circuit boards instead of purchasing Rabbit’s
development kit.
As it stands now, a basic cost analysis of the system places a final equipment cost
for creating one complete system at $430. In addition to that, the cost of engineering the
product was $7200 and another $300 for the estimated cost of the software license.
Based on a sale price of $700, 28 units need to be sold in order to break even.
430 x + 7200 + 300 = 700 x ; x = number of units to be sold
x = 27.777 ≈ 28 units
However, this is a prototype model and is much more costly than a consumer release
model. Future revisions of this product will provide a more compact, cost efficient
version for consumers. All future budget analysis should then be based off of that model
and not the prototype.

62
References:
[1] DTMF232 DTMF to RS232 Decoder Data Sheet
[2] Enfora GSM/GPRS Spider SA GL Modem Data Sheet
[3] ISD25120P Voice Chip Data Sheet
[4] Pro Series Deluxe 62 Remote Car Starter with Alarm System Installation Guide
[5] Rabbit 3000 Microprocessor Data Sheet
[6] RabbitCore RCM3100 Board Data Sheet

*Pictures located within this report were taken from the above data sheets

63
Appendices:
1. Car Alert System Dynamic C Program
2. DTMF232 DTMF to RS232 Decoder Data Sheet
3. Dynamic C User Manual
4. Enfora AT Commands Manual
5. Enfora GSM/GPRS Spider SA GL Modem Data Sheet
6. ISD25120P Voice Chip Data Sheet
7. MM74C902 Hex Non-Inverting TTL Buffer Data Sheet
8. MOSFET BUZ11 Data Sheet
9. Pro Series Deluxe 62 Remote Car Starter with Alarm System Installation Guide
10. Rabbit 3000 Microprocessor Data Sheet
11. RabbitCore RCM3100 Board Data Sheet
12. R70 SPDT 5V Relay Data Sheet
13. Voltage Regulator (LM341)

64