978-1-4577-1343-9/12/$26.

00 2013 IEEE
GPS Enabled Speed Control Embedded System
Speed Limiting Device with Display and Engine Control Interface
Aamir Sarwar Jahan, Imdadul Hoq, and David Westerfeld
Department of Electrical and Computer Engineering
Stony Brook University
Stony Brook, USA
sarwarjahan@live.com, hoq.imdadul@gmail.com, davidwesterfeld@ieee.org

Abstract-- In the past decade, there have been close to 350,000
fatal crashes in the United States [1]. With various improvements
in traffic and vehicle safety, the number of such crashes is
decreasing every year. One of the ways to reduce vehicle crashes
is to prevent excessive speeding in the roads and highways. The
paper aims to outline the design of an embedded system that will
automatically control the speed of a motor vehicle based on its
location determined by a GPS device.
The embedded system will make use of an AVR ATMega128
microcontroller connected to an EM-406A GPS receiver. The
large amount of location input data justifies the use of an
ATMega128 microcontroller which has 128KB of programmable
flash memory as well as 4KB SRAM, and a 4KB EEPROM
Memory [2]. The output of the ATMega128 will be a
DOGM163W-A LCD module which will display information of
the current and the set-point speed of the vehicle at the current
position. A discrete indicator LED will flash at a pre-determined
frequency when the speed of the vehicle has exceeded the
recommended speed limit. Finally, the system will have outputs
that will communicate with the Engine Control Unit (ECU) of the
vehicle. For the limited scope of this project, the ECU is
simulated as an external device with two inputs that will
acknowledge pulse-trains of particular frequencies to limit the
speed of a vehicle.
The speed control system will be programmed using mixed
language C and Assembly with the latter in use for some pre-
written subroutines to drive the LCD module. The GPS module
will transmit National Marine Electronics Association (NMEA)
data strings to the microcontroller (MCU) using Serial
Peripheral Interface (SPI). The MCU will use the location co-
ordinates (latitude and longitude) and the speed from the NMEA
RMC output string. The current speed is then compared against
the recommended speed for the vehicles location. The memory
locations in the ATMega128 can be used to store set-point speed
values against a particular set of location co-ordinates.
Apart from its implementation in human operated vehicles,
the project can be used to control speed of autonomous cars and
to implement the idea of a variable speed limit on roads
introduced by the Department of Transportation [3].
Keywords-component; speed control, GPS, LCD Display,
Engine Control Unit Interface, LED feedback
I. INTRODUCTION
Intelligent Speed Adaptation (ISA) devices have been
introduced in vehicles over the last few years. An ISA device
constantly monitors the speed of the vehicle and makes
adjustments to keep the vehicle within its legal and safe speed
limit. An ISA device can be implemented using Global
Positioning System (GPS) receivers, radio frequency receivers,
or optical recognition systems. Radio frequency transmitters
can provide a simpler ISA solution by reducing memory usage
to store map locations. But the technology requires frequent
installations of roadside radio transmitters which will require a
considerable infrastructural investment [4]. Optical recognition
systems involves scanning speed limit signs to recognize the
acceptable speed limit in a specific location. This will also
restrict the use of such ISA technology to only areas that have a
frequent number of speed limit signs.
GPS technology does not suffer from the aforementioned
setbacks. The GPS receiver makes use of the satellites and the
infrastructure already in place and an extensive library of map
information is available. Therefore, this senior design project
uses GPS receivers to alert the driver of excess speeds at a
given location. The paper highlights how the information can
be used to communicate with the on-board computer of a given
vehicle. Several output peripherals such as LCD display and
LEDs are used to provide feedback to the driver.
The goal of this project is to provide a simple and effective
solution to control the vehicle speed. Adapting the speed of the
vehicle to its location will substantially reduce excessive
speeding and thus the chances of fatal crashes. An important
use of the ISA can be in developing countries that are yet to
have an effective highway patrol. A speed limiter can be used
to reduce the number of speed related crashes without spending
any additional funds on highway speed supervision. Moreover,
the project can be a part of the development of autonomous
cars. The ISA technology currently in use is limited to a few
specific vehicle manufacturers. The project uses an inexpensive
and effective solution that can be easily embeddable in
different vehicles with minor adjustments in ECU interface.
II. SYSTEM DESCRIPTION
A. ET AVR Stamp
The microcontroller used in the project is an ATMega128
which is mounted on an ET AVR Stamp board. The advantages
of using the board is that it packages the microcontroller in a
thin quad flat package (TQFP) and takes up less board space
with only 50 pin-outs. The ATMega128 is run at a 1 MHz
frequency with its external oscillator. This is same as the
frequency the GPS unit is operating.





B. JTAG mkII
In order to program the MCU, the ATMega128 is
interfaced via JTAG mkII. The JTAG is connected to the
computer by USB and development software AVR Studio 4
and IAR Embedded Workbench are used to program and debug
the device. The pin-outs of the JTAG to MCU are given in
Table I:
TABLE I. JTAG PIN-OUTS TO ATMEGA128
Pin
No.
Pin Description Connection to
1 Test Clock (TCK) PortF 4
2 Ground (GND) GND
3 Test Data Output (TDO) PortF 6
4 Reference Voltage (Vtref) +5V
5 Test Mode Select (TMS) PortF 5
6 Target System Reset (nSRST) RESET
7 Voltage High(VCC) +5V
8 No Connect (NC) x
9 Test Data Input (TDI) PortF 7
10 Ground (GND) GND

C. GPS Device EM-406A
The GPS receiver is the key device of the system and an
EM-406A GPS receiver is used for this project. This GPS has a
20 channel receiver ensuring a relatively decent startup time
and an accuracy of 5-10m which is sufficient for our purposes.
The GPS device performs at a baud rate of 4800bps and has a
1s update rate [4]. To avoid interference, the GPS is mounted
on a separate sideboard and is connected to the rest of the
module using a jumper cable. The EM-406A has six pins: Pin1
(GND), Pin2 (VCC), Pin3 (RX), Pin4 (TX), Pin5 (GND), Pin6
(PPS). The RX pin is used to receive instructions from the
MCU and the TX information is used to transmit GPS output
information to the MCU. The Pulse per Second (PPS) terminal
is not connected. Table II shows the pin-outs of the EM-406A.
TABLE II. EM-406A PIN-OUTS TO ATMEGA128
Pin
No.
Pin Description Connection to
1 Ground (GND) GND
2 Reference Voltage (VCC) +5V
3 Receive Channel (RX) PortE 1
4 Transmit Channel (TX) PortE 0
5 Ground (GND) GND
6 Pulse per Second (PPS) x

The GPS can output information using several output
strings and for this project, the Recommended Minimum
Specific GNSS Data (GPRMC) output message is used. An
example of RMC output string is:
$GPRMC, 01542333, A, 40.91455, N, 73.116399, E, 0.10,
329.62, 16022013, *29, <CR><LF>
The above string can be parsed to get information and the
classified information is given in Table III.
TABLE III. GPS RMC DATA FORMAT
RMC Data String Data Format
$GPRMC Message ID
01542333 UTC time in hhmmss.ss
A A=Valid data
40.91455 Latitude
N N/S Indicator
73.116399 Longitude
E E/W Indicator
0.10 Speed in Knots
329.62 Course over ground
16022013 Date in ddmmyyyy
*29 Checksum
<CR> carriage return
<LF> line feed

D. LCD Device DOGM163W-A
The LCD screen is the output of the system and displays the
location co-ordinates, the recommended speed at the current
location, and the current speed of the vehicle. The LCD module
in this project is a EA DOGM163W-A that has 3 lines with 16
characters per line. The LCD Module is assembled with a EA
LED55x31-W white backlight for better contrast. The LCD
Module is connected to the PORTB of ATMega128 via serial
peripheral interface. The display has 8 bits for data transfer
using parallel interface but for the purposes of this project, we
only use two terminals out of the 8 data bits for the Slave Input
(SI) and the Slave Clock (SCLK). The other data bits are set to
high which is 5V in this case. The Slave Select input is set to
high to select the LCD display as the slave device and the
MCU as the master device. The pins of the LCD are connected
to the MCU using a 10 pin header. Table IV gives the pin-outs.
TABLE IV. LCD MODULE PIN-OUTS TO ATMEGA128
Pin
No.
Pin Description Connection to
1,3,5 No Connect (NC) X
2 VCC +5V
4 Slave Select (SS) PortB 0
6 Register Select (RS) PortB 4






Pin
No.
Pin Description Connection to
7 Backlight Control (BLC) GND
8 Slave Input (SI) PortB 2
9 Ground (GND) GND
10 Slave Clock (SCLK) PortB 1

The LCD module can be used to display a set of specified
characters by directly sending the bit patterns of each character.
For this project, a driver subroutine named update_lcd_dog() is
used to write three 16 byte memory buffers in ATMega16s
memory. Each buffer represents a line in the display and each
byte is the ASCII representation of the character. As characters
are written to the memory buffer, a subroutine named
update_lcd() can be used to send the contents of the three
buffer to the microcontroller (ST7036) controlling the LCD
display.
E. Other I/O Devices
The system will have a System Test switch to turn the
system on or off at any time. This switch is needed to stop
draining power from the battery. A single pole double throw
(SPDT) tactile switch is used to turn the system ON and OFF.
When pressed, the switch will power the circuit and thus
turning ON the device. The switch will cut off the power
supply from the battery.
There will be two discreet LEDs that will indicate the status
of the vehicle speed. The green LED will be on to indicate if
the speed of the vehicle is under or equal to the recommended
vehicle speed at the current location. The red LED will blink at
a predetermined frequency as a function of the vehicle speed if
the speed is more than the speed limit. The Red LED will blink
faster if the speed increases thus providing a visual feedback to
the driver. A third blue LED will also be connected to the
microcontroller. This LED is turned ON every time the vehicle
enters a different speed zone. Three current limiting resistors
will be in series with the LEDs to regulate the current through
the LEDs. The typical value of these resistances is chosen to be
330 ohms.
F. Power Supply and Management
For this project, the Microcontroller, the GPS device, and the
LCD Display are all operated at 5V. In the laboratory, the
system is connected to CADET Electronic Circuit Trainer
which does not provide the desired portability. Therefore a 9V
battery is used to provide the power to the breadboard during
functional testing. A MIC2937A Low-Dropout Voltage
Regulator is used to convert 9V battery to 5V specification.
During the development phase, a system test switch is provided
to power on the system only when it is required for testing and
debugging purposes. This will avoid draining the battery
quickly.
To save battery power, the SLEEP modes of the
ATMega128 can be used. In order to enter any of the sleep
modes, the SE bit of the Microcontroller Control Register
(MCUCR) must be set to logic one. The MCUCR contains the
bits given in Table V.
TABLE V. ATMEGA128 MCUCR BITS
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0
SRE SRW SE SM1 SM0 SM2 IVSEL IVCE
After setting the SE bit, the SM1, SM0, and SM2 bits
determine the sleep mode out of the six sleep modes available.
Clearing all the three bits to zeroes makes the MCU enter Idle
Sleep Mode [2]. In Idle mode, the CPU stops but allows SPI,
USART, and the interrupt system to operate.
III. SYSTEM IMPLEMENTATION
A. Test Location
The location to test the speed control device is selected as
the campus roads inside Stony Brook University in Stony
Brook, NY. Figure 1 shows the intended path of the device as
it is mounted on a vehicle. The path was chosen to be such to
test the speed limiting feature of the device at both higher and
lower end of the speed limit. As can be seen from the diagram,
Figure 1. Test track of Vehicle





UCSR1A = 0x00; // Setting USART1 to RX
UCRR1B=0x10;
UCSR1C=0x06;
UBRR1H=0x00;
UBRR1L = 0X17
char time[32];
char validate;
char latitude[32];
char longitude [32];
char speed[32];
int position=0;
while{position != 6} {
data = UDR1;
if (data ==$) position++;
if (data == G) position++;
if (data == P) position++;
if (data == R) position++;
if (data == M) position++;
if (data == C) position++;
if(data ==,) position++; }
// place all the character to time char array until another
a character found which is equal to ,
position = 0 ;
while (data ! == ,) {
time[position] = data;
data = UDR1;
position ++; }
the test path is divided into four regions with varying speed
limits.
When the vehicle is driven through the test path, the GPS
device should be sufficiently accurate to turn ON the blue
LED as the vehicle crosses the speed zone. The GPS device
can have an error of 5-10 meters [5]. Nearly overlapping
regions with different speed limits, e.g. polygon 1 and 9, will
mean that the accuracy of the GPS can also be verified with a
degree of certainty.
B. Determination of Speed Zones
After the speed zones are marked, the microcontroller uses
the location co-ordinates obtained from the GPS and compares
it with the hardcoded values of location co-ordinates of the
different polygons representing each speed zone. Each region
is represented by a rectangle and the co-ordinates of the four
corners are obtained. The following table shows the latitude
and longitude co-ordinates of the some of the speed zones
obtained from Google Maps.
TABLE VI. GPS LOCATION CO-ORDINATES OF THE TEST AREA
Region Speed Location Co-ordinates (Latitude, Longitude)
1 55
(40.92431124509733, -73.11963558197021);
(40.92444905454594, -73.11930298805237);
(40.921376646274, -73.11726450920105);
(40.921506355051676, -73.11695337295532)
5 30
(40.914003094456675, -73.11635255813599);
(40.9142904108373, -73.11633110046387);
(40.91532210451524, -73.11895094811916);
(40.91497094536057, -73.11905354261398)
6 15
(40.91528916758866, -73.11872161924839);
(40.916650209067306, -73.11784386634827);
(40.917076858892166, -73.12223598361015);
(40.9159529701723, -73.12291324138641)
7 5
(40.917010480062295, -73.12147490680218);
(40.920812207457075, -73.12064878642559);
(40.9209044231049, -73.12092572450638);
(40.917076858892166, -73.12223598361015)
To determine the location of the vehicle, the software code
determines if the location co-ordinates obtained from the GPS
falls within the parameterized polygons. The logical &&
function in C is used in the following code to perform this
function.
C. Parsing Data from GPS output string
GPS outputs information in various ways. For this project,
Recommended Minimum GPRMC standard output is used.
Output information is sent out from GPS as an array character.
In order to retrieve the information from GPS, first of all, we
have to initialize variables and ports in C as done in Fig. 2.
Figure 2. Code Snippet of variable initialization
Now all the information is sent from GPS can be accessed
throw UCSR1A port. At this point, a list of character array
will be used as a global variables as shown in Fig. 3. Here
each of the parameters of the GPS output string is declared as
a character arrays. The character arrays are declared to be
sufficiently long to hold the parameters.
Figure 3. Code Snippet of declaration of global variables

A function named clear_infomation() will execute at the
beginning of the program to make sure that those character
array are not holding any previous information or data. Then
read_GPS() function will be called which will read the
information from GPS through UCSR port. Once the program
reads character $, G, P, R, M, C and , in sequence,
all the characters after that will be placed in char[32] as time
until another , found as an character. In this the next
information which is data validation character A is put in the
variable named validate. In this way, data for location co-
ordinates and speed are allocated to their assigned character
arrays. A pseudo code of the parsing is given in Fig. 4.
Figure 4. Pseudo Code Snippet of output string parsing





D. Conversion of speed.
The speed parsed from the GPS RMC string is obtained in
knots. As the recommended speed is given in miles per hour,
the speed from the RMC string has to be converted to miles
per hour. As 1 knot is equal to 1.15078 miles per hour, the
speed in mph can be obtained by simply multiplying the speed
in knots by the factor 1.15078. In the program this conversion
is done by the getspeed_mph() function.
E. Experimental Data Obtained
The device prototype was tested in the region shown in
Fig. 1. In order to properly test the device, a fixed procedure
was used in each speed region. For each speed zones, the test
procedure is given as follows:

i) The vehicle was driven under the speed limit to
see if the Green LED indicating safe use is lit.
ii) The vehicle was then accelerated above the speed
limit to see if the Red LED is lit. This will
indicate that the GPS has successfully recognized
the speed zone and indicated if vehicle speed for
the zone is exceeded.
iii) For any speed value, the difference between the
speed calculated from GPS and the vehicle
odometer values are recorded.
iv) The vehicle is driven to a different speed zone to
see if the Blue LED indicating zone change is lit.

Using the test procedures listed, the following experimental
data were obtained.
TABLE VII. EXPERIMENTAL DATA OBTAINED
Speed Zone
(mph)
Odometer Speed when
Red LED blinked (mph)
Percentage Error
Between GPS and
Odometer Speed
5 N/A N/A
15 15.5 3.33%
30 31 6.67%
55 59 7.27%

From the experimental data, some clear conclusions can be
drawn. First, the device did not perform satisfactorily in the 5
mph speed zone. The speed of the vehicle was kept just below
5 mph but the Red LED was blinking nevertheless. This
indicated that the device calibration can be improved in the
lower speed zones. One possible solution to the problem was
achieved by raising the speed limit in the code for the 5 mph
zone to 7 mph zone. Second, the device performs quite
satisfactorily within the other speed zones. But at higher
speeds, there is a greater discrepancy between the GPS speed
and the odometer value. Assuming the odometer speed to be
more accurate, a more sensitive GPS device will reduce the
discrepancy.
F. Simulating the Engine Control Unit.
The information from the GPS is used to display location
and speed information on the LCD screen. At the same time,
the system has outputs that connect to the Engine Control Unit
(ECU) of a vehicle. For the scope of this project, the ECU is
modeled as an external peripheral with several inputs and has
two inputs connected from the system: the Vehicle Speed
Sensor (VSS) and the engine RPM input. Each time the
vehicle exceeds the set point value of speed, the system
outputs signals to these two sensors in order to control the
speed.

The Vehicle Speed Sensor is a square wave generating
input signal where the frequency of the square waves is
directly proportional to the speed of the vehicle. The reference
voltage for the sensor is +5V which is same as that used in our
system. Therefore, the VSS input can be simulated as a square
wave with amplitude of 5V, an offset voltage of 0V and a
variable frequency proportional to speed.

In order to calculate the frequency of the square wave
generated to VSS, the maximum RPM the ECU can read is
assumed to be 9000. This means that the system will be able to
generate frequencies for RPM ranges well beyond the normal
limit. In the ECU, the vehicle speed sensor outputs 2000
pulses per minute for a speed of 1 mile per minute which is
same as 60 mph [5]. So for a speed of 60 mph, the number of
pulses per second is (2000/60) = 33.3 Hz. The following table
lists the frequency of the generated square wave for the critical
speed values for this application.
TABLE VIII. FREQUENCY OUTPUT TO VEHICLE SPEED SENSOR
Speed (mph) Frequency (Hz)
5 2.8
15 8.3
30 16.7
55 30.6

Similarly, the engine RPM input on the ECU determines
the number of revolutions per minute of the crankshaft of an
engine. The RPM input also produces a 5V amplitude square
wave that has a frequency proportional to the number of
engine revolutions. For every vehicle, the speed to RPM ratio
is determined from a number of vehicle parameters. In this
case, we assume the parameters obtained from the owners
manual of a 2001 Toyota Corolla.
TABLE IX. TRANSMISSION GEAR RATIOS AND OTHER PARAMETERS
Parameter Variable
Value for 2001
Toyota Corolla
Transmission Gear Ratio (1st Gear) RT1 3.643
Transmission Gear Ratio (4th Gear) RT2 2.008





Parameter Variable
Value for 2001
Toyota Corolla
Transmission Gear Ratio (3rd Gear) RT3 1.296
Transmission Gear Ratio (4th Gear) RT4 0.892
Differential Gear Ratio RD 2.655
Loaded Tire Radius r 11 inches
Vehicle Speed variable

Thus for a given speed for this specific vehicle, the RPM
can be calculated step by step. The distance the car moves in
miles per hour for one complete rotation of the tire is given by:
((60 minutes)/(636530 inches in 1 mile))2 = 0.0059 (1)
And the RPM for any speed (in mph) at a given
transmission ratio is given by (2):
RPM = ( R
T
R
D
)/(0.0059 r) (2)
Using the equation, the following RPM values were
calculated for the critical speed values in this application. The
frequency of the square wave from revolutions per minute is
given by the multiplying the RPM value with the factor of
1/60.
TABLE X. FREQUENCY OUTPUT TO RPM INPUT
Speed(mph) Gear Ratio (Gear) RPM
Frequency
(Hz)
5 3.643 (1st) 745.2 12.4
15 2.008 (2nd) 1232.2 20.5
30 1.296 (3rd) 1590.5 26.5
55 0.892 (4th) 2007 33.5

Thus every time the speed control system is engaged, the
microcontroller will generate two square waves to VSS and
RPM input with the corresponding frequencies at the given
speed.
G. Calculating Delay Cycles
The program uses several delay cycles to provide measured
delays. The ATMega128 is run at a frequency of 1MHz which
means that each single cycle instruction takes 1s to execute.
At first, the program needs to provide a delay to blink the red
LED at a frequency corresponding to the speed of the vehicle.
An header file named avr_macros.h defines several useful
macros. One such macro is __delay_cycles() where the
argument is the number of the cycles to be delayed. Thus an
argument of 106 delay cycles at 1 MHz frequency will
produce a delay of 1 s. As the red LED will blink faster for
increasing speed greater than the speed limit, the program
needs to factor both the speed and the speed limit as an
argument of the delay cycle macro which is given as:
No. of delay cycles = (10
6
)/(speed speed limit) (3)
As the difference between the measured and the set point
value of speed is considered, the LED blinking frequency will
be the same for different speed limits as long as the difference
is the same. Each delay cycle length will be equal to half of
the blinking period. From the above equation, we can obtain
the following frequency table.
TABLE XI. DELAY CALCULATION FOR SPEED LIMIT
Speed
Speed Limit
Number of Delay
Cycles
Half
Period (s)
Frequency @
1MHz
1 10
6
1 0.5 Hz
2 5 10
5
0.5 1 Hz
3 3.33 10
5
2/3 1.5 Hz
4 2.5 10
5
0.25 2 Hz

The above table clearly illustrates that increasing integer
difference between the two speed will increase the frequency
of blinking by 0.5 Hz.

Generating delay cycles are also necessary to output the
pule train to the vehicle speed sensor and the RPM input. This
can also be done using the __delay_cycle() macro. In order to
output a pulse train of a particular frequency to the vehicle
speed sensor, the number of delay cycles is given by:
No. of delay cycles = (10
6
) / (2frequency) (4)
The frequency is multiplied by 2 as the number of delay
cycles will be equal to half of the time period. The frequency
for the speed limit is given in the Table VII.

Similarly, the waveform to the RPM input is generated by
providing a fixed number of delay cycles and can be
calculated with (4). The frequency values for each RPM value
are given I Table IX.
H. Storing Data in Microcontroller Memory.
The ATMega128 for this project has to store a large
number of data in regard to location, speed, and frequency
information. The MCU has 128Kbytes of In-System Flash
program memory, 4Kbytes of Internal SRAM and 4Kbytes of
EEPROM [2]. The main program will be stored in the Flash
program memory and the location co-ordinates and frequency
information will be stored in the SRAM as variables. As
reading and writing to the EEPROM requires several
instruction cycles and the MCU is operating at 1 MHz,
EEPROM memory will be used only to read data for location
variables outside the initial test area.
IV. CONCLUSION
Based on the experimental data calculated, some clear
improvements can be made to this device. A more sensitive
GPS device will reduce the percentage difference between





GPS calculated speed values and the odometer values. An
improved interface with the ECU can be developed taking into
account other factors such as tire rotation and the angle
climbed by the vehicle. Overall the visual feedback
incorporated in the device, indicator LEDs and LCD,
performed satisfactorily. A wider test area, a more sensitive
device, and improved ECU interface will make this project a
viable accessory in vehicles to improve safety on roads.
V. BIOGRAPHIES
A. Aamir Sarwar Jahan
Aamir Sarwar Jahan is a senior at Stony Brook University
located at Stony Brook, NY. He is pursuing to obtain his B.E
in May 2013. Aamir is a completing his degree with
specialization in microelectronics. He has been serving as the
Secretary of the student branch of Stony Brook IEEE chapter.
He is also a member of Tau Beta Pi engineering honor society
and Eta Kappa Nu electrical engineering honor society. Aamir
is planning to obtain his Professional Engineering Licensure in
the State of New York and will be sitting for the Fundamentals
of Engineering exam in April 2013. He plans to pursue a
career in embedded systems design.
B. Imdadul Hoq
Imdadul Hoq is a senior at Stony Brook University at
Stony Brook, NY. He is studying in Computer Engineering
and pursuing to obtain his B.E in Dec 2013. He is a member of
Golden Key International Honor Society since November
2011. Upon completing him Bachelor degree, he wants to
pursue a career in computer hardware architecture and
embedded system design.
C. David Westerfeld
David Westerfeld is an Assistant Professor in the
Department of Electrical and Computer Engineering at Stony
Brook University. He is the faculty advisor for this project.
REFERENCES
[1] "FARS Encyclopedia." FARS Encyclopedia. National Highway Traffic
Safety Administration, n.d. Web. 15 Dec. 2012. <http://www-
fars.nhtsa.dot.gov/Main/index.aspx>J. Clerk Maxwell, A Treatise on
Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892,
pp.6873.
[2] "ATmega128 Datasheet." Atmel Corporation. Atmel Corporation, n.d.
Web. 15 Dec. 2012. <http://www.atmel.com/devices/atmega128.aspx>.
[3] "Variable Speed Limits." FHWA Safety Program. Department of
Transportation, n.d. Web. 21 Feb. 2013.
[4] B.Karthikeyan and M Tamileniyan. Article:Dynamic Data update for
Intelligent Speed Adaptation (ISA) System. International Journal of
Computer Applications 11(1):813, December 2010. Published By
Foundation of Computer Science.
[5] "EM-406A Datasheet." Sparkfun.com. GlobalSat, n.d. Web. 21 Feb.
2013.
[6] Skaff, Luke. "GM OBD-I ALDL Microcontroller Scan Interface." Luke
Skaff, n.d. Web. 21 Feb. 2013. <http://lukeskaff.com/?page_id=305>.