Redundant Alarm Omitter – R



Redundant Alarm Omitter – R.A.O. Speedwagon

-The Intelligent Radar Detector-

FINAL REPORT

June 1st, 2001

Group I

Travis Rothlisberger rothlis@cs.washington.edu

              Phuoc Nguyen phuoc@cs.washington.edu

              Daniel Allen dsallen@cs.washington.edu

             Alex Chiu alexch@cs.washington.edu

COVER LETTER

The R.A.O. Engineer Group

Department of Digital Design

4321 S. Street St.

Seattle, WA 98118

June 1st, 2001

Chris Diorio, Chief of Engineers

The Diorio Corporation

1234 N. Avenue Ave.

Seattle, WA 98127

Dear Chris Diorio:

We, the R.A.O. Engineer Group, are happy to present to you our final report on the R.A.O. Speedwagon project. We found that the idea was very interesting; and we were more than happy to work on the project.

With the support from the laboratory manager, Christopher Morgan, we were able to get all the parts we needed on time. We were able to design, implement and finish all the verification a week before the time line. Along with this letter, we attached a product brochure, an executive summary and the complete report of the project.

After a full testing, we found the product is now completed and meets all the requirements. However, to ensure the quality of our product as well as our company’s reputation, we recommend some further in-field testing to gain feedback from users on usability and performance. Then, if appropriate, the company should quickly produce and market it to take advantage of the market since none of our competitors has promoted such a product.

We would like to thank you again for your idea of the project in the first place. We enjoyed designing and implementing it. And we hope that you will also enjoy our fabulous R.A.O. Speedwagon as you try it.

Sincerely,

Phuoc Nguyen, Senior Engineer

The R.A.O. Engineer Group

Ps. Please disregard some fake aspects of this report that are required for the TC class.

PRODUCT BROCHURE

[pic]

EXECUTIVE SUMMARY

INTRODUCTION

This report is a summary of the whole project, the Redundant Alarm Omitter (RAO) project, performed by our group, the RAO Engineer Group. The module was built from the idea of a smart alarm detector that can distinguish and ignore the false alarm signal. The idea was raised by the Chief Engineer -Chris Diorio- as he observed that the market was lacking of products that perform such functionality. The module was designed, implemented and tested in ten-week project.

After the first two weeks, the module’s functionalities and user interfaces were completely designed. The module was designed to be able to detect a wide band of radar-signals as a regular detector and at the same time, keep track of the vehicle’s location. In this way, the module should be able to locate the each area where the radar signal comes from. Then, the module provided the user the ability to ignore a specific area to be identified as a false source, or to restore that location through a set of buttons. The module was also able to automatically ignore the radar signal if the user was driving at a safe speed: below 20 mph.

The next five weeks was used to configure the parts, build the circuit, implement and test specific components. The module’s components were compiled successfully at the end of week eight. At the end of week nine, the whole module was completely tested both in lab and in field. The project was finished successfully in 9 weeks.

DESIGN AND IMPLEMENTATION

With the specified functionalities, the module was developed based on two complete products: a regular radar detector and a Global Positioning System (GPS). The radar detector picked up radar signal. The GPS collected the vehicle’s coordinates. The XSV-300 Xilinx board was used to store these locations as well as to execute the logic to determine when to ignore a signal, when to store a location, how to figure the omitted area, how to restore an omitted area.

The GPS was able to update the location every second and sent it out in ASCII format. An 8051 Atmel micro-controller was used to parse these data before sending it to the XSV-300 board to process.

The radar detector was opened and rewired so that it sent the a-radar-picked-up signal to the XSV-300 board. The XSV board then processed this signal along with the current location received from the GPS and micro-controller; and then, decided whether or not to set off the alarm (send signal to the speaker).

The Atmel micro-controller, running at 32 Mhz, was configured to receive data from the GPS at 9600 baud rate. It parsed these data and stored them in a 10 bytes buffer before sending it to the XSV board using the handshake algorithm to ensure the completion of the transaction.

The FLASH memory and the Xilinx FPGA are the two components of the XSV board used in this project. The FLASH was used to store the location of the omitted area. The FPGA was used to control, i.e. to store entries, check entries, erase memory, set off alarm, etc.

ANALYSIS AND TESTING

The code for the micro-controller took 4.88 KB in a 20KB maximum constrain. It took the micro-controller 322 (s to execute these 1434 assembly instructions. However, it was still fit in the 1-s-data-update period from the GPS.

The code for the FPGA took 50% of the available slices made it fit into a 300K-gate requirement. The FLASH with 8 KB RAM was able to hold a maximum of 255 32-bytes entries. The FLASH runs at 10MHz. Since there are a maximum of 255 entries stored, we can look through the entire list in 1,020 clock cycles, which is only 102 microseconds. We had set forth a requirement to be able to perform the calculations in less than 100 milliseconds. This is several orders of magnitude less than that and thus should not affect the driver’s ability to slow down in the presence of an alarm.

Using the hyperterminal (to generate data) and logic analyzer, we were able to test the data output of the micro-controller and made sure data was parsed, stored and sent correctly.

Our initial testing of the FPGA was on a module-by-module basis. The Handshaking Module, Min/Max Collector, Flash Controller, and Cache Controller were each tested individually using the Xilinx simulator and/or logic analyzer. Using the logic analyzer to monitor data, each module was first tested with simulated data, then, with each other to verify that all modules were working together.

CONCLUSIONS AND RECOMMENDATIONS

At this point, the product was completed in term of design, implementation and in-lab testing. Though, we had performed some on-street testing, we still recommend some more in-field testing to gain feedback from the users and to ensure the product’s usability and performance. Then, we recommend that the product should be produce quickly to take advantage of the market.

REPORT

TABLE OF CONTENTS

I) Abstract Page 11

II) Introduction 11

III) Requirement 13

IV) Parts 17

V) Design and Implementation 18

VI) Final Analysis 31

VII) System Performance and Testing 34

VIII) Addressing Reviewers Comments 35

IX) Reference 37

X) Conclusions 38

XI) Recommendations 39

I – ABSTRACT

This report shows the complete design, implementation and testing of the Redundant Alarm Omitter (RAO Speedwagon) product. The system was built based on an 8051 Atmel micro-controller, an XSV-300 Xilinx board and two complete products: a standard radar detector (Whistler 1140) and a Global Positioning System unit (Trimble ScoutMaster). The final product allows the user to ignore radar signals that come from false sources.

To perform the task, the RAO keeps track of the vehicle’s coordinates all the time through the GPS. The micro-controller transforms these coordinates into an appropriate format. Whenever a location is chosen to be a false alarm source, its coordinates are stored in the XSV board. The alarm is only set off if the signal that the radar detector picks up does not correspond to an omitted area. The system is configured to use the FLASH memory in the XSV board to store a maximum of 255 entries. The radar detector is rewired to send the alarm signals to the XSV board instead of the speaker, which is now controlled by the XSV board. The GPS sends data directly to the micro-controller through an RS-232 cable. The whole module’s physical electronic characteristics were manually measured, calculated and verified. Connections and communications between submodules: GPS, radar detector, micro-controller and XSV board were tested and verified using a logic analyzer and performance tests.

At this point, the product’s design, implementation and testing are completed. We recommend that the RAO should be produced and marketed after more extensive in-field testing to gain feedback from the users about usability, performance and reliability.

II – INTRODUCTION

There are many radar detectors on the market today. All of them provide the same basic functionality. The detector is a passive device, simply listening for a signal it believes is that of police radar. Upon receiving such a signal, the detector sounds an alarm to warn the driver to check the current speed. However, there are many devices that operate at or near frequencies commonly used by police radar. The problem is that regular radar detectors encounter them all.

These other devices cause false alarms that can be bothersome to the driver. The Redundant Alarm Omitter, or R.A.O. Speedwagon, is designed to eliminate many of these alarms by utilizing the fact that most false alarms occur on a regular basis in the exact same location.

For example, assume that you drive past a convenience store everyday on your way to work. Every time you drive by, their automatic door opener sets off your radar detector. The first few times, it is a mild nuisance. However, after a few weeks of listening to your radar detector go off at the same spot, you shut it off. You have eliminated the annoyance, but also eliminated any chance of detecting a real radar signal along your way to work.

What you really want to do is to tell your radar detector to ignore this one particular signal, not all signals. The R.A.O. Speedwagon solves this problem by utilizing the Global Positioning System (GPS) to track the coordinates of the false alarms. An “ignore” button is added to the radar detector so that when drivers hear an alarm from a signal they know is false, they simply press it. Thus, the radar detector is trained to ignore alarms at that particular location.

At a somewhat lower level, the radar detector simply does the following upon receiving the signal. First, it checks with the GPS to get the coordinates where the signal initiated. Then, it looks through a table of coordinates it knows it needs to ignore. If it finds that it is within the set tolerance of one of those ranges, it turns on an LED notifying the user that it is in a “silent” zone and the audible alarm is not sounded. If however, the current position is either not known or not found to be in the ignore list, the alarm is sounded as normal.

At this point, the driver can either slow down and heed the warning or depress the “ignore” button. If the latter is the case, the radar detector will enter the start and stop coordinates of the alarm into the ignore table. Future alarms at this location will be ignored as described earlier. Due to limitations of the GPS system, worst accuracy is limited to about 100 meters. This tolerance will be built into the system.

In addition to ignoring locations, the system also provides the ability to restore a previously ignored location. This is accomplished either by pressing the “restore” button when a user notices he/she is in a silent zone, or by allowing the device to “autorestore” the location. When the user leaves the unit in “autorestore” mode, the system will constantly compare coordinates to locations that are ignored and if it notices that an ignored location consistently doesn’t have an alarm anymore, that location will no longer be ignored.

In this final project report, we will first talk about the requirement and the detailed design of each component in our project. Those two sections will provide a good idea of what our project does and how we approach it. The complete pin out and parts are also included in the report. In the analysis and testing sections, we show how each component was carefully analyzed and tested in order to prove that our project actually works. We will list the main design issues we think we may encounter, and we will also answer all the reviewers’ comments. Finally, the conclusion, the recommendation for our final product, and the technical reference will be at the end of this final project report.

III – REQUIREMENTS

Since this device obviously must fit into a car, there are some firm restrictions we must obey with respect to size, power, and usability. Notably, we must ensure that this device does not interfere with user’s ability to safely drive a car. Its use should not detract attention from driving more than the use of a typical radar detector. Table 1, below, shows these basic parameters along with the values we have measured for our final device.

Table 1. Vehicle Constraints

|Specification |Maximum |Minimum |Typical |Our Device |

|Power Source1 |  |  |  |  |

|--Connection Type |- |- |- |Cigarette Lighter |

|--Voltage |14.6 Volts |11.0 Volts |12.0 Volts |12 Volts |

|--Current |3 Amps |- |- |1.5 Amps Max |

|Size (On Dash) |  |  |  |  |

|--WidthxLengthxDepth |Must Fit on Typical Car Dash |6”x8”x2”2 |

|User Interface |  |  |  |  |

|--Input |Must Not Interfere with Driving |3 Buttons |

|--Output (Audible) |Must Not Interfere with Driving |Audible Alarm |

|--Output (Visible) |Must Not Interfere with Driving |Several LEDs |

1 Values taken were for a Honda Accord. Slight variance may occur for different vehicles.

2 The size could easily be reduced. Our prototype is limited by the fixed size of the proto-board.

As you can see, our device should not affect driving beyond that of a typical radar detector. We estimate its size and power requirements to be only slightly larger than that of a typical radar detector. The power source will come from the vehicle’s cigarette lighter adapter. Figure 1, below, shows the pinouts for that commonly used system.

Figure 1. Cigarette Lighter Adapter Pinouts

Initially, we concluded that the RAO device should be able to store at least 100 locations. Considering that drivers spend most of their time within 10 or 20 miles of home and false alarm sources are usually not any more dense than one per mile or so, this seems like a reasonable number of entries to store. In the course of the design, we found 255 to be a reasonable and easily implemented number of locations.

We would have liked our device to be as accurate as possible, but considerations for variances in signals and GPS accuracy limitations have led us to use a 100m buffer zone all around a stored location. We feel that building in a buffer of this size will not adversely effect the operation of the device. This leaves a small zone around known alarms that is not protected, but should not leave a very large unprotected area for the driver.

Nearly as important as the vehicle’s interface is signal response for radar detection. Table 2 below lists typical police radar frequencies as well as our unit’s ability to detect them. The R.A.O. unit detects all common signals in use by police radar.

It should be noted that laser radar does not usually result in false alarms. Only a few devices such as Terabeam transmitters operate in this range. Also, laser is very narrowly directed compared to radar, making false alarms less common. Due to the layout of the lights on our radar detector, laser radar cannot be ignored. However, due to the lack of false alarms of this type, we do not see this as a major limitation. The presence of a signal is sensed via a 5V, active-low signal, which is used to drive a pair of LEDs on the modified radar detector. This information will be routed directly to the FPGA for processing. The radar detector we are using is a Whistler 1140, which requires a 12 VDC (250 mA) power source that we will wire directly. We have limited information on the functionality of this device.

Table 2. Police Radar Specifications

|Band |Frequency |Notes |Detected |

|S |2.455 GHz |Obsolete |No |

|X |10.525 GHz |+/- 25 MHz |Yes |

|Ku |13.450 GHz |Not Currently Used |No |

|K |24.125 GHz |+/- 100 MHz |Yes |

|Ka |33.4-36.0 GHz |13 Channels |Yes |

|Laser |333 THz |Infrared Signal |Yes |

The second major external component in our system is the GPS unit itself. We are using a Trimble Scoutmaster GPS. The GPS unit is completely self-contained and operates at 6 VDC (180 mA). The device normally operates on 4 AA batteries, but we have also wired up power directly so that the unit can be powered by a car’s cigarette lighter (after voltage reduction). All the GPS specifications are listed in table 3 below.

Table 3. Trimble ScoutMaster GPS Specifications

|Specification |Value |

|Voltage |6 VDC |

|Current |180 mA |

|Communication |RS-232, configurable |

|Data Format |ASCII |

|Accuracy |100 meters |

|Update rate |1.0 Seconds |

The GPS communicates its current coordinates as well as its velocity and satellite information in standard ASCII format via an RS-232 serial link. This information is sent via a Mini-DIN connector in the back of the GPS. Figure 2 shows this connector, along with its pin outs. These connections will be routed directly to our microcontroller to handle the RS-232 link and parse the ASCII data into a useable format.

Figure 2. Trimble ScoutMaster GPS DIN-8 Connector and its Pinouts

The internal parts of our system consist of an Atmel AT89C55WD 8051-based microcontroller and an XESS XSV-300 Digital Design board. Relevant specifications that constrain our design can be found in Tables 4 and 5, below. Table 4 lists data for the XSV-300, while Table 5 contains data for the Atmel microcontroller.

Table 4. XSV-300 Specifications

|Specification |Value |

|FPGA Gate Equivalence |300K Gates |

|Flash RAM Storage |16 Mbits |

|Flash RAM Access Time |< 100 ns |

|Power Requirements |9 VDC, 1.5 Amps |

|Available I/O Pins |2-50 pin headers |

|I/O Pin Logic Voltage |3.3 – 6.5 Volts |

|Operating Frequency |100 MHz Max. |

Table 5. Atmel 8051 Specifications

|Specification |Value |

|Code Size (Flash ROM) |20K Bytes |

|Programmable I/O |32 Lines |

|Power Requirements |5 VDC, 15 mA |

|I/O Pin Logic Voltage |5.0 Volts |

|Operating Frequency |32 MHz |

The actual layout of the Atmel 8051 microcontroller and the XSV-300 can be seen in Figures 3 and 4, respectively. Please see the design section for a detailed schematics of all connections.

[pic]

The XSV-300 board has many components we will not need for this design. The major parts we will be using are the flash memory (for nonvolatile storage of coordinates and other information) and the Xilinx Virtex series FPGA. External connections will be made directly via the expansion pins on either side of the board.

The final and possibly most critical design parameter we must be conscious of is speed and response time. In altering the radar we must be certain that when the radar detector receives a signal, it can quickly decide whether or not to sound an alarm. If too much time is spent making these decisions, the radar detector will become less effective.

Traveling at 60 MPH, a vehicle covers 88 feet every second. Thus, we can take one-tenth of a second to make our decision and still only travel nine additional feet before sounding an alarm. Comparing this to actual human braking times, which are near 1-second, it becomes apparent that allowing one-tenth of a second will not adversely affect the driver’s ability to slow down in the presence of police radar. Thus, we feel that anything less than 100 milliseconds will be more than adequate. Related timing results are covered in the section on analysis.

The list of parts discussed in this section and used throughout the project is listed in the next section.

IV – PARTS

We have broken down the part list into two groups: hardware and software.

Hardware

Below are all the hardware parts that we need:

• XESS XSV-300 board

• Xilinx XCV-300 FPGA

• Intel PA28F016S5 FLASH RAM

• Atmel 8051 micro-controller

• FOX F1100E 32.0 MHz oscillator

• Dallas Semiconductors DS275 RS-232 Level converter

• Trimble Scoutmaster GPS Receiver

• Whistler 1140 Radar Detector & cigarette lighter adapter

• Custom RS-232 serial cable (Mini-Din 8 to custom wiring)

• National Semiconductors LM338T-ND Voltage Regulators (3 items)

• Axicom MT2 C93401 5V mechanical relay

• Heat Sinks (2cm x 2cm x 1cm) (3 items)

• Toggle Switch

• Pushbutton Switches (2 items)

• 10 uF Capacitors (4 items)

• 1 uF Capacitor (1 item)

• 240 Ohm Resistors (3 items)

• 10K Ohm Resistors (9 items)

• Various Resistors (1.5K, 1K, 710K)

Software

• Custom C code written to the micro-controller’s flash, as specified in section on micro-controller design.

V – DESIGN AND IMPLEMENTATION

Our design is a composition of four main components: a radar detector, a GPS, an Atmel 8051 microcontroller, and a Xilinx XSV-300 circuit board. Each has specific jobs, as outlined below, and communicates with each other as shown in Figure 5.

• The radar detector picks up radar signal and then sends it to the FPGA (in the XSV-300 specified below).

• The GPS receives coordinates from satellites and send them to the microcontroller.

• The microcontroller receives coordinate data from the GPS, parses these data and sends them in appropriate format to the FPGA.

• The XSV-300 board receives and stores the locations false signal source; checks radar signals received from the detector and outputs appropriate signals to the user; gets response input from the user and updates the false signals sources locations information according to the user’s response.

The details of construction, specifications and implementation (when applicable) of each of these components are presented in the following subsections.

Figure 5. Block diagram show the relationship between four major components of the design

Radar Detector

The radar detector’s task is to pick up radar signals and send it to the FPGA. However, since we started with a complete device we have had to dismantle it and reroute some wires. This section presents the details regarding modifications of the device.

We were provided with a Whistler 1140 radar detector, which is able to pick up radar and laser signals as specified in Table 2. The device has its own speaker and a set of LEDs to send out its output signals. We want to interfere with this process. We want our device to decide when to send out the audible signal to the user (when to set the alarm off). Therefore we have to disable the detector’s speaker and then reroute the output signal to the FPGA. The circuit used to obtain the alarm information from the detector is shown in the figure below. We pull this information from two LEDs which allow us to determine the radar band. Table 6, below, lists the possible output combinations.

Table 6. Radar Detector Bands

|LED1 |LED2 |BAND |

|OFF |OFF |No Signal |

|OFF |ON |X |

|ON |OFF |K |

|ON |ON |KA |

Figure 6. Diagram of output from radar detector

As you can see in Figure 6 above, we measured the voltage of the output signal (when the alarm is set off) in reference to ground, which is common among all devices. We have found that this signal is set high at 5V and low at ground. Since the I/O pins of the FPGA on the XSV-300 board can operate at 0-5 V also, we conveniently wired this pin directly to the XSV-300 board input pin.

We have removed the speaker from the radar detector and rewired it to the breadboard. The signal from the radar detector that would normally go to the speaker is now routed through a mechanical relay that is controlled by a signal from the FPGA. That signal will either allow or block the passage of the speaker signal.

In our design, there are two completely manufactured devices. The radar detector is one. The other one is the Trimble GPS.

GPS

The core of our design is to intellectualize a regular radar detector based on the location of the false signals sources that it picks up, and the job the GPS is to provide this ‘location’.

The GPS unit we use is a ScoutMaster GPS unit. It communicates with a system of satellites developed by the U.S. Department of Defense. Then, it determines its current coordinates, velocity, and other information. It can display this information on its screen or send it through a RS-232 serial link.

As configured, this device outputs a stream of information through the RS-232 serial link that consists of: its position, the number of satellites available and its speed. These outputs are in ASCII format and look like the following (fields of interest are in bold):

$GPGGA,203602,4739.256,N,12218.296,W,1,03,9.1,37.0,M,17.3,M,,

$GPVTG,303.0,T,283.7,M,004.8,N,048.9,K

The GPGGA line is the NMEA standard sentence for “GPS Latitude and Longitude”. The first field (corresponding to 203602) is the Universal Time Coordinates, broken down by hour, minute and second (20:36 and 2 seconds, or 8:36 p.m. and 2 seconds) based on Greenwich Mean Time. The second field is the current latitude in degrees, minutes and fractions of minutes (47( 39.256’) with the third field giving the hemisphere (N or S). Accordingly, the fourth and fifth fields give the current longitude (122( 18.296’ W). The sixth field gives the reliability of the GPS data. A zero indicates that there weren’t enough satellites or that the data is unreliable, a one indicates that the data is accurate and a two indicates that the GPS was able to use differential GPS to achieve even more accurate results. All of the remaining fields are of no interest to us and will be ignored.

The GPVTG line is the NMEA standard sentence for “Actual Track and Ground Speed”. The only field of interest in this is the speed (in km/hr) in field seven.

If the GPS is unable to gather accurate coordinates because of bad telemetry or obstructed views of the sky, it will send a stream in the format shown below. This is recognized by the microcontroller as bad data and is not passed on to the FPGA.

$GPGGA,,,,,,0,00,,,,,,,

$GPVTG,,,,,,,,

The GPS can easily output these streams to the 8051 microcontroller (through an RS-232 serial cable) since this device has a RS-232 input port. The information is sent at 9600 baud using 8 data bits, no parity, and one stop bit. We then parse the output information from the GPS and send it to the FPGA. That is the main job of the microcontroller.

Micro-controller

The main purpose of using the microcontroller is to parse and pass along the information that it receives every second from the GPS unit. The microcontroller parses the stream as it arrives and stores the desired information into a buffer. The necessary values are then converted from ascii to binary and sent to the FPGA.

The GPS input is parsed within an interrupt routine that is called every time a full character is received over the serial port. Since the microcontroller handles the serial communication, we simply retrieve the character from a temporary buffer (SBUF) and handle the data. To correctly parse and collect the stream of data we coded a simple state machine that tracks its position in the stream (see the GPS data format in the previous section) by watching for distinguishing characters in the header fields and counting commas. We simply cannot count characters because the GPS will sent bad data (see previous section) when no satellites are available and we need to recognize this fact. Additionally, it is possible for the microcontroller and the GPS to get out of sync regarding the order of the streams, if there is a power surge or temporary loss of power. For this reason, the state machine needs to include some extra checks to ensure that we do not send errant data to the FPGA. The following pseudo-code summarizes the functionality of the interrupt routine.

R1 = 0; // Reset interrupt flag

Temp = SBUF; // Get serial character

switch(state) {

case 0: Wait for a ‘$’, start storing data when we see one, state = 1.

case 1: Make sure we eventually see ‘A’ and not ‘V’. Keep storing data, state = 2.

case 2: Store everything up to the seventh comma, state = 3.

case 3: Wait for another ‘$’

case 4: Wait for ‘V’, if ‘A’ state = 2 else if ‘V’ state = 5.

case 5: Wait for ‘G’, state = 6.

case 6: Store the velocity, ignore decimal portion. Set ‘send’ flag.

}

When a full stream has been received, the input buffer will look like:

$GPGGA,203602,4739.256,N,12218.296,W,1,048

which is

$GPGGA,time,latitude,N/S,longitude,E/W,GPS quality,velocity

The main loop in the code then notices that the ‘send’ flag is set and calls the process_data routine, which converts the necessary values to binary and stores them in an output buffer to be sent. The pseudo-code below summarizes the process_data routine and is written specifically to fit the data above to clarify functionality.

Skip over ‘$GPGGA,203602,’

Lat_deg = ((‘4’ - 48)*10) + (‘7’ - 48); // convert ascii to binary ‘47’ ( 47

Lat_min = ((‘3’ - 48)*10) + (‘9’ - 48); // convert ascii to binary ‘39’ ( 39

Lat_frac = ((‘2’ – 48)*100) + ((‘5’ – 48)*10) + (‘6’ – 48); // ‘256’ ( 256

…

…

…

velocity = ((‘0’ – 48)*100) + ((‘4’ – 48)*10) + (‘8’ – 48); // ‘048’ ( 48

Once all the data is stored in the output buffer, it is sent to the FPGA in 16-bit blocks. Table 7 shows the final format of the 16-bit output blocks.

Table 7. Parsed data from the GPS unit using microcontroller

|  |output bits |bytes needed |final format in byte |

|degree latitude |7 |1 |2 |

|minute latitude |6 |1 | |

|fraction/min latitude |10 |2 |2 |

|  |  |  |  |

|degree longitude |8 |1 |2 |

|minute longitude |6 |1 | |

|fraction/min longitude |10 |2 |2 |

|  |  |  |  |

|Quadrants |4 |1 |2 |

|velocity (km/hr) |8 |1 | |

The data is passed to the FPGA via the direct connection over ports zero and two and is synchronized using a typical handshake protocol. New data is sent every time a full set of valid data is received from the GPS. Since we are using a 16-bit bus between the devices, this will require five transactions. Each transaction is basically a sequence as defined below:

Microcontroller puts data on the lines and sets the REQ line.

FGPA sees REQ, gets data and sets the BSY line.

Microcontroller sees BSY and drops the REQ line.

FPGA sees REQ low and drops BSY line.

Physically, the use of the built-in RS-232 serial port required setting an interrupt timer to coordinate baud rates between the GPS and the microcontroller. Using the formula given in the Atmel manual, the timer (TH1) was set at 239 to set the baud at 9600. Accordingly, the timer mode (TMOD) was set to 34 for auto-reload and was started by setting the timer register (TR1) to one at the start.

Once the data is parsed, extracted and converted it is sent to the FPGA in five 16-bit blocks. The function and design of the FPGA is discussed in the next section.

XSV-300 (FPGA)

The XSV-300 board is the most important piece of our project; it provides the logic and storage to determine whether or not a given alarm should be muted. Since it is the core of our project it should come as no surprise that it is also the most complex part. The two main components we are using from the XSV board are the Xilinx Virtex FPGA and the Intel FlashFile memory. The logic programmed into the FPGA is outlined in the schematic in Figure 7, below.

[pic]

Figure 7. Internal FPGA Schematic

As you can see, the project consists of 5 main modules and an 8KB memory that temporarily stores the locations that have been ignored. Below is a brief overview of each module:

• Handshake Module: This module receives data from the microcontroller in order to update its current coordinates. It handles the protocol, the valid line, and places the needed coordinate information onto the buses shown.

• Ignore Check Module: This module receives the alarm input from the radar detector and decides whether or not the actual alarm should be sounded. It also handles the restore button presses and the auto-restore functionality.

• Min/Max Collector: This modules collects the boundaries of an alarm and has the coordinates written into memory if the ignore button is pressed. It also adds the 100-meter cushion on when storing the alarm boundary.

• Cache Controller: This module does the physical writing to the cache. Since both the Min/Max Collector and the Ignore Check module both interact with memory simultaneously, this unit is needed to prioritize and coordinate accesses.

• FLASH Controller: This module contains the logic necessary to read, write, and erase the contents of the FLASH. When the device is powered on, the FLASH is read and the cache is updated. Each time a write occurs to the local cache memory, this module must erase and reprogram the FLASH.

Now that a basic understanding of the modules has been established, we will go into more depth about the functionality of each module. A simplified version of the Verilog used in each module is presented below in pseudo-code.

Handshake Module

Uses a standard 4-way handshake to transfer data from microcontroller. The transmission sequence is always started with 0xFFF0 which is an impossible sequence to get while transferring any of the GPS data. This way, the sequence can always be started correctly even if an error occurs at some point. The pseudo-code is as follows:

If (REQ)

BSY ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download