car alert system

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


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


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


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


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


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


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/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


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


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


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


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


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


5 PB4 I/OIA2SA0

ExternalAddress 2Slave port

Address 0


6 PB5 I/OIA3SA1

ExternalAddress 3Slave portAddress 1


7 PB6 I/O IA4ExternalAddress 4


8 PB7 I/O IA5/SLAVEATTN

ExternalAddress5SlaveAttention


9 PF4 I/O

AQD1B

PWM0

Voice chip

memoryaddress 8

10 PF5 I/OAQD1APWM1


11 PF6 I/OAQD2BPWM2


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


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


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


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


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


18/64

Figure 13. Schematic for Header J2 of RCM3100

18


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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.


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.


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


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


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.


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.


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


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


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


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


39/64


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


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


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


43/64

the cost came from the software license incorporated with the GSM/GPRS Application

kit.

Table 10. Material cost

43


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


45/64

Design:

Figure 26. Design Gantt Chart Alternative Design

45


46/64

Figure 27. Design Gantt Chart Alternative Design Schedule

46


47/64

Figure 28. Design Gantt Chart Accepted Design

47


48/64

Figure 29. Design Gantt Chart Accepted Design Schedule

48


49/64

Implementation:

Figure 30. Implementation Gantt Chart Hardware

49


50/64

Figure 31. Implementation Gantt Chart Hardware Schedule

50


51/64

Figure 32. Implementation Gantt Chart Software

51


52/64

Figure 33. Implementation Gantt Chart Software Schedule

52


53/64

Figure 34. Implementation Gantt Chart System Integration

Figure 35. Implementation Gantt Chart System Integration Schedule

53


54/64

Actual:

Figure 36. Actual Gantt Chart - Hardware

54


55/64

Figure 37. Actual Gantt Chart - Hardware Schedule

55


56/64

Figure 38. Actual Gantt Chart Software

56


57/64

Figure 39. Actual Gantt Chart Software Schedule

Figure 40. Actual Gantt Chart - System Integration

57


58/64


59/64

Design Team Information:

Chris Dyer Electrical Engineering

[email protected]

Dan Paul Electrical Engineering

[email protected]

John Shuman Electrical Engineering

[email protected]

Faculty Advisor Dr. James Grover

[email protected]

59


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


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


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


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


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)

car alert system

Documents