8/8/2019 Car Alert System
1/64
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
8/8/2019 Car Alert System
2/64
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 systems original equipment along with touch-tone
phone
Password and dialed phone number are fully configurable
2
8/8/2019 Car Alert System
3/64
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
alarms 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 cars engine, and lock or unlockthe 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 vehicles starting capabilities.
System must have a way to disable automated alarm notification and
remote interaction.
3
8/8/2019 Car Alert System
4/64
Design Requirements:
Requirement Specifications:
The system must place a phone call to the vehicles owner using the
GSM/GPRS modem when the cars alarm begins sounding.
The system must maintain a connection to the owners 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 vehicles 12VDC electrical
system. Currently 12VDC and 5VDC are required for equipment.
The processor must match the 97 bit code created by the alarms
factory radio receiver.
4
8/8/2019 Car Alert System
5/64
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
8/8/2019 Car Alert System
6/64
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 systems
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
8/8/2019 Car Alert System
7/64
LED
Alarm RFDecoder
4-buttonFactory
Transmitter
Alarm ControlModule
SIG
NAL
+5V
GN
D
Vehicle Ignition Harness
Digital LogicSignal
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 alarms 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 3and 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
8/8/2019 Car Alert System
8/64
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 s640 . 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
8/8/2019 Car Alert System
9/64
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 systems 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
8/8/2019 Car Alert System
10/64
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]
particular, the Rabbit 3000 has 54 parallel I/O lines, 46 of which are configurable.In
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 640s. To show this operating
frequency is fast enough, please see Table 1. A small computer program will allocate
one of the processors pins to produce the desired logic patterns. Through the use of
10
8/8/2019 Car Alert System
11/64
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 alarms 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
8/8/2019 Car Alert System
12/64
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
3-10 PA[7:0] Parallel I/O
External databus
(ID0-ID7)Slave port databus(SD0-SD7)
11 PF3 I/O QD2A
12 PF2 I/O QD2B
13 PF1 I/OQD1ACLKC
14 PF0 I/OQD1BCLKD
15 PC0 Output TXD DTMF RX
16 PC1 Input RXDSerial Port D
DTMF TX
17 PC2 Output TXC modem TX18 PC3 Input RXC
Serial Port Cmodem RX
19 PC4 Output TXB modem TX
20 PC5 Input RXBSerial Port B
modem RX
21 PC6 Output TXA
22 PC7 Input RXA
Serial Port A(programmingport)
23 PG0 I/O TCLKFSerial Clock Foutput
24 PG1 I/O RLCKFSerial Clock Finput
25 PG2 Output TXF
26 PG3 Input RXF
Serial Port F
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
33 PD0 I/OLogic patternoutput
HeaderJ1
34 PD1 I/O
12
8/8/2019 Car Alert System
13/64
Table 3. Rabbit Microprocessor Pin Assignments (Header J2)Pin Pin Name Default Use Alternate Use Notes Project Use
1 /RES Reset output Reset inputReset outputfrom ResetGenerator
2 PB0 I/O CLKB
Voice chip
memoryaddress 1
3 PB2 I/OIA0
/SWR
ExternalAddress 0Slave portwrite
Voice chipmemoryaddress 2
4 PB3 I/OIA1
/SRD
ExternalAddress 1Slave portread
Voice chipmemoryaddress 3
5 PB4 I/OIA2SA0
ExternalAddress 2Slave port
Address 0
Voice chipmemoryaddress 4
6 PB5 I/OIA3SA1
ExternalAddress 3Slave portAddress 1
Voice chipmemoryaddress 5
7 PB6 I/O IA4ExternalAddress 4
Voice chipmemoryaddress 6
8 PB7 I/O IA5/SLAVEATTN
ExternalAddress5SlaveAttention
Voice chipmemoryaddress 7
9 PF4 I/O
AQD1B
PWM0
Voice chip
memoryaddress 8
10 PF5 I/OAQD1APWM1
Voice chipmemoryaddress 9
11 PF6 I/OAQD2BPWM2
Voice chipmemoryaddress 10
12 PF7 I/OAQD2APWM3
Voice chipSTART/STOP
13 PE7 I/OI7
/SCSVoice chip LOWPWR MODE
14 PE6 I/O I6
DTMF switch to
Relay
15 PE5 I/OI5INT1B
vehicle ignitioninput
16 PE4 I/OI4INT0B
alarm LED input
HeaderJ2
17 PE3 I/O I3MOSFETswitch to DTMF
13
8/8/2019 Car Alert System
14/64
18 PE1 I/OI1INT1A
I/O Strobe 1Interrupt 1A
alarm sireninput
19 PE0 I/OI0INT0A
I/O Strobe 0Interrupt 0A
20 PG7 I/O RXE
21 PG6 I/O TXESerial Port E
22 PG5 I/O RCLKE Serial ClockE input
23 PG4 I/O TCLKESerial ClockE output
24 /IOWR OutputExternalwrite strobe
25 /IORD InputExternalread strobe
26-27SMODEO,SMODE1
(0,0)--startexecuting ataddress zero(0,1)--cold bootfrom slave port
(1,0)--cold bootfrom clockedSerial Port A
SMODE0=1,SMODE1=1Cold boot fromasynchronousSerial Port A at2400 bps(programmingcableconnected)
Alsoconnected toprogrammingcable
28 /RESET_IN InputInput toResetGenerator
29 VRAM OutputMaximumCurrentDraw 15 uA
30 VBAT_EXT 3 V battery InputMinimumbatteryvoltage 2.8 V
31 +3.3V Input3.15-3.45 VDC
32 GND
33 n.c.
34 GND
14
8/8/2019 Car Alert System
15/64
In the original design, the processors 97 bit signal line was going to be hard-
wired directly into the alarms factory signal line as seen in Figure 9.
LED
Alarm RF
Decoder
Alarm ControlModule
SIGNAL
+5V
GND
+5V+3.3V
uC
Armed System LED
CMOSto TTL
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 alarms 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 microprocessors 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
8/8/2019 Car Alert System
16/64
LED
Alarm RFDecoder
Alarm ControlModule
+5V
GND
+5V+3.3V
uC
Armed System LED
CMOSto TTL
SPDTRelay
NC
OUTPUT
NO
Figure 10. Actual 97 Bit Signal Line Connection
Figure 11. MOSFET Switch for Relay Circuit
16
8/8/2019 Car Alert System
17/64
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
8/8/2019 Car Alert System
18/64
Figure 13. Schematic for Header J2 of RCM3100
18
8/8/2019 Car Alert System
19/64
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 users 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 telephones 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 itoff 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
8/8/2019 Car Alert System
20/64
+12V
uC
1M
+3.3V
DTMFdecoder
+5VCMOSto TTL
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 modems 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
8/8/2019 Car Alert System
21/64
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 users 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 chips output pin. This can be seen in
Figure 16.
modem
voice
DTMFdecoder
microprocesso
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 cars +12V supply.
21
8/8/2019 Car Alert System
22/64
Figure 17. Modems 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
8/8/2019 Car Alert System
23/64
Table 5. Verbal phrase message listMSG# Duration Message Associated function
1 8Your alarm is sounding. If you would like to silenceand disarm your car, press 1. If you would like to donothing and end this call press 2.
DialMain
2 21
If you would like to disarm the alarm, press 1. If youwould like to arm the alarm, press 2. If you wouldlike to turn the car on, press 3. If you would like toturn the car off, press 4. If you would like to changeyour security password, press 5. If you would like tochange the outgoing phone number, press 6. If youwould like to end the call press 7.
CallMain
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. Car7 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
10 5I'm sorry, the 2 entries do not match. The phonenumber was not changed.
ChangeDialed
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
16 4
I'm sorry, the 2 entries do not match. The password
was not changed. ChangePW17 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
8/8/2019 Car Alert System
24/64
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 vehicles owner. It was decided to tap into the
+12V line of the alarms 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
8/8/2019 Car Alert System
25/64
Alarm
uC
100k
38k
+12V+3.3V
Siren
Figure 19. Alarm to processor circuit (12 to 3.3)
The same type of configuration was used for checking the vehicles 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 alarms factory transmitter, the Rabbit microprocessors 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
8/8/2019 Car Alert System
26/64
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 alarms 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 vehicles 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
8/8/2019 Car Alert System
27/64
L
ED
Alarm RFDecoder
Alarm ControlModule
SI
GNAL
+
5V
G
ND
1.5k
3.8k
+5V+3.3V
uC
Armed System LED
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 vehicles
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
8/8/2019 Car Alert System
28/64
Table 6. Power CharacteristicsItem Required Given Current draw Notes Supply Source
75mA unloaded
1A max for +3.3V and +5V combinedRCM3100 8-24V DC 12V
120uA "sleepy" mode (unloaded)
Car
20mA active
10mA idleDTMF 7-24V DC 12V
0mA chip turned off (no connected call)
Car
225mA 1TX 1 RX
140mA 1RX
45mA idleMODEM 5-9V DC 5V
35mA sleep
DC/DCconverter(Car's 12 downto 5)
25mA powered upVOICE 5V DC 5V
10uA powered down
DevelopmentBoard
23mA system armed (LED blinking)ALARM 12V DC 12V
18mA idle (alarm disarmed)Car
20% safety factor
Total current drawn by active developmentboard:(processor at 29.4MHz)
100mA 120mA
Total current drawn from entire system:*calculations are for an idle system(no active calls are present and alarm is armed,processor at 32.768kHz, DTMF off)
58mA 70mA
Total worst case current drawn by entiresystem(all components are fully active w/ processor at29.4MHz)
368mA 442mA
Taking the idle system scenario with the 20% safety factor, the total amp hours
for seven days of operation can be written as: AhdhmA 1272470 = . 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 calculationReserve Capacity (RC) 40
Amp Hour 28
Cold Cranking Amps 600
Max Amps 2400
28
8/8/2019 Car Alert System
29/64
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
Systems 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
8/8/2019 Car Alert System
30/64
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 W2 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 Combo1 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
8/8/2019 Car Alert System
31/64
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
8/8/2019 Car Alert System
32/64
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
8/8/2019 Car Alert System
33/64
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
8/8/2019 Car Alert System
34/64
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
8/8/2019 Car Alert System
35/64
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
8/8/2019 Car Alert System
36/64
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
8/8/2019 Car Alert System
37/64
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 23will be in
effect.
Figure 23. Car Alert System signal flow
37
8/8/2019 Car Alert System
38/64
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 systems 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
8/8/2019 Car Alert System
39/64
8/8/2019 Car Alert System
40/64
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
8/8/2019 Car Alert System
41/64
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
8/8/2019 Car Alert System
42/64
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 didnt 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 TeamMember
No. ofweeks 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.00John 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 universitys 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
8/8/2019 Car Alert System
43/64
the cost came from the software license incorporated with the GSM/GPRS Application
kit.
Table 10. Material cost
43
8/8/2019 Car Alert System
44/64
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
8/8/2019 Car Alert System
45/64
Design:
Figure 26. Design Gantt Chart Alternative Design
45
8/8/2019 Car Alert System
46/64
Figure 27. Design Gantt Chart Alternative Design Schedule
46
8/8/2019 Car Alert System
47/64
Figure 28. Design Gantt Chart Accepted Design
47
8/8/2019 Car Alert System
48/64
Figure 29. Design Gantt Chart Accepted Design Schedule
48
8/8/2019 Car Alert System
49/64
Implementation:
Figure 30. Implementation Gantt Chart Hardware
49
8/8/2019 Car Alert System
50/64
Figure 31. Implementation Gantt Chart Hardware Schedule
50
8/8/2019 Car Alert System
51/64
Figure 32. Implementation Gantt Chart Software
51
8/8/2019 Car Alert System
52/64
Figure 33. Implementation Gantt Chart Software Schedule
52
8/8/2019 Car Alert System
53/64
Figure 34. Implementation Gantt Chart System Integration
Figure 35. Implementation Gantt Chart System Integration Schedule
53
8/8/2019 Car Alert System
54/64
Actual:
Figure 36. Actual Gantt Chart - Hardware
54
8/8/2019 Car Alert System
55/64
Figure 37. Actual Gantt Chart - Hardware Schedule
55
8/8/2019 Car Alert System
56/64
Figure 38. Actual Gantt Chart Software
56
8/8/2019 Car Alert System
57/64
Figure 39. Actual Gantt Chart Software Schedule
Figure 40. Actual Gantt Chart - System Integration
57
8/8/2019 Car Alert System
58/64
8/8/2019 Car Alert System
59/64
Design Team Information:
Chris Dyer Electrical Engineering
Dan Paul Electrical Engineering
John Shuman Electrical Engineering
Faculty Advisor Dr. James Grover
59
8/8/2019 Car Alert System
60/64
Conclusions and Recommendations:
This project was designed to fulfill the requirements set forth by ABETs and the
Electrical and Computer Engineering Departments 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 cars 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
8/8/2019 Car Alert System
61/64
Figure 43. Finalized Car Alert System
+12V GND Relay GND
Alarm LED
IGN Line
SIREN Line
Dash LED 97 bit Signal
(empty)
Figure 44. Connections between CAS and vehicle
61
8/8/2019 Car Alert System
62/64
After completing the project, several considerations have been made for the next
revision of the Car Alert System. As briefly described in the Financial Budgetsection 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 cars negative battery terminal. It was because of these ground loops
there was some heavy interference on the modems 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 Rabbits
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.
xx 7003007200430 =++ ;x = number of units to be sold
28777.27 =x 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
8/8/2019 Car Alert System
63/64
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
8/8/2019 Car Alert System
64/64
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)