Presented at GNSS 2004

The 2004 International Symposium on GNSS/GPS

Sydney, Australia
6–8 December 2004

Integrating GPS with Standalone MVEDR

S. Omar
School of Surveying & Spatial Information Systems
The University of New South Wales, UNSW, NSW 2052, Australia
Email: omar@cse.unsw.edu.au

A. Yip
School of Computer Science & Engineering
The University of New South Wales, UNSW, NSW 2052, Australia
Email: ayip247@cse.unsw.edu.au

Alan Yip

ABSTRACT

This project’s aim is to build a totally standalone EDR which can work
independently. In another word the EDR will not be directly communicating
with a car’s electronic system and can work with any vehicle regardless of
circuitry or data difference. Another advantage of such a system is that it
will be harder to temper with. With systems that depend on a car’s data (such
as from its ECU), a malicious intended person can sabotage the car’s ECU
and feed false data into the EDR whereas a standalone EDR could be easily
made more temper proof. The EDR will require a source of data about the
vehicle’s velocity, location and other information, and the main sources of
the data will be from a built in GPS receiver. An internal clock and a FPGA
is used to trigger the GPS receiver’s data output which is then directed to a
memory module for recording purpose. The usage of FPGA is because of the
flexibility it offers for being reprogrammable; a final product using ASIC
could later be investigated to reduce cost when mass produced. The FPGA
will be programmed to communicate data from a GPS receiver through a
serial connection. The data is then directed by the FPGA to a calculated
address in the memory module. As the device only records a certain amount
of time before the oldest data is overwritten, the memory location to be
overwritten will be decided by the FPGA. The embedded core within the
FPGA also provides the calculation to judge when an event would happen.

KEYWORDS: MVEDR, FPGA, Embedded Core Device, Integrated GPS,

Event Data Recorder.
1. INTRODUCTION

Motor vehicle accidents happen around the world, with numerous accidents, small and major,
happening every moment. In New South Wales, Australia alone, there were 49266 recorded
crashes in 2003. The total casualties cause by accidents numbers at 27747, in which 539 were
fatal. This amounts to a staggering 70 casualties per 10000 vehicles registered. (Road and
Traffic Authority, 2004)

When such accident happens, it takes a group of expert investigator to piece the puzzle and
establish the sequence of occurrences. They locate the impact points, determine the crumple
zone, measure the length of skid marks and make other measurements and calculations to
compute the speed of the vehicle and whether it braked or not. But such methods are at most
an educated guess or an estimation of what has happened and is never truly accurate. Thus a
method of accurately collecting data when an accident occurs is required. (Henderson et al
2001)

There are various ways of recording a vehicle’s data. One of the most accurate and direct way
of doing so is the introducing of an EDR (Event Data Recorder). Popularly known as black
boxes, their function is to record a vehicle’s current speed, location and other various data
collected from the vehicle itself. The recorded data, in the case of an accident or similar event,
can be used to rebuild the scene by careful analysis (Faith, 1998).

However such devices are not always popular, especially when it comes to the general public.
They view upon the device as an intrusion into their privacy. They might feel violated or
threatened by the fact that there is a device in their vehicle that records every moment of their
driving, recording their whereabouts at a certain time. There might also be instances where a
person might participate in illegal activities with their vehicle, such as street racing, and
would much prefer if such a device does not exist in their vehicle.

Therefore there is a possibility that people will attempt to disrupt the device, stopping it from
recording any incriminating or perhaps simply any data. Even if a person has no intention to
disrupt such a device, the person might inadvertently stop it from collecting accurate data by
altering parts of the car. A popular way of enhancing a car’s performance is to alter the
program in a car’s Electronic Control Unit (ECU) or to replace it entirely with another unit.
The ECU is a device that controls and manages many functions of a car, it can also be used to
calculate a car’s speed and provide information. Thus there is a chance that the actions will
corrupt the data being recorded. Therefore a way is needed to ensure that the data being
recorded will be safe from any interfering. One way of doing so is to make the Recorder work
on its own without needing any data from external sources.

However, it’s not correct to say that currently there are no black boxes preinstalled in motor
vehicles. In fact, many current models of car have black boxes installed within them.
However they serve a different purpose to recording data for accident investigation. Their
main function is actually to gather information to improve airbag system when an accident
occurs. Major car manufacturers have such black boxes installed in their cars, and are
mentioned in their instruction manuals that such devices are installed for monitoring airbag
performance purposes. However, such black box does not conform to any standards and
collects different types of data for different period of time. Also different methods are
required for the retrieval of data from different types of black boxes. (Harris 2004)
This is the reason why the Institute of Electrical and Electronics Engineers (IEEE) is
proposing a standard for Motor Vehicle Event Data Recorder (MVEDR). Project 1616 is a
standard that defines a protocol for the data retrieval and also to standardise the data output. It
does not actually advice what specific data are to be recorded but provides a unified way of
retrieving the recorded data. This would greatly simplify the process of retrieving data from
the MVEDR. However, it is a new project and a set of standard has yet to be defined.

Privacy is an issue which one has to look at. There are important questions yet to be
answered, such as who is the owner the data stored within the recorder or could the recorded
data be used to prosecute the driver in the case of an accident. California became the first state
in America recently to adopt a law that addressed the issue of black boxes in motor vehicles.
The law requires motor vehicle manufacturers to disclose the fact that a black box is installed
within their car. At the same time, it states that access to data within the black box can only be
granted by either the owner or through a court order. This law goes into effect July 1, 2004.
(Cabanatuan, 2003)

In section 2, MVEDR currently sold by other companies are investigated. Afterwards, the
design and implementation of the device is explained in detail in section 3 and the testing and
results gathered of the implementation is discussed in section 4. Section 5 gives details about
further expansion possible for this device and finally a conclusion is given in section 6.

2. RELATED WORK

There are other devices currently available out in the market. Most of them are used as tracer
or trackers, as in the devices are actually used to monitor a car’s position or where it has been,
rather than recording data that leads to and after an accident. Their function also includes
recording items such as maximum or average speed during a particular trip, and then can be
accessed later on for inspection.

Road Safety RS-1000 is a popular low cost monitoring system that records data through the
OBD-II (On Board Diagnostic) connector. Using the data collected from the connector, it
would record them to be downloaded later onto a computer. It could store over a month’s
worth of data. Apart from being a data recorder, it also serves as a warning device. Under
high speed or high acceleration, the device would emit a warning beep, advising the driver to
slow down.

As mentioned before, the tapping into the car’s circuitry allows a user to temper with it by
feeding it false information. It’s also a tracker, rather than an event only data recorder. It is
used mainly for monitor a driver’s behaviors and serves as a warning for aggressive driving.

DriveCam’s video event data recorder is a video recorder that monitors driving activity and
records sights and sounds both outside and within the cabin of the vehicle. When an event
happens, the images and sounds are saved and can be used later to determine what has
happened. It stores data in a twenty seconds window, ten seconds before and ten seconds after
the triggering event. The device also records the forward and lateral acceleration the vehicle is
experiencing.

The device would make a good event data recorder. It records useful information in the form
of a video of the accident scene. At the same time due to the short period of time it captures
the data, it would offer some protection to the user’s privacy, giving them a peace of mind.
However it can easily be tempered with by having the video camera blocked, thus making the
device incapable of recording data.

LoCATe is developed by Roke Manor Research. It is not a data recorder as such, but is a
tracking device. It uses the GPS receiver to locate itself and then utilise the mobile phone
network to report the position of the vehicle using text messaging. To accompany the GPS
receiver (El-Rabbany, 2002), it employs the SiRFXTrac technology. SiRFXTrac is produced
by SiRF and is software GPS signal enhancer, it would increase the receiver’s sensitivity and
allows GPS receiver to be used in urban area such as in car parks.

LoCATe is used mainly to track the vehicle fleet of a large business, giving the business the
exact location of their trucks and vehicles. This is not a solution for widespread usage of black
box. The amount of data sent from the devices would overwhelm the mobile network. And
also as the location of the vehicles are being constantly sent to a receiving station, the security
of the data will need to be very secured or the user’s privacy and security would be
compromises. In the end, even if the data is secured, the users might feel violated for having
their location being monitored at all time.

Thus the device in this project would be designed in such a way that the data isn’t recorded
indiscriminately and the range of data collected can be used to help in the reconstruction of an
accident.

3. DESIGN AND IMPLEMENTATION

3.1 System Overview

This project is to create a MVEDR that’s standalone and can work by itself without any
external input from the vehicle itself. One way of doing so is the utilisation of a Global
Positioning System (GPS) engine inside the MVEDR. It would provide all the important
information such as speed, co-ordination and headings to the recorder, thus eliminating the
need for the recorder to record data from the vehicle’s sensor, such as the OBD-II connector.

The device would involve a microcontroller that communicates with a GPS device. It would
trigger the GPS and receives data from it. It would then probe the data and records the ones
that it believes to be important. At the same time it would use the data to compute whether an
event or an accident has occurred. When it believes that an accident has occurred, it will
trigger the system to permanently store the data.

However, only a short period of data will be recorded inside the GPS device. This is done to
ensure that a level of privacy is kept. Only twenty seconds of data will be recorded in the
device; ten seconds of data before an event occurs and another ten seconds after. The twenty
seconds length of data should be long enough to allow a reconstruction of what happened.
This makes sure that the recorder is not recording data indiscriminately and can be exploited
to trace the vehicle’s location for a longer period.

A computer can then be used to retrieve the data stored inside the memory. The computer will
connect directly to the device and will send a signal to trigger it. The device will then offload
its content to the computer, which can then be read and used for analysis
3.2 Design

In order to fulfil the requirements set upon the device, a circuit that reads from a GPS engine
and record the data into memory. In order to rapidly develop and create prototype cheaply,
FPGA (Field-Programmable Gate Array) is employed in this project. The use of a FPGA
allows quick changes in circuit and can then be checked quickly to verify it is operating
correctly.

Thus the major physical components of the device would involve a FPGA and a GPS engine.
Below are devices and components used in this project. Information and description about
them and how they are to be used are given below.

3.2.1 FPGA

FPGA is used in place of a circuit. As a single chipped system is preferred, the

microcontroller is therefore integrated into the processor. If an external processor is used,
CPLD (Complex Programmable Logic Devices) would be a better choice as it has shorter and
more predictable I/O delays due to its coarse-grained nature. However, an embedded core is
to be used in this design. A FPGA is required as CPLD generally does not have the ability to
support embedded core. An FPGA gains its flexibility due to its fine-grained nature (Brown
and Rose 1996)

Another advantage of using FPGA for design is that it can later on be transferred onto an
ASIC (Application-Specific Integrated Circuit) when mass production is required. ASIC are
generally cheaper to implement when over ten thousand devices are to be produced. This
would further drive down the cost of production of the device, making it cheaper and
therefore more appealing to car manufacturers.

The FPGA chosen for this project would be the Xilinx Spartan 3 (Bout, 1998). This device is
chosen due mainly to the fact that it’s inexpensive and at the same time it provides enough
bandwidth and logic units for the circuit required. Altera’s Cyclone would be another FPGA
suitable for this project. However after considering equipment availability and previous
experience with the free Xilinx ISE, a decision is made to choose Xilinx as the FPGA
producer. Cost effectiveness is important in such a device in the ever competitive
environment of vehicle manufacturing. In order for vehicle manufacturers to adapt such a
device into their car, it has to be as cheap as possible otherwise it would increase their cars’
production cost and lower their competitiveness.

The Spartan 3 is also a low power consumption device and also has a high level of noise
immunity. This is an important consideration into choosing the device, the device have to
work in a high noise environment within the car’s myriad of circuitry, thus high noise
immunity is required to ensure no data corruption. Also in the event of an accident, the device
might lose power from the car’s power supply, requiring it to be ran on battery, thus the fact
that it consume as little power as possible is important to ensure that it continues to record
data and also that the data will not be lost. (Xilinx, 2004)
3.2.2 GPS

The GPS receiver chosen for this project is the Garmin GPS-18. Garmin is a well known GPS
receiver manufacturer. The company is a forerunner in GPS technology, designing some of
the first consumer GPS receiver and its receiver are in used by the military themselves. After
factoring in the cost, the availability of a device and the amount of data the receiver would
provide. It’s deemed that the GPS-18 is a very cost effective device. Being an OEM solution,
it’s relatively low in price and also allows multiple configurations to choose from.

It is a self enclosed device, meaning that every component within the device is encased inside
an enclosure, minimising the chance of it being damaged by external objects. It also has a
built in antenna, removing the need to use an external antenna.

Figure 1. GPS 18LVC Serial Port Interconnection (Garmin International, 2004)

It only requires 5v to drive the GPS and using only 60mA, a low consumer in power. It can
also operate in a high range of temperature, from -30ºC to 80ºC. Making it suitable for an in-
car environment where temperature can be high in areas such as the engine bay. Another
feature of a LVC component is that the serial signal it transmits is a TTL signal, thus allowing
a direct connection between the receiver and the FPGA without requiring another component.
This would further reduce cost and also power consumption. (Garmin International, 2004)

The GPS-18 also provides a wealth of data, and does so every second, providing the device
with a high enough resolution to be used for analysis in the case of an event occurring. It
transmit data in several formats, the one that will be used is the Recommended Minimum
Specific GPS/Transmit Data (RMC). An advantage of the GPS-18 is that it adheres to a very
strict format when transmitting data. It will be transmitted from the receiver in the following
format.

$GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>*hh<CR><LF>
<1> UTC time of position fix, hhmmss format
<2> Status, A = Valid position, V = NAV receiver warning
<3> Latitude, ddmm.mmmm format (leading zeros will be transmitted)
<4> Latitude hemisphere, N or S
<5> Longitude, dddmm.mmmm format (leading zeros will be transmitted)
<6> Longitude hemisphere, E or W
<7> Speed over ground, 000.0 to 999.9 knots (leading zeros will be transmitted)
 <8> Course over ground, 000.0 to 359.9 degrees, true (leading zeros will be transmitted)
<9> UTC date of position fix, ddmmyy format
<10> Magnetic variation, 000.0 to 180.0 degrees (leading zeros will be transmitted)
<11> Magnetic variation direction, E or W (westerly variation adds to true course)
The “hh” are the checksum of all characters between “$” and “*” and is an exclusive-or sum
of them. (Garmin International, 2004)

For example, it is UTC 3:15:20 pm on October 20, 2004 and we are located at latitude
33º55’24” south and longitude 151º17’03” east. We are travelling at 110 km/h heading
exactly west with a magnetic variation of 0.3º east. Then the format of the data sent will be:
$GPRMC,151520,A,3355.4000,S,15117.0500,E,059.4,270.0,201004,000.3,E*66
Followed by the carriage return and line feed characters.

3.2.3 Connectivity

In order for the FPGA to communicate with the GPS and a computer, a serial connection
between the two of them has to be implemented. The physical component requires a D-9 RS-
232 connection. In order to produce the required signal voltage from the system board, a
max232 chip will be used as a RS-232 level converter.

The max232 converts a ±10 volt RS-232 Logic Waveform to a +5V TTL/CMOS Serial Logic
Waveform. It does so by using two internal charge-pumps converter. One of the converters
doubles the input voltage level from +5V to +10V using the C1 and C3 capacitors. The other
is used to invert a +10V to -10V using the C2 and C4 capacitors (Maxim, 2000)

A schematic of how the chip is connected with the device and its accompanying capacitors
used is shown in Figure 2.

Figure 2. Schematic of max232

The TTL Out will be connected to the output port on the FPGA and the TTL In will be
connected to the input port on the FPGA. The 100 resister is placed in series with the TTL
In to protect against logic conflicts. Pin 2 on the D-9 is the Transmit Data (TXD) signal, Pin 3
is the Receive Data (RXD) signal and Pin 5 is the signal ground.

The serial port is connected in a Null Modem configuration. Pin 4 (Data Terminal Ready), Pin
6 (Data Set Ready) and Pin 1 (Carrier Detect) are interconnected and similarly Pin 7 (Request
To Send) and Pin 8 (Clear To Send). This is done so that the computer would believe that it’s
communicating with a modem and sends data without waiting for the required request and
clear signals. (Putman, 1987)

3.3 Implementation

3.3.1 Design Software

Altium Protel DXP 2004 Service Pack 1 is used to design and implement the device.
Installation of the Xilinx ISE 6.3i Service Pack 2 is required to compile FPGA design from
either schematic or VHDL into bit stream and then programming the stream into the FPGA
via JTAG. Xilinx ISE is available for free download as part of its WebPack after free
registration with its website. DXP 2004 allows the integration of the compilation process into
its software by interfacing the Xilinx ISE itself.

3.3.2 Design Drawing

Designing of the required components within the FPGA silicon is done using DXP 2004. The
Tasking Z80 (TSK80) embedded processor as the controller of the device. The TSK80 is an
8-bit embedded processor with an instruction set that’s compatible with the Zilog Z80
microcontroller. It provides hardware interrupts and necessary interface to address external
I/O peripheral devices. The Zilog Z80 is chosen because it is a popular processor used in
many other systems and devices as microcontroller, thus it has a large support base available.
The ease of programming with interrupts with the microcontroller is also another reason why
the processor is chosen. All embedded cores provided with DXP 2004 are royalty free thus
the employment of the TSK80 is free. (Altium, 2004)

A SRL0 is used to provide UART (Universal Asynchronous Receiver/Transmitter)

functionality in order for the TSK80 to communicate with a serial port. It offers a one byte
buffer and would trigger an interrupt in the case of a successful transfer or receive. It also
allows a variable baud rate thus making communicating much easier. It can be accessed when
the 15th bit of the address sent by TSK80 is 1 and 14th bit is 1. (Altium, 2004)

The SRL0 has a series of registered used to setup the device and also to act as data buffer for
sending and receiving data. The registers that are used in this design and a brief description of
their functionalities are given below: (Altium, 2004)
• Power Control - Controls whether the baud rate is to be doubled
• Serial Interface Control - Define the operational mode of the serial interface and
controls whether reception of data is enabled.
• Serial Data Buffer - This serve as a buffer for transmitting and receiving data.
• Baud Rate Generator Reload - Defines the default data to be loaded while generating
the baud rate.
• A/D Converter Control - Determine whether an internal Timer unit or the Internal
Baud rate Generator is used.
Figure 3. Schematic drawing of the design
Another component working in conjunction with the microcontroller is the FPGA Start-up. It
has an 8 bit delay which means that 256 clock cycles will be passed before the TSK80 starts
up, thus allowing all other interconnection and components to be readied before letting the
TSK80 to start operation. A test button is also connected to resets the TSK80 in the case of a
software malfunction. (Altium, 2004)

Two random access memories are used to store program and data for the TSK80. Two
memories are used to keep the recorded data away from the program, thus ensuring that the
memory address of the data stay constant no matter how much the program has changed. This
also allows an external memory to be addressed later on if required, rather than one residing
within the FPGA. The external memory can be made more robust and non-volatile and also
allows easy access to data if the FPGA failed, data can be read straight from the external
memory.

The 16KB memory, RAMS_8x16K, is used to store the coding within the embedded
processor. The program when compiled into HEX requires 11KB of memory space. The 4KB
memory, RAMS_8x4K, is used to store data recorded from the GPS device. The second
memory is accessed when the 15th bit of the address is 0 and 14th bit is 1.

A switch is also implemented to mimic external signals. As this device is a data recorder,
there might be other information that wants to be recorded, such as seatbelt usage or other
form of data. There could also be instances where another device might want to make a log of
what is happening at a certain instant. This includes another project running concurrently at
UNSW with this one. The Red-Light Running Detector, being designed by another student,
sends a triggering signal to my device, asking it to store an instance of data for when a traffic
offence has been committed. When such an event occurs, the signal will be used as a trigger
rather than a data unit, how this is to be implemented will be described later in the embedded
process section. The switches can be accessed when the 15th bit of the address is 1 and the 14th
bit is 0.

Two binary 2 to 4 bit decoders with enable, the D2_4ES U_WR and U_RD, are used to
control the write and read enable of the various peripheral and memory. They are used this
way to allow the TSK80 to addresses each device, storing data in the memory or sending data
over the SRL0.

A 4x8 bit to 1x8 bit bus multiplexer, M8_B4B1 U4, is then used to allow the data to be
returned to the TSK80. Thus any data that the TSK80 is trying to access from the memory,
reading from the switches or any data being received by the SRL0 can be send to it.
A system clock of 10 MHz is required and should be provided through the clock input
(CLK_BRD).

All these components and their interconnections are shown in Figure 3.

3.3.3 Embedded process

The basic overview of what the program does is that it will read from the GPS, only recording
data which it thinks is important. It will also at the same time calculate the acceleration of the
car. When a high acceleration is detected, an event would be considered to have occurred, it
would trigger the controller to store the pass ten seconds of data and collect another ten
second of data before switching off and wait for a transmission to occur. At the same time, it
will read from a series of switches, they could be used as normal data unit. However there are
other instances where the switches will be used as a trigger.

The first thing the program does is to setup the SRL0 unit. It does so by sending configuration
details using the specially allocated addresses. After doing so, the program would initiate and
goes into an infinite loop.
• PCON - 0x80 00000000
• SOCON - 0x50 01010000
• SORELL - 0xDF 11011111
• SORELH - 0x03 00000011
• ADCON - 0x80 10000000
This sets the SRL0 such that it allows a baud rate of 4800 using its internal baud rate
generator and enables the reception of serial data. (Altium1, 2004)

The address spaces of the design are accessed in the following way, the resulting 15th and 14th
bit of the TSK80 address bus is given: 15th bit 14th bit
• 0x0000 to 0x3FFF - Program and program data memory 0 0
• 0x4000 to 0x4FFF - Recorded data memory 0 1
• 0xC000 - Switches 1 0
• 0x8000 to 0x8008 - SRL0 registers 1 1

While it’s in the infinite loop, it awaits for an interrupt signal at address 0x66. When an
interrupt signal is triggered, the processor reads data from the SRL0 unit through address
0x8002. Every time a data transfer is done, the SOCON is invoked to reset its flag to allow
further transmission.

Once the data is read, it starts looking for the appropriate header. When it founds the
appropriate header, “$GPRMC”, it would start recording all data available from it up to until
carriage return and line feed characters, “<CR><LF>”. The characters signify the end of the
data transmission under the header and another group of data will be transmitted.

The base data are recorded at address 0x4000 and slowly builds up. Each GPRMC sentence is
62 characters long. Thus the maximum span of the data will reach 0x44D8. While recording
the data, the processor identifies two components of the data stream required for calculating
acceleration, these two components being the ground speed and the heading. As C works in
radian, the heading needs to be converted to radian.

Using the cosine rule, one can then calculate the exact acceleration. First however, the
difference between the two headings is flipped by 180º to calculate the difference rather than
the summation of the two speed vectors. Then the cosine rule can be applied to calculate the
difference between the two speeds, thus working out the acceleration. If this figure is above a
certain threshold, an event flag will be triggered. The latest ten seconds of data will be
permanently stored and another ten seconds will be recorded.

Every second, the processor will poll the inputs at 0xC000. These are the inputs that are
provided by the switches. They could be replaced with other signals and can either be used as
data to be recorded or as triggers of events. In this instance, it is used as a trigger to record an
extra slot of data when the 7th bit is 1. The data is stored at address 0x47D0, 2000 bytes away
from 0x4000, well away from the twenty seconds of data to be recorded in an event.
Afterwards, the processor will remains in an infinite loop, waiting for the computer to send a
“!” character, which would trigger it to send the computer the data within its memory. The
downloaded data will allow the user to analyse the data.

4. TESTINGS AND RESULTS

Testing was done iteratively. Each component was tested and the complexity of the test unit
was increased gradually. This allows quick and easier debugging as the problem can be
pinpointed quickly in the smaller parts and fix before testing other parts and putting all the
separate parts together.

4.1 Testing the GPS Data

The GPS receiver is also tested, testing the GPS data is another trivial but necessary exercise.
Garmin’s software, available from their website, is used to check whether the GPS receiver is
functioning properly and that the connection made for it, following instructions from
Garmin’s specification, is correct. After checking to ensure that the receiver is communicating
properly with its own software, its data is then captured using HyperTerminal. Under
HyperTerminal the data received were shown on screen as bare characters. This allows the
sentences to be studied first hand and make sure that there is no misunderstanding of the
specification from Garmin.

4.2 Testing Embedded Codes

In order to test the code of the embedded processor efficiently, rather than transferring the
code into the FPGA and test from there (Meyer, 2001), a quicker way was devised to test the
validity of the code. As the codes are written in C, a C compiler can be used to compile the
code and determine whether it’s acting correctly. However some of the codes are needed to be
replaced, this includes the way the program is receiving and transferring data. The interrupt
driven function was replaced with a getchar() for receive and printf() for transfer of data.

Two main functionalities were tested on the data. The codes were first tested to make sure
that it is recording the correct data sentence. After validating that it is indeed recording the
correct data, the testing of whether it is storing the correct twenty second window of event
data is then commenced. GPS receiver messages (Xu, 2003) collected from the
HyperTerminal testing session mentioned above were used as input.

Many errors were indeed found in the program and they can be quickly corrected before final
compilation and transfer the program into the FPGA. This gives a higher confidence that the
embedded code will work inside the FPGA.

4.3 Testing implementation on Virtex.

A Virtex was provided at later stage to test the implementation. However, due to the fact that
it has limited memory space, only 8KB worth of memory, the program needs to be scaled
down. The program as mentioned before requires approximately 11KB after compiling into
binaries. However, another 2KB is required to store the data recorded from the GPS receiver,
thus the program needed to be scaled down in order to fit inside 6KB of ram. The 6KB of ram
is created by choosing an 8KB memory unit but limit its data depth to 6144.

To do this the cosine rule from the calculation of acceleration is removed and is replaced with
a much simpler one. This reduces the amount of memory required and can now fit within the
6KB of ram. The reason of the drastic reduce in memory is that the cosine rule requires the
cos() function. The cos function in terns requires the math.h library and the inclusion of it
pushes up the memory usage. At the same time, to adapt to the 2KB data memory, the extra
data address is moved closer to the max recorded data address.

After compilation of the design and loading the program into the FPGA, testing was
performed on the device. A problem is found when the serial port is swapped between the
GPS receiver and computer. It seems to have lost sync at times when the serial port is hot
swapped, however serial devices are supposed to be hot swappable and can be disconnected
and reconnected any time as long as the correct baud rate is maintained. Yet this does not
seem to be the case.

When only the computer is used and imitation GPS sentences are sent it seems that the device
is working properly. However this would be a similar testing method to above using a C
compiler thus isn’t fully indicative that the device is functioning correctly.

However, due to time constraint, a proper solution to the problem isn’t found. Yet from the
results, it’s believed that the design is functioning as intended. The FPGA is recording data
from the GPS receiver and then offloading it when requested.

One way of fixing the hot swap error is to implement two separate serial ports, thus
eliminating the need to swap the two connections, however due to design and hardware
constraints this was not implemented thus the hypothesis cannot be verified.

There are also other issues involving the inability to fully test my program as part of it is
required to be removed due to memory constraint of the Virtex. As mentioned before, due to
limited memory the program has to be scaled down, thus eliminating the proper calculating of
acceleration and reduce it to a much simpler one.

While prove of concepts coding using a normal C compiler confirms that the coding is
working. However under the FPGA environment this would not be totally certain as race
condition might appear, the program might still be calculating the speed when the next set of
data appears, thus producing programming error. However, from the result shown, it does
appear that the fundamental aim of recording data is achieved.

5. FUTURE EXPANSION

There are however functionalities and features of the current design that could be improved.
These are listed below.

5.1 Higher Resolution

A higher resolution helps in reconstructing the event scene. If the device can receive data at a
much higher frequency then it would increase the resolution. However, the cost of
implementing a high resolution GPS would lead to a very expensive device. A ten signal per
second resolution would cost in excess of one thousand Australian dollars. Thus a
compromise needs to be reached, where only data that are determined to be important will be
recorded at a high resolution, and less important data will be recorded at a lower one.
Acceleration figure is a data that’s deemed to be important. It was recommended by IEEE to
be collected at the rate of ten times per second.

The employment of accelerometers will allow the figure to be collected at a high resolution
while keeping the cost down, however they are quite expensive. As there is another student
that’s designing a car black box using camera and accelerometer, using the sensors would be a
redundant exercise. Thus the implementation of accelerometer is left for further development
and instead concentrating on using data collected from the GPS.

5.2 Extra Sensors

Extra sensors can be added to the device. As discussed earlier, extra input can be given via
input ports by replacing the switches with actually physical sensors. Thus a seatbelt sensor,
such as ones using Hall-effect sensors produced by Allegro, can be used to send information
about whether it’s latched properly, sending a +5V for being latched and 0V for disconnected.
These data can then be recorded by the device every second. Other sensors such as the
Occupant Weight Sensor (OWS) can also be connected to the device, recording the weight of
the passenger.

5.3 Dongle Functionality

Finally, to ensure that the device cannot be disrupted by simply removing it from the vehicle
or by cutting its power, a security code can later on be implemented. This would act as a
dongle that continuously sends the security code to the vehicle. The car’s ECU can use it to
verify whether a MVEDR is connected and if it finds that the code is absent then the ECU
will prevent the car from being operational.

To further provide security and to disable the possibility that a person would provide a fake
code to the ECU, pretending that the device is connected, the device can send the speed it’s
recording through the GPS receiver to the car’s ECU. The speed can be encrypted and can
only be decrypted by the car’s ECU. If the ECU, after comparing its own speed through and
the device speed has found a substantial difference then it can prevent the car from being
operational.

These expansions however are beyond the scope of the fundamental aim of this project thus is
left out.

6. CONCLUSIONS

Thus in conclusion, the device would hopefully be used widely in vehicles. The data recorded
will be a valuable asset in solving an accident and putting the person liable responsible. The
black box recording of twenty second window of an accident would hopefully make it more
acceptable to the general public while still providing enough information for an investigator
to reconstruct the accident scene.

As well, the fact that it is standalone means that the probability of it being tempered with is
minimised. It also does not record data from a car’s sensors and circuitry, thus reading from
connectors such as the OBD-II isn’t required. The OBD-II sensor is used originally for
diagnosing a car’s engine, to make sure that its emission is within standard. There are many
versions of it, using different protocols. The usage of a GPS minimises the chance of the
sensors are being inaccurate, thus ensuring that the data it receives is as accurate as possible.

It also means that the device can be used in a wide variety of motor vehicles, even vintage
cars that do not have on board computers and relies on older technology such as carburettors
to deliver fuel. The device would still work in such cars where recording data – required by
that a black box – wasn’t be able achieved with their existing sensor system.

REFERENCES

Roads and Traffic Authority, NSW (2004) Road Traffic Crashes in NSW - 2003
Henderson J, Whittington C, and Wright K (2001) Accident investigation: the drivers, methods and
outcomes.”
Faith N (1998) Black box: the further investigations
Bout VD (1998) The practical Xilinx designer lab book
Meyer-Baese U (2001) Digital signal processing with field programmable gate arrays
Brown S, and Rose J, (1996) Architecture of FPGAs and CPLDs: A Tutorial IEEE Design and Test
of Computers, Vol 13, No. 2, page 42-57.
Putman BW (1987) RS-232 simplified: everything you need to know about connecting, interfacing,
and troubleshooting peripheral devices
Xu G (2003) GPS: theory, algorithm, and applications
El-Rabbany A (2002) Introduction to GPS: the Global Positioning System
Michael Cabanatuan (2003) Law guards use of vehicle data/ Carmakers install ‘black boxes’ to get
accident information San Francisco Chronicle Tuesday, September 23, 2003
Altium (2004) TSK80x MCU Core Reference CR0117
Altium 1 (2004) SRL0 Serial Port Unit Core Reference CR0111
Garmin International (2004) GPS 18 Technical Specifications
Xilinx (2004) Spartan-3 FPGA Family: Complete Data Sheet
Maxim (2000) +5V-Powered, Multichannel RS-232 Drivers/Receivers MAX220-MAX249 Data
Sheet
Harris Technical Services (2004) Motor Vehicle Event Data Recorders List of all American
manufactured vehicles equipped with Event Data Recorders, available at
http://www.harristechnical.com/downloads/cdrlist.pdf