The University of British Columbia Department of Electrical and Computer Engineering
EECE 375/474 Instrumentation Design Laboratory
Final Report
The Emergency Vehicle Detection System
By Team 2 Ambuj Srivastava Brandon Ko David Hung Kiky W. Tangerine Reuben Heredia Salman Ghumman William Huang
Submitted to Dr. Lee Iverson and Tom de July 24, 2007
i
ABSTRACT
With the number of automobiles on the road increasing each year, collisions between emergency vehicles and civilian vehicles are constantly on the rise. As a result emergency response times are on the rise. The Emergency Vehicle Detection (EVD) System, developed by seven students at the University of British Columbia, attempts to solve this problem by alerting drivers of on coming emergency vehicles within the vicinity. Information such as ‘direction to’, ‘distance from’ and ‘type of’ active Emergency Vehicles are provided to drivers in order for them to respond well before the arrival of the emergency vehicle. This is achieved by using two modules – one placed in an emergency vehicle, one placed in a civilian car. The module on the emergency vehicles allows the vehicle to broadcast its own Universal Transverse Mercator(UTM) coordinates, which is converted from the GPS data received. On the other hand, the module on the civilian vehicles will receive the UTM coordinates of the emergency vehicle, and calculate the distance between themselves and the emergency vehicle. The distance, direction and type of emergency vehicle are clearly displayed on the LCD of the receiver module. Due to time and budget constraints, the precision and accuracy of the distance and direction are comprised to certain extent. The modules were able to outperform our initial expectations of 500m. Overall the general goals were achieved, however, there is room for growth.
ii
Table of Contents
ABSTRACT........................................................................................................................ ii Table of Contents............................................................................................................... iii LIST OF FIGURES ............................................................................................................ v LIST OF TABLES............................................................................................................. vi 1 INTRODUCTION ...................................................................................................... 7 2 PROJECT BACKGROUND ...................................................................................... 9 2.1 Stanford University’s Emergency Vehicle Detector Prototype .......................... 9 2.2 Emergency Vehicle Alert System (EVAS)....................................................... 10 3 SYSTEM DESIGN REQUIREMENTS AND GOALS ........................................... 11 3.1 Budget ............................................................................................................... 11 3.2 Team task Breakdown....................................................................................... 11 4 SYSTEM DESIGN APPROACH............................................................................. 12 4.1 Emergency Vehicle Triangulation using Siren Recognition ............................ 12 4.2 Emergency Vehicle Triangulation Using RF.................................................... 13 4.3 Final Design ...................................................................................................... 13 5 SYSTEM OVERVIEW ............................................................................................ 14 5.1 GPS Receiver .................................................................................................... 14 5.2 Microcontroller ................................................................................................. 14 5.3 Modem .............................................................................................................. 15 5.4 Amplifier........................................................................................................... 15 5.5 LCD Interface ................................................................................................... 15 5.6 Broadcast/Locator Module Packaging.............................................................. 15 6 HARDWARE DESIGN OVERVIEW ..................................................................... 17 6.1 Modem .............................................................................................................. 18 6.1.1 Modem Requirements and Goals.............................................................. 18 6.1.2 Modem Assessment and Analysis ............................................................ 23 6.2 Amplifier........................................................................................................... 24 6.2.1 Amplification Circuit Design Requirements and Goals ........................... 24 6.2.2 Amplification Circuit Design.................................................................... 25 6.2.3 Amplifier Circuit Results.......................................................................... 27 6.3 Microcontroller ................................................................................................. 28 6.3.1 Choosing the Microcontroller ................................................................... 28 6.3.2 Microcontroller Circuit Design................................................................. 29 6.3.3 Port Assignments ...................................................................................... 30 6.3.4 Clock Source............................................................................................. 30 6.3.5 Programming............................................................................................. 30 6.4 Serial Communication ...................................................................................... 31 6.5 LCD................................................................................................................... 31 6.6 GPS Receivers .................................................................................................. 32 6.7 PCB Design....................................................................................................... 32 6.8 Power Supply .................................................................................................... 32 6.8.1 Power Supply Requirements and Goals.................................................... 33 6.8.2 Power Supply Design and Results ............................................................ 33 6.8.3 Power Supply Assessment and Analysis .................................................. 35
iii
7
SOFTWARE DESIGN OVERVIEW ....................................................................... 37 7.1 Microcontroller Configuration.......................................................................... 37 7.1.1 Initialization via ICCAVR ........................................................................ 37 7.1.2 Port and register Initializations ................................................................. 39 7.1.3 UART Initializations................................................................................. 41 7.1.4 LCD Initialization ..................................................................................... 44 7.2 Firmware ........................................................................................................... 48 7.2.1 General Overview ..................................................................................... 48 7.2.2 System Requirements................................................................................ 48 7.2.3 Implementation ......................................................................................... 49 7.2.4 Locator Module Implementation .............................................................. 53 8 SYSTEM ASSESSMENT AND ANALYSIS.......................................................... 57 8.1 Accomplishments.............................................................................................. 57 8.2 Shortcomings and Limitations .......................................................................... 58 8.3 Recommendations............................................................................................. 58 9 CONCLUSION......................................................................................................... 60 10 REFERENCES ..................................................................................................... 61 APPENDIX A - MODEM BENCHMARKING .............................................................. 63 APPENDIX B – DETAILS ON HAC-UM12 MODEM .................................................. 72 APPENDIX C - MICROCONTROLLER SCHEMATIC ................................................ 75 APPENDIX D – PCB DESIGN........................................................................................ 77 APPENDIX E – POWER SUPPLY TESTING AND RESULTS.................................... 78 APPENDIX F – BUDGET ASSESMENT ....................................................................... 85 APPENDIX G – GNAT CHART ..................................................................................... 87
iv
LIST OF FIGURES
Figure 2-1: Experimental Setup by Stanford Graduate Students in Liaison with GM ....... 9 Figure 2-2: A pictorial explanation of the EVAS system. ................................................ 10 Figure 4-1: Simplified mock-up of the Siren Recognition System................................... 12 Figure 4-2: Simple mockup of Triangulation using RF signals........................................ 13 Figure 5-1 Modules in the Emergency Vehicle Detector System..................................... 14 Figure 5-2: Box ................................................................................................................. 16 Figure 6-1: Hardware System Overview .......................................................................... 17 Figure 6-2: Illustration of the Fresnel Zone [3] ................................................................ 19 Figure 6-3: NMEA 0183 data in HyperTerminal ............................................................. 22 Figure 6-4: Screenshot of Google Maps receiving NMEA data and updating the position live............................................................................................................................. 23 Figure 6-5: Illustration of a Repeater re-transmitting one signal in different directions .. 24 Figure 6-6: Amplifier Circuit Diagram [5] ....................................................................... 25 Figure 6-7: Choke Circuit Diagram [6] ............................................................................ 25 Figure 6-8: ADCH-80+ Insertion Loss and VSWR [6].................................................... 26 Figure 6-9: Pin assignment for GV-84+ ........................................................................... 26 Figure 6-10 Pin assignment for ADCH-80+..................................................................... 27 Figure 6-11 Amplified and Un-Amplified Frequency Response of Modems 1 and 2 ..... 28 Figure 6-12: Block Diagram Microcontroller................................................................... 30 Figure 6-13: MAX232 High Level ................................................................................... 31 Figure 6-14 Block diagram for the Power Supply Circuit................................................ 34 Figure 6-15 LM7805N Voltage Regulator [10]................................................................ 34 Figure 6-16 Pin configuration of the MIC94063 IC [12] ................................................. 35 Figure 7-1: ICCRAVR Initialization for ATmega M16 ................................................... 37 Figure 7-2: Port A,B,C,D Initializations in ICCAVR....................................................... 38 Figure 7-3: UART ,and Baud Rate Initialization in ICCAVR.......................................... 38 Figure 7-4: LED Initialization .......................................................................................... 45 Figure 7-5: Special Character Initialization...................................................................... 47 Figure 7-6: GPS Data Packet in NMEA 0183 Format...................................................... 48 Figure 7-7: Broadcast Module Data Flow Block Diagram............................................... 50 Figure 7-8: GPS Data Checking Function ........................................................................ 51 Figure 7-9: Locator Module Data Flow Block Diagram .................................................. 54 Figure 7-10: Angular Direction of Broadcast Module...................................................... 55 Figure 7-11: LCD Display on Locator Module ................................................................ 56 Figure A-1: GPSGate, Input and Output Settings............................................................. 65 Figure B-1: Block Diagram for Functionality of the HAC-UM12 ................................... 72 Figure B-2: Example of FSK modulation......................................................................... 73
v
LIST OF TABLES
Table 3-1: Team task Breakdown ..................................................................................... 11 Table 6-1 Amplifier Circuit Testing Results .................................................................... 27 Table 6-2 Choosing ATmega164P.................................................................................... 29 Table 6-3: LCD Pin Description ....................................................................................... 32 Table 6-4: Theoretical values for each component........................................................... 33 Table 6-5: Practical values for each component ............................................................... 33 Table 6-6: Method of operation for MIC94063................................................................ 35 Table 7-1: Initial Pin Assignments ................................................................................... 40 Table 7-2: Data Direction Register Initializations ............................................................ 41 Table 7-3: Sleep Mode Control Register .......................................................................... 41 Table 7-4: MCU Control Register .................................................................................... 41 Table 7-5: UART Register A, B and C Initializations...................................................... 42 Table 7-6: Baud rate equation legend ............................................................................... 43 Table 7-7: Modem at 1200 Baud, UBBR Register Setting............................................... 44 Table 7-8: GPS at 4800 Baud, UBBR Register Setting.................................................... 44 Table 7-9: Initialization Values for 2x16 LCD................................................................. 46 Table 7-10: Initialization Values for 4x20 LCD.............................................................. 46 Table A-1 Indoor Test Results.......................................................................................... 63 Table B-1: Modem Specifications .................................................................................... 72
vi
1 INTRODUCTION
The actions of other drivers can’t always be anticipated and for drivers of emergency vehicles, oblivious drivers are accidents waiting to happen. In the year 2000, 19% of all firefighter fatalities took place when the person was responding to or returning from a call. In 1999, the statistic was even higher at 23%. These accidents account for nearly half of all liability losses involving ambulances and about a third of all liability losses involving fire trucks not including the emergency organization’s own members and property. Furthermore, due to improved soundproofing in today’s automobiles, audio systems capable of delivering deafening sound levels, and closed windows due to (humming) air conditioners, it is easy for the motoring public to be unaware of approaching emergency vehicles. Even if a driver were to hear the siren, siren sounds can be reflected off buildings, thus altering their direction and creating confusion on the driver’s part; this, combined with the fact that drivers are much more casual about yielding to emergency vehicles than in the past is cause for concern. The Emergency Vehicle Detection System (EVD) aims to remedy this problem by providing cars with a system capable of detecting ‘Active’ (sirens on) Emergency Vehicles. The system consists of two parts: a Broadcast unit which is placed in an Emergency Vehicle and a Receiver-Locator unit placed in civilian vehicles. The Broadcast Unit uses a GPS receiver to acquire positional information and a modem to broadcast said positional information to any vehicle with a receiver/locator unit; the receiver/locator unit has its own GPS receiver and is able to triangulate the position/direction of the ambulance using the received positional data and its own positional data. In order to accomplish this, system design has been focused on the following: 1) Alerting drivers of the direction-of-approach in a non-startling or confusing way; 2) accurately determining the direction of an oncoming emergency vehicle a) when approaching within a distance > 150m perpendicular to a driver’s vehicle and b) when approaching within a distance > 500m from behind and in front of a driver’s vehicle; In order to get increased range, a lower-carrier-frequency modem along with an extended antenna and a signal amplifier was used since higher-carrier-frequency modems are easily blocked by surrounding foliage. The GPS data is framed by the Broadcasting unit’s microcontroller and direction is determined using the Locator unit’s microcontroller. Locator unit’s microcontroller then outputs the data to an LCD which displays distance and direction of approach. ICBC states that their “ultimate goal is to increase public awareness of the importance of safe driving and to contribute to improved traffic safety on British Columbia’s roads and highways”; the ultimate goal of this project is to help them achieve this.
7
This report is divided into the following sections: project background, initial designs, system overview, hardware design, microcontroller design, conclusion and assessment and analysis. The project background describes the market research done before deciding on a design. The system design requirements and goals section discusses the goals, requirements, budget, and task allocation. The system overview describes the system design and module packaging. The Hardware section goes into detail on the PCB design, modem choice, signal amplification, GPS receivers and HUD design. The Software section details the programming of the microcontroller. Finally, the assessment and analysis provides insight as to the challenges and shortcomings of the design and suggest possible solutions if any.
8
2 PROJECT BACKGROUND
According to statistics from ICBC, driver error/confusion and failing to yield right of the way are among the top three contributing factors leading to collisions. Of these drivers, 66% of them are distracted by either listening/changing the radio. In 2005, ICBC reported 3 collisions every 5 days resulting in 238 victims for the year and leaving 1 fatally dead and in 2004, 2 collisions every 5 days resulting in 207 victims. About 50% of the collisions are either at an intersection or due to rear end and 20% of them occurs while changing lanes. Currently, there are no existing Emergency Vehicle Alert Systems on the market, but the idea is not unique. There is both a graduate project at Stanford University which attempted siren detection and an Emergency Vehicle Alert System proposed by AZCO which is similar in both suggested execution and scope.
2.1 Stanford University’s Emergency Vehicle Detector Prototype
In 2004 two graduate students from Stanford University working in conjunction with General Motors (GM) developed a prototype system for Emergency Vehicle Detection. The system is able to identify the direction (front and back only) and distance of the incoming emergency vehicles, given that their sirens are at least 30% louder than the background noise, with 90% accuracy. The figure below illustrates the basic design of the study.
Figure 2-1: Experimental Setup by Stanford Graduate Students in Liaison with GM
9
The system was never actually implemented in a car and the noise distortions and the vehicle vibrations that exist in a real world scenario have never been tested. The system takes four seconds to update and an emergency vehicle traveling at 100km/hr would have traveled 115 meters by then. Furthermore, the group only used laptops, which is inappropriate from a marketing perspective because the system can not be sold as an independent module free from other external instruments. Also, the audio receivers were never designed to detect sirens approaching perpendicular to the vehicle; therefore, the system can only differentiate incoming emergency vehicles from front and back. The overall budget for the group was approximately $2,000 CAD. Regardless of these shortcomings, the project still successfully shows the proof of concept.
2.2 Emergency Vehicle Alert System (EVAS)
AZCO LLC proposed another approach in March 2005, which is referred to as the Emergency Vehicle Alert System (EVAS). The concept is to install a radio transmitter in an emergency vehicle to broadcast the GPS coordinates of itself, and other private vehicles will install radio receivers to compare the GPS coordinates of itself and the emergency vehicle. Figure 2 shows the display system that AZCO LLC had envisioned.
Figure 2-2: A pictorial explanation of the EVAS system.
AZCO’s EVAS system uses the same method of alerting and triangulating as the Emergency Vehicle Detector. However, it has yet to be implemented and AZCO is still awaiting a patent on the idea before attempting a proof of concept.
10
3 SYSTEM DESIGN REQUIREMENTS AND GOALS
The objective of this project is to design and build a system capable of determining the direction of an approaching emergency vehicle responding to/returning from an emergency within a distance of a 150m perpendicular to a driver’s vehicle when approaching within a distance of 500m from behind and in front of a driver’s vehicle. Furthermore, the directional information must be presented in an easy-to-read, nondistracting manner.
3.1 Budget
The budget for this project was $400, excluding any labour, software and book expenses. The total cost of the parts used in the development of the final product was $431.69. An additional $35 was spent on purchasing the text book for the amateur radio licensing exam. The GPS receivers and modems were the most expensive pieces of equipment and makeup more than half of the budget. Refer to Appendix F for a complete list of all the components.
3.2 Team task Breakdown
NAME
Ambuj
TASK
-Marketing -Power Supply Research, Design, Testing. -Final Report touch up, formatting, proof-reading -Powerpoint Presentation -Amateur Radio License -RF distance testing and Power Supply Testing -Package Design and Development -Antenna Coaxial Cables -Log Book -Microcontroller Circuit Design -Serial Communication Hardware, LCD Hardware and PCB Design -Hardware Integration and Testing -Package Design and Develop -Parts Ordering Master and Master Logger -Final System testing -Team Leader -Embedded system programming (LCD interface, GPS communication, System logic) -Embedded system programming (LCD interface, GPS communication, System logic) -Final System testing -Marketing and RF Research -Modem Selection, Benchmarking - RF Distance Testing - Final Report writing, compiling, formatting, editing -Video Editing -Marketing -Amateur Radio License -Amplifier research, design, construction -Antenna Coaxial Cables
Brandon
David
Salman Kiky Reuben
William
Table 3-1: Team task Breakdown
For project progress, refer to Appendix E for the Gnat Chart.
11
4 SYSTEM DESIGN APPROACH
The first iterations of the Emergency Vehicle Detector allowed valuable insight which led to the decisions made for the final design. The following sections details the designs considered and their shortcomings, challenges and the subsequent discarding or modifying of the design.
4.1 Emergency Vehicle Triangulation using Siren Recognition
A microphone placed on the exterior of the car would record environmental noise. The environmental noise would be filtered on Siren-recognition Controller and depending on whether a Siren was detected or not, the Radio would be turned down temporarily and the driver would be notified where the ambulance was in proximity to their vehicle.
Figure 4-1: Simplified mock-up of the Siren Recognition System
This design was deemed unfeasible since filtering the environmental noise was a major issue. The siren noise would be buried amongst the noise created by the vibration of the car’s body, horn, engine, exhaust; there is the noise created by other cars in the vicinity; emergency vehicles (EVs) use 3 different sirens in order to keep drivers from ignoring them; and furthermore, air flow into the microphone could drown out the siren completely. Additionally, as mentioned in section 2.0, the siren recognition challenge had already been tackled and was limited by its inability to triangulate the location of an ambulance without multiple microphones and high cost. The final strike against this design was dealt by an RCMP officer during a marketresearch interview who said that on freeways, even without the radio on, the emergency vehicle has to be at least 40 feet behind the vehicle before the driver will hear the siren.
12
4.2 Emergency Vehicle Triangulation Using RF
Using an RF transmitter placed in an EV and an RF Receiver in the driver’s vehicle, the position of the emergency vehicle would be triangulated by the “RF-Based Triangulator” and announced over the vehicle’s sound-system as shown in Figure 4-2.
Figure 4-2: Simple mockup of Triangulation using RF signals.
This idea was abandoned after speaking with Professor David G. Michelson. It was discovered that in order to properly triangulate the location of an emergency vehicle transmitting an RF signal, two RF receivers in the driver’s vehicle; furthermore, according to Professor Michelson, the act of triangulation was far to complex a problem and would be a waste of resources if attempted.
4.3 Final Design
The approach chosen (using RF transmitters to broadcast GPS position) was, to some extent, inspired by the approach in section 4.2. It is a straightforward solution to both siren detection and RF triangulation and it uses a standardized positioning system, making it easy to implement and develop additional software for – for example, plug-ins for Google maps.
13
5 SYSTEM OVERVIEW
Locator Module Broadcast Module
GPS Receiver (Byonics GPS1)
GPS Receiver (Byonics GPS1)
Microcontroller
Parallel
LCD Interface
Microcontroller
Modem (HAC-UM12)
Amplifier
Coaxial
Modem (HAC-UM12)
Figure 5-1 Modules in the Emergency Vehicle Detector System
The Emergency Vehicle Detector consists of two modules: a Broadcast Module placed in an emergency vehicle and a Locator Module placed in a normal vehicle. Both modules have similar subsystems, but differ in the firmware used for the microcontroller. The subsystems are: GPS receiver, Microcontroller, Modem, Amplifier, and LCD Interface.
5.1 GPS Receiver
A Byonics GPS1 receiver is used to provide each module with its position. In the Locator Module, the data from the GPS receiver is used to provide a reference point from which to triangulate the direction of the oncoming emergency vehicle.
5.2
Microcontroller
The microcontroller in the Broadcast Module accepts the incoming NMEA 0183 data from the GPS receiver, extracts the needed time and positional information (latitude, longitude) while discarding , converts the coordinates to UTM coordinates, frames the data and sends it to the modem for transmission.
14
The microcontroller in the Locator Module checks the modem for any incoming data and only accepts properly framed data. Once the data is accepted, the microcontroller compares the received UTM coordinates to its most recent position (also converted to UTM). It determines the ‘direction of” the emergency vehicle containing the Broadcast Module relative to its own position, ‘distance to’, and ‘EV type’ and sends the data to the LCD Interface.
5.3 Modem
A HAC UM12 433MHz modem is used to transmit the framed data from the Broadcast Module, and receive data at the Locator Module. It communicates with the microcontroller using the RS-232 Standard. The modem transmits on a carrier frequency of 433MHz and antennas are placed at the highest possible point on the car/emergency vehicle.
5.4 Amplifier
A RF signal amplifier is used to boost the Broadcast Module’s transmitted signal strength. The amplifier is the final step before transmission from the Broadcast module and is connected via coaxial cable to the modem. It is further connected to the antenna via coaxial cable.
5.5 LCD Interface
The LCD Interface provides the driver with directional information on the whereabouts of an active emergency vehicle. It receives its data from the microcontroller and displays the distance from the EV, direction to the EV's position with respect to car's position and the EV type.
5.6 Broadcast/Locator Module Packaging
Both modules are housed in a red metal box as shown in Figure 5-2. Both boxes contain a power input at the back and a space for the antenna.
15
Figure 5-2: Box
16
6 HARDWARE DESIGN OVERVIEW
The hardware design was divided into multiple modules: modem, RF Amplification, microcontroller, and GPS receiver. The power, microcontroller and RF amplification modules were designed and developed while the modem and GPS receivers were prepackaged OEM units. Figure 6-1, presents a high level block diagram of the major modules and components integrated in the hardware. Both the transmission and reception end have the same hardware design but operates differently.
Automobile Power Jack
LED_PWR
E
R/W
LCD
RS
ATmega164P
8 Bit Bus
LM7508
Output: 5V, 1A
Vcc
PWR_EN
MIC94063
SLEEP
CMOS
Modem
RS-232
MAX232
2CH CMOSRS232 RS-232 DB-9 PC DB-9 GPS
RS-232
Figure 6-1: Hardware System Overview
During the initial stages of research, the team quickly realized that there would be a major trade-off between the performance and cost of the modems and GPS receivers. In order to stay within the budget limits, low cost and reliable GPS receivers and Modems were required. Affordable OEM GPS receivers from Byonics, and OEM modems from
17
Sparkfun Electronics were used in the project. All of the additional hardware design revolved around the modems and the GPS receivers.
6.1 Modem
In order to transmit the GPS location received from the microcontroller successfully between cars an affordable, yet powerful, modem was necessary. Initially, a custom designed modem was considered, but eventually deemed unfeasible given group resources and time. Instead, time was invested in finding a suitable modem. The following sections will detail why the HAC UM12 433 MHz modem from Shenzhen HAC Co. was chosen. Refer to Appendix A for detailed modem specifications.
6.1.1 Modem Requirements and Goals
The main goals for the modem were simple: 1) Low cost. 2) Able to make a point-to-point transmission over 150m at intersections and 500m in either direction on straightaways. 3) Serial communication uses established standard such as RS-232. Additionally, other wireless options were considered: 1) UBC Wireless LAN. 2) XBee™ ZigBee OEM RF Module from Maxstream [1]
6.1.1.1 Low Cost
Due to budget restrictions, the modem needed to be low in cost. Modems in the GHz range of the Ultra High Frequency Band (UHF) were too expensive; therefore, the main selling point of the HAC UM12, was that it was low in cost: $49.95 US
6.1.1.2 Data Transmission over 150-500 meters
In order to achieve a point-to-point transmission over 150m at intersections and 500m in either direction on straightaways, the right carrier frequency needed to be chosen. Even if visual line of sight (visual LOS) is established between a transmitter and receiver, RF line of sight (RF LOS) is the deciding factor in how far a signal will go [2]. RF LOS requires not only visual LOS, but that a football-shaped area between the antennas called the Fresnel Zone is free of obstructions.
18
Figure 6-2: Illustration of the Fresnel Zone [3]
Any obstructions that enter the Fresnel zone will affect the transmission distance, for example: buildings, ground, vegetation, etc. As the antennas get further apart, the diameter of the Fresnel zone gets larger and the ground begins to affect signal transmission. In order to keep the ground from doing so, the antennas need to be raised so that the combined height of both antenna’s off the ground, is greater than the diameter of the Fresnel zone. The equation for the radius of the Fresnel zone is:
r = 1.732 ×
d 4f
Where: d = distance between antennas (Km) ƒ = carrier frequency (GHz) The frequency is inversely proportional to the radius of the Fresnel zone and as the frequency increases, the radius of the Fresnel zone decreases; consequently, so does the height of the antennas. Considering the height of a regular car and an ambulance, an antenna could be approximately 1 metre off the ground for the car and 3 metres off the ground for an ambulance. Using the equation above it was determined that a carrier frequency > 3.0 GHz would be needed to keep obstruction at a minimum, combined antenna height at 4m, and to obtain the ideal range; however, as mentioned in section 1.2.1, high-frequency modems are in the $200+ range and were too expensive. Furthermore, while high frequency signals are ideal for long-range transmission, they are unable to bend around corners. With this in mind, a modem with a carrier frequency in the lower half of the UHF band – 3GHz to 300MHz – was needed since the lower frequencies of the UHF band would be more likely to bend around corners, facilitating detection at intersections. The UM12 was not only cost-effective; it uses a carrier frequency of 433MHz – low enough to ensure some ‘signal bending,’ high enough to keep antenna heights reasonable. Furthermore, its data-sheet listed it at being able to transmit at distances > 800m when visual LOS is established and antenna height ≥ 2m, and distances > 1000m when visual
19
LOS and antenna height ≥ 5m; that made it ideal for our application. However, in order to achieve these distances, the antenna’s needed to be extended somehow.
6.1.1.2.1 Antenna Extension
As mentioned in Section 1.2.2 of the report, the antenna needed to be placed at a height of at least 2m in order to transmit at distances > 800m. To achieve this, two coaxial cables, one 6 feet and one 1.5 meters in length, with an input impedance of 50Ω, were purchased.
6.1.1.3 Serial Communication Uses Established Standard
Serial Communication needed to be as straightforward as possible and therefore, the modem needed to support an established industry standard such as RS-232. The UM12 supports RS-232, RS-485 and Universal Asynchronous Receiver/Transceiver, TransistorTransistor Logic (UART/TTL) and hence was an ideal choice.
6.1.1.4 Alternate Wireless Options Considered
Other wireless options such as UBC’s Wireless LAN and Zigbees were considered, but they were dismissed on account of their feasibility, complexity, and most importantly cost.
6.1.1.4.1 UBC Wireless LAN
Pros: -
-
Excellent coverage across UBC would make for a good demonstration Minimal hardware needed as Laptops can be used to demo the concept. Infrastructure exists and therefore no protocols are needed. Interesting application of Communal WiFi as implemented in countries like Taiwan. Linux based Full Function Miniature Computers (FFMC) by Gumstix [4] makes creating a non-laptop based receiver/GUI simple and robust.
Cons: - Wireless cards needed are very expensive Wireless USB cards with SMA connectors for antennas cost approximately $40 to $70; furthermore, the supported antennas are themselves $30, resulting in a grand total of approximately $70 to $100 multiplied two ways for two laptops. - The Gumstix proposed are also very expensive, costing at least $100 per motherboard. - Creating robust software is a problem due to the nature of wireless LANS and limited software depth in the team.
6.1.1.4.2 XBee™ ZigBee OEM RF Module from Maxstream [1]
Pros: - Development kit is comprehensive and easy to use. - Zigbees support mesh networking amongst each other, a function which is optimal for congested city transmission.
20
-
Have fully developed transmission protocols. Excellent Support from Maxstream.
Cons: - Development kit is expensive: $400 for the pro module. - The Xbee Pro Module can support transmission over only 100m in indoor/urban areas and over 1.6 Km when RF line of sight is established. - A repeater would be needed to boost the signal and according to e-mails from Maxstream, while it’s theoretically possible to do, they are not sure if any of their customers have modified a Zigbee to act as a repeater though they assume it has been done.
6.1.1.5 Modem Testing Results
To assess the performance of the modem, a few basic tests were performed to benchmark the modem: 1) Distance Testing 2) NMEA 0183 Data Transmission 3) Modem Robustness The following section will detail the basic procedure and final results of each test.
6.1.1.6 Distance Testing
The first distance test was done indoors using two laptops running Microsoft HyperTerminal. Text files of varying size were sent from one laptop to the other over a maximum distance of 67.1 meters. The test showed a limitation of the modem: it cannot transmit files greater than 4 kb. The second distance test was performed using the same settings but outdoors. The maximum transmission distance with antenna heights at approximately .75 meters was approximately 275 meters. The same tests were again attempted after the NMEA 0183 Data Transmission test. It was found that the NMEA data becomes garbled when the distance exceeds 100m; however, once past the 100m mark, the data would become less garbled if the antenna was raised higher. Refer to Appendix A for detailed procedure.
6.1.1.7 NMEA O183 Data Transmission
After distance testing was performed, the next step was to determine if NMEA 0183 data – the type outputted by the GPS Receiver – could be transmitted from one modem to the other. A GPS simulator program called “GPSGate” was used to broadcast NMEA 0183 data and HyperTerminal was used to receive and display the NMEA 0183 data.
21
Figure 6-3: NMEA 0183 data in HyperTerminal
The data was transmitted accurately with none of the data being garbled and matched the data being broadcasted. Additionally, by copying and pasting the transmitted NMEA data to a text file, it was determined that a GPS data packet is less than 1kb. Refer to Appendix A for detailed procedure.
6.1.1.8 Modem Robustness
During the distance tests, there was a notable delay before transmission. It was originally hypothesised that this delay was the fault of HyperTerminal – the program would take time to setup before receiving a file. The hypothesis was confirmed during the NMEA 0183 data transfer tests since the streaming GPS data was appearing every 1-2 seconds and the initial delay when transmitting text files through HyperTerminal was approximately 6+ seconds. In order to properly measure modem robustness, a “live” test was simulated. Yet again GPS gate was used, but this time in conjunction with Google Earth. GPSGate’s simulator function allows the user to broadcast the GPS Coordinates of an object moving between two points at any speed. GPSGate can also receive and output NMEA data to Google earth. Using GPSGate and Google earth, an object was shown travelling from Macleod to an unspecified location in Richmond at 200 Km/h. A red line would indicate the distance already travelled as seen in Figure 6-4. Refer to Appendix A for detailed procedure.
22
Figure 6-4: Screenshot of Google Maps receiving NMEA data and updating the position live.
Google earth would take approximately 1-2 seconds to receive and map the GPS data.
6.1.2 Modem Assessment and Analysis
While two of the three main goals mentioned in Section 1.1 were met, the third requirement was only met partially, and in some cases, not at all. Section 5.3.1, mentioned the issue of garbled data when distances exceeded 100m, but at the same time stated a maximum transmission distance of 275m. The 275m transmission distance was possible because HyperTerminal ensures a stable connection before transmission; however, in the case of the NMEA data test (Section 5.3.2), data was broadcasted and read without ensuring a stable connection between the transmitter and receiver. A way around the distance problem is ensuring signal strength by amplification and/or the use of repeaters. Repeaters take incoming broadcasts and retransmit them as in Figure 6-5. By placing repeaters and strategic spots high up (signal posts at intersections for example), transmission distance and obstructions in the Fresnel zone become less of an issue. Repeaters would have been implemented if not for budget and, to a lesser extent, time restraints.
23
Figure 6-5: Illustration of a Repeater re-transmitting one signal in different directions
However, despite its shortcomings in the transmission distance department, the UM12 was a good choice of modem. It was low in cost, it supported the RS-232 standard making it easy to integrate with the rest of the EMD’s hardware, and the distance issue can be overcome through use of the aforementioned amplifier/repeater combo.
6.2 Amplifier
In order to increase range of the wireless modems (UM-12), two options were considered: amplifying the transmitted signal or increasing receiver sensitivity. Signal amplification on the broadcaster was chosen since increasing signal strength would only require an amplifier on the transmitter.
6.2.1 Amplification Circuit Design Requirements and Goals
The high-level requirement of the amplifier was simple: amplify the transmitted signal power by 20 dB. In order to do so, the following requirements needed to be met: 1) The amplifier’s operational Range needed to include 433MHz 2) It needed to support an input signal power of 10dBm to prevent amplifier saturation and heavy harmonics on the output. 3) A method of preventing Electromagnetic Interference and Radio Frequency Interference from the power supply. 4) Operational Voltage of 5V.
24
6.2.2 Amplification Circuit Design
For the amplification circuit, one IC was needed along with four passive components: a Choke (the ADCH-80+ also from minicircuits), and three capacitors. The amplifier circuit in Figure 6-6 from the datasheet for the GVA-84+ was used in the design:
Figure 6-6: Amplifier Circuit Diagram [5]
The GVA-84+ has an operational range of 0.1 to 1GHz; its maximum allowed input is 13 dBm (19.95 mWatts); and its operational voltage is 5V, making it ideal for the amplification circuit. In order to prevent Electromagnetic Interference and Radio Frequency Interference from the power supply, a choke was added. The choke (RFC in Figure 6-6) is basically an inductor which has high reactance for certain range of frequencies. The chosen Choke, an ADCH-80+ from Minicircuits, has a reactance for frequencies in the 50 to 10000 MHz range.
Figure 6-7: Choke Circuit Diagram [6]
Furthermore, at 400 MHz, the VSWR for the Choke is approximately 1.08 with 0.31 dB insertion loss. Referring to the performance graph (Figure 6-8), the modem’s operational frequency (433MHz) is amongst the lowest in insertion loss as well as the best VSWR value (closest to one).
25
Figure 6-8: ADCH-80+ Insertion Loss and VSWR [6]
Finally, the DC power input of the choke requires 5V +/- 0.2 V. Hence, the choke was ideal for the amplifier circuit. The purpose of the three capacitors is as follows: a 0.1 UF filter capacitor was placed at the DC power input to reduce the ripples from the Vcc (Cbypass in Figure 6-6). The Cblock capacitors are 2400 pF capacitors and were placed directly after/before the RF input/output to prevent flows of DC into the amplifier. The value of 2400 pF was chosen so that no resonance would occur at the frequency of 433MHz, since during resonance capacitors will become equivalent inductor and capacitor circuits; it is necessary to prevent such a case. In addition, the capacitors are ceramic and type NP0 or X7R due to RF circuit’s necessary specifications. In the recommended PCB design, the board used is RO4350B material which has a dielectric constant of 3.48. The PCB was printed on FR-4 fiberglass which has a dielectric constant of 4.2 [7]. Furthermore, the RO4350B has a dielectric thickness of 0.030 mils and FR-4 has 0.062mils [8]. The track width from the recommended PCB design was changed accordingly, in order to obtain the equivalent impedance and ultimately benefit RF transmission. The micro stripes of 60 mils on the recommended design were increased to 120 mils on FR-4 after calculation to achieve same impedance of 50 Ohms [9]. The bottom layer of the PCB is fully grounded and there are numerous vias that which ground the amplifier’s pin 2 and 4.
Figure 6-9: Pin assignment for GV-84+
This procedure was necessary to ensure optimum grounding of the IC. The choke has six pins where only pin 2 and 5 are used.
26
Figure 6-10 Pin assignment for ADCH-80+
Due to the magnitude of the track width, pin 1, 2, 3 will all be placed upon the signal RF track while pin 5 remains as a DC pin. Refer to Appendix D for the PCB design of the amplifier circuit. The amplifier circuit was installed between the Modem and its antenna. The male SMA connector was connected to the RF input of the Amplifier via DBRF 200 cable, which has an intrinsic impedance of 50 Ohms. The RF output of the amplifier was then connected directly to the antenna.
6.2.3 Amplifier Circuit Results
The most effective way to test the amplifier circuit was to use a spectrum analyzer. HyperTerminal repeatedly sent the letter “U” (ASCII 010101) to the HAC-UM12 modem which was connected via laptop. The modem was connected to the amplifier circuit via a DBRF200 coaxial cable and the amplifier circuit was connected to the Spectrum Analyzer via the coaxial cable and an N to SMA adapter. The letter ‘U’ was outputted because it contains the same number of 1’s as 0’s. Since the modem uses Gaussian Frequency-Shift Keying Modulation (refer to Appendix A for explanation) and the frequency will change depending on the value of the output bit, 1 or 0, using the letter U allows for the measurement of an average frequency. The Spectrum analyzer settings that produced the most accurate results were as follows: • Centre Frequency - 433 MHz • Span - 10MHz • Resolution Bandwidth - 30KHz Both modems were tested using this setup and the results were as follows:
Unamplified Signal Strength (dBm) 7.53 7.53 Amplified Signal Strength (dBm) 21.57 21.16 Unamplified Amplified Signal Signal Strength (mW) Strength (mW)
Modem 1 Modem 2
5.66 5.66
143.55 130.62
Table 6-1 Amplifier Circuit Testing Results
27
Figure 6-11 Amplified and Un-Amplified Frequency Response of Modems 1 and 2
The signal was amplified by 20 dB, hence the expected range increase will be about square root of 20 or 4.47 times the unaltered transceiver’s range (note that in 3-D space, power is proportional to distance squared cubed).
6.3 Microcontroller
6.3.1 Choosing the Microcontroller
The microcontroller that first came to mind was the Motorola HC11 since most members of the team are familiar with it. But after consulting with the EECE 474 teaching assistants and reading over previous projects that have used microcontrollers, Atmel Corporation’s microcontrollers seemed to be the better choice. Atmel’s ATmega series is very popular among projects from previous semesters and has a vast on-line support community. The microcontroller selected for the project is the Atmel ATmega164P, which is a low power CMOS 8-bit microcontroller based on the AVR enhanced RISC architecture. It is the new and enhanced version of the ATmega16, with improvements including the possibility for low voltage consumption, an extra USART, and running frequencies up to
28
20MHz. With 16 kilobytes of flash memory, 512 bytes of EEPROM and 1 kilobyte of SRAM internally, the hassle of manually addressing external memory was avoided. Although the ATmega164P contains the lowest amount of memory in its family, it was estimated at the beginning of the project development stage that 16kB will be sufficient. The estimation was based on reviewing previous EECE474 projects and from previous experience with microcontrollers. In the end, the amount of memory proved to be sufficient for the project on both the transmission and reception ends. A summary of the deciding factors and reasoning for selecting the ATmega164P is shown in Table 6-2.
Factors 2 hardware UART Reason - Allows communication with peripheral devices (Modem and GPS receiver) - Avoids the need for software UART - Initial estimation of 20 pins required - Complements with the voltage level of peripheral devices - Avoids SMD components for easy handling - Allows memory expandability if necessary - Members of the team lacked experience with microcontrollers; therefore, a large community for support was ideal
Table 6-2 Choosing ATmega164P
32 I/O Pins Operating voltage = 5.0V PDIP packaging Large family Vast online support
The extra USART was the key reason for selecting the 164P because the microcontroller needs to communicate with the modem and GPS receiver using RS-232. To avoid the extra work of creating a software UART (RS-232 does not require the synchronous aspect of the USART) for the second UART, two built-in UARTs were necessary. Refer to the datasheet on Atmel’s website for more information on the microcontroller.
6.3.2 Microcontroller Circuit Design
Figure 6-12 illustrates the high level communication links between the microcontroller and the surrounding components and modules. Refer to Appendix C for the schematic of the microcontroller circuit.
29
Figure 6-12: Block Diagram Microcontroller
6.3.3 Port Assignments
The ATmega164P has four ports which totals to 32 I/O pins. PORTA was assigned to the LCD data bus, and PORTB was assigned to the LCD control and power lines. In addition, In System Programming (ISP) and power switch enable are also assigned to PORTB. PORTC was assigned to JTAG programming, and PORTD was assigned to serial communication to the modem and GPS receiver. A detailed assignment of each pin can be found in the software section of the report, moreover, the physical link of each pin can be found in the microcontroller schematic in Appendix C.
6.3.4 Clock Source
The microcontroller uses an external crystal as the clock source, which operates at 18.432MHz. This was determined and deemed necessary for the UART to operate with minimal baud rate error. Further explanation of how this error rate is calculated will be discussed in the software section of the report. The values of the capacitors used in conjunction with the crystal were selected based on the values listed in the datasheet of the microcontroller.
6.3.5 Programming
In order to program the microcontroller in mobile environments, the ISP and JTAG pins were made available with break-off headers. Refer to the schematic of the microcontroller circuit in Appendix C for pin connections.
30
Before programming, the microcontroller fuse bits can be set through the programmer. These fuse bits activate certain features such as internal brownout, external clock source, and JTAG programming. For both microcontrollers, the 4.3V internal brownout fuse bit was set. In addition, the fuse bit for external clock source was set.
6.4 Serial Communication
Serial communication between the microcontroller and the peripheral devices (modem and GPS receiver) was established with the help of the MAX232 IC, an industry standard RS-232 line driver and receiver. It has two channels or pairs of data lines (Tx, Rx). One pair is used for the modem and the other pair is used for the GPS receiver and PC. To drive the CMOS level to RS-232 level, two 1µF capacitors are required to double the voltage from +5V to +10V, and two 1µF are required to invert the +10V to -10V. As for receiving RS-232 level signals, the inverters’ thresholds are set by the manufacturer so that the received output will be at TTL/CMOS levels. For more information on the IC, refer to the manufacturer’s datasheet. Figure 6-13 presents a high level representation of how the MAX232 fits into the overall hardware design. Refer to the schematic of the microcontroller circuit for implementation.
+5V/0V +/- 10V
TXD0
TXD0 Modem
RXDO
RXD0
ATmega164P
TXD1
MAX232
2CH CMOSRS232 TXD1 DB-9 PC DB-9 GPS
RXD1
RXD1
Figure 6-13: MAX232 High Level
6.5 LCD
For the reception end, a LCD was required to display the distance between the two vehicles, the direction of the receiver relative to the transmitter, and the type of vehicle that is broadcasting. In order to display these results in a clean and concise manner the team decided to use a four by twenty LCD. On the transmission end, a two by sixteen LCD was incorporated into the design to aid in the debugging process. Both LCDs have backlights that allow the user to see even under bright conditions. The LCD has 16 pins in total and their descriptions can be found in table 6-3.The pin connections can be found in the microcontroller schematic in Appendix C.
31
Pin Symbol Description 1 Vss Ground 2 Vdd 5V 3 Vo LCD Drive 4 RS Resiter Select Signal (H:Data, L:Instruction) 5 R/_W Read/Write {H: Data Read (LCD->MPU), L: Data Write (MPU->LCD)} 6 E Enable 7~14 DB0~DB7 Data Bus 15 A LED Backlight: Anode 15 K LED Backlight: Cathode
Table 6-3: LCD Pin Description
6.6 GPS Receivers
When choosing the GPS Receivers, a fine balance between cost and accuracy needed to be established. As with any electronic equipment sensitivity and price are proportional. It also needed to be easy to mount and waterproof as the GPS receiver would be placed on the outside of a vehicle. The Byonics GPS1 Receiver transmits data at 4800 baud, runs at 5V DC, and outputs to a serial port that supports TTL and RS-232. It also has a position accuracy of approximately 2m, can track an object moving at a velocity up to 500m/s, and withstand accelerations up to 4G. Furthermore, it’s waterproof, has a magnet on the bottom for easy mounting and is quite low in price at $56 [BYONICS]. Due to these attributes and its cohesion with out requirements, the GPS1 Receiver from Byonics was chosen.
6.7 PCB Design
One PCB was designed to accommodate both the transmission and reception modules. Please see Appendix D for the PCB schematic.
6.8 Power Supply
The main task of the power supply is to conveniently provide each component with a reliable and fail-safe power while at the same time providing sufficient protection to avoid any damage to the components due to unexpected fluctuations.
32
6.8.1 Power Supply Requirements and Goals
The entire system consists of a microcontroller, GPS module, modem and an LCD. The following table highlights the main requirements to be met in order for them to function properly as taken from their respective datasheets. Voltage ( Max ) Current ( Max )
Microcontroller 5V GPS 5V Modem 3.3 ~ 5 V LCD 5V LED 5V
20 mA
120 mA
> 8); // Load upper 8-bits of the baud rate value UBRR1L = BAUD_PRESCALE1; // Load lower 8-bits of the baud rate value UBRR1H = (BAUD_PRESCALE1 >> 8); // Load upper 8-bits of the baud rate value
7.1.4 LCD Initialization
The Liquid Crystal Display (LCD) functions at the behest of specific instruction sets further constituting of command and data entries. A command entry is executed by the
44
LCD where as a valid data entry corresponding to a specific character, is displayed. The following flow chart is the template which we followed to initialize the LCD.
Figure 7-4: LED Initialization
For the 2x16 LCD on the transmission end, the following set of instructions was used to initialize the LCD.
45
Steps Function Set
DB Value (Binary) 0011 1000
Display ON/OFF Control Display Clear Entry Mode Set
0000 1111 0000 0001 0000 0100
Description Sets line display to 2 and font type to 5x8 Sets 8-bit bus mode, turns cursor on and blinking on Clears display Sets the direction the cursor will shift to after each character entry
Table 7-9: Initialization Values for 2x16 LCD
For the 4x40 LCD on the reception end, the following set of instructions was used to initialize the LCD.
Steps Function Set DB Value (Binary) 0011 1000 Description Sets line display to 4 and font type to 5x8 Sets 8-bit bus mode, turns cursor on and blinking on Clears display Sets the direction the cursor will shift to after each character entry
Display ON/OFF Control Display Clear Entry Mode Set
0000 1111 0000 0001 0000 0100
Table 7-10: Initialization Values for 4x20 LCD
In order to display directions, custom arrow characters were created. The initialization process for one custom character is summarized in Figure 7-5. A total of six custom characters were created; the up, down and four diagonal arrows. Each will have a different set of address and data.
46
Figure 7-5: Special Character Initialization
47
7.2 Firmware
This section covers the general overview, system requirements, and implementation of the firmware for both transmitter and Locator Modules.
7.2.1 General Overview
When the Broadcast Module is powered, it polls for its own GPS coordinates from USART1, which is connected to the GPS module. The coordinates are then filtered by removing unnecessary information such as satellite locations. Next, it converts the GPS location to UTM coordinates and packets the UTM data. Finally, the packet is passed to the modem where it takes care of the broadcast. On the other end, the Locator Module waits for an interrupt which indicates the reception of data from the modem. When data is received from the modem, it then obtains its own GPS coordinates from the GPS receiver. Both sets of data are processed and the resulting distance and angular direction of the Broadcast Module relative to the Locator Module are displayed onto the LCD.
7.2.2 System Requirements
This section is divided into two parts: the Broadcast Module requirements and the Locator Module requirements.
7.2.2.1 Broadcast Module Requirements
The Broadcast Module was required to receive data from the external GPS module, which is connected to USART1 of the microcontroller, and extract the first line of data, as shown in
Figure 7-6: GPS Data Packet in NMEA 0183 Format . The process of extracting information had to be exact in order to avoid errors during the calculations. The next requirement was that the Broadcast Module be able to convert the data it received from the GPS module into UTM coordinates. Again, this had to be done as accurately as possible so that the uncertainty of the positioning data was low. The next requirement was for the Broadcast Module to generate a packet consisting of the UTM coordinates and broadcast it via the modem which was connected to USART0 of the microcontroller. Due to the real-time nature of the system, the entire process had to be completed as fast as possible so that the packet generated would be updated as frequently as possible. On a final note, the Broadcast Module should not interfere with the broadcasting of other Broadcast Modules so that the Locator Modules do not receive corrupt data.
48
Figure 7-6: GPS Data Packet in NMEA 0183 Format
49
7.2.2.2 Locator Module Requirements
Much the same as the Broadcast Module, the Locator Module was required to keep polling for data; however, it polls the data broadcasted by the Broadcast Module using the modem instead of its own GPS module. After a valid data is received, the Locator Module will poll for its own GPS coordinates in the same fashion as the Broadcast Module. The data from the GPS module was then converted to UTM coordinates and the distance and angular direction of Broadcast Module were calculated and displayed on an LCD. The display had to be short and simple, yet it had to convey the required information to approximate the location of the Broadcast Module (Emergency Vehicle). Again, this process had to be done as rapidly as possible to ensure that real-time information was being delivered.
7.2.3 Implementation
The implementation on both Broadcast and Locator Modules are similar, with more functions implemented on Locator Module to accommodate the requirements of computing for displaying on the LCD.
7.2.3.1 Broadcast Module Implementation
The block diagram in Figure 7-7 below displays the flow of data in the Broadcast Module. Looking from the requirements of the Broadcast Module, it had to be able to constantly polling for data so that no data would be lost. At the same time, it was required to filter the incoming and take only the necessary data: GPS longitude and latitude values in degrees and minutes. One possible approach was to use polling; however, as polling would dominate the microcontroller resulting in lost data, the microcontroller wasn’t able to poll and perform other tasks at the same time. Therefore it was necessary to use the Interrupt Service Routine (ISR) of the USART1 which was connected to GPS module, because ISR would only occur whenever there was data coming in and right after the execution of ISR, MCU would return to its previous state and continue doing its tasks. Moreover, if need be, the ISR could be disabled as required.
50
Figure 7-7: Broadcast Module Data Flow Block Diagram
Whenever there is data coming into the microcontroller from the GPS module through USART1, the Receive Complete ISR will catch the incoming data, temporarily store it in a Data Register of USART1 (UDR1), and subsequently store it in a buffer. The data will finally be passed to a function that checks for the wanted data. Because the data being sent out from the GPS module follows the NMEA 183 standard format, the function checks for a certain series of characters and then takes the data that follows those series of characters until it does not recognize anymore characters [16]. This checking function looks for the characters ‘G’, ‘G’, and ‘A’ in sequential order. After “GGA” is received, the next data coming in will be stored in a buffer until it
51
reaches the start character for the next line, which is a dollar sign ($). When this character is received, the ISR for GPS checking function is disabled and data is transferred to the filtering function. The Figure 7-8 below describes the behaviour of the GPS checking function.
Figure 7-8: GPS Data Checking Function
The function will then pass the whole line that contains the necessary data to another function that does the filtering. The filtering function will take the whole line and return
52
only the GPS longitude and latitude data to be converted to UTM coordinates by another function called deg2utm.
void deg2utm { float float float (float *initLat1, float *initLon1) lat1temp, lon1temp, lat, lon, lat1, lon1, S0, deltaS; a0, epsilon, nu, v0, ta, a1, a2; j2, j4, j6, alfa, beta, gama, Bm;
// converting latitude data to degrees lat1temp = (trunc(*initLat1 / 100.0)) + (fmod(*initLat1, 100.0)/60.0); // converting longitude data to degrees lon1temp = (trunc(*initLon1 / 100.0)) + (fmod(*initLon1, 100.0)/60.0); // deg2utm conversion migrated from deg2utm.m lat = lat1temp * ( M_PI / 180.0 ); lon = lon1temp * ( M_PI / 180.0 ); S0 = trunc( lon1temp/6.0 + 31.0)*6.0 - 183.0; deltaS = lon - ( S0 * ( M_PI / 180.0 ) ); a0 = cos(lat) * sin(deltaS); epsilon = 0.5 * log( ( 1.0 + a0) / ( 1.0 - a0 ) ); nu = atan( tan(lat) / cos(deltaS) ) - lat; v0 =(deg2utm_c/pow(((1.0+(e2cuadrada*pow((cos(lat)),2)))),0.5))*0.9996; ta = ( e2cuadrada / 2.0 ) * pow(epsilon, 2) * pow(( cos(lat) ), 2); a1 = sin (2.0 * lat); a2 = a1 * pow(( cos(lat) ), 2); j2 = lat + (a1 / 2.0); j4 = ((3.0 * j2) + a2) / 4.0; j6 = ( ( 5.0 * j4 ) + ( a2 * pow(( cos(lat) ), 2)) ) / 3.0; alfa = ( 3.0 / 4.0 ) * e2cuadrada; beta = ( 5.0 / 3.0 ) * pow(alfa, 2); gama = ( 35.0 / 27.0 ) * pow(alfa, 3); Bm = 0.9996 * deg2utm_c * (lat - alfa * j2 + beta * j4 - gama * j6); lon1 = epsilon * v0 * (1.0 + (ta / 3.0)) + 500000.0; lat1= nu * v0 * (1.0 + ta) + Bm; if (lat1=0) return floor(num); }
The degree to UTM conversion function above was migrated to C from a free source deg2utm.m file for MATLAB [17]. After the data is ready, one last function is called to assemble the packet by attaching a header, emergency vehicle’s tag name and number, a CRC (Cyclic Redundancy Check) checksum, and an end character and finally the packet is ready to be broadcasted. Another free source code is used to generate the CRC checksum [18]. More information about CRC can be found in Michael Barr’s column, the same person who provides the free CRC source code [19].
53
Lastly, in order for the Broadcast Module not to interfere with the broadcasting of other Broadcast Modules, it would sense whether the current line was being used by other modules or not. If the current frequency line was busy, it would discard the current packet and generate a new one before trying to send the packet again. When the frequency line is open, an interrupt service routine that checks for Data Register Empty is enabled in the USART0 that is connected to the modem. This interrupt service routine will check if the Data Register for USART0 (UDR0) is empty and store the next character of the packet to be sent for transmission. Once the whole packet is sent, this ISR will be disabled and the whole process will be repeated until the broadcast is turned off.
7.2.4 Locator Module Implementation
The complete flow chart of the Locator Module is larger and more complex compared to what the Broadcast Module has, however they do share certain similarities. The Figure 7-9 on the following page presents the full data flow for Locator Module. For the same reason why interrupt service routine was selected to poll data from GPS module, ISR was also chosen to constantly check whether data is received into the microcontroller of the Locator Module from the modem through USART0. If the ISR doesn’t sense any data from the modem for a second, the ISR for the USART0 will be disabled and ISR for USART1 which is connected to the GPS will be enabled to update the Locator Module’s current GPS coordinates which will be stored as initial GPS coordinates of the Locator Module. This is necessary in order to be able to display the correct direction of the incoming emergency vehicle and will be explained in greater detail later in this section. If there is data coming into the modem, the Receive Complete ISR of UART0 will be executed to store the incoming data into a buffer. There is a function similar to GPS data checking function to check whether the packet received contains the correct header. If the correct header is detected, the data will then be passed into the next function that checks for the correctness of the data. This will be done again using the free CRC source code by Michael Barr.
54
no
Checking for a signal from nearby EV
Update current own GPS coordinates (from UART1) yes
1 second passed?
no
Is there a signal from nearby EV?
no yes
Getting data from EV through modem (UART0)
Is data valid? (header and CRC check) Wait for 1 second yes
Getting data from own GPS module (UART1)
Filter unnecessary data and stores the GPS longitude and latitude data
Convert own previous and current GPS coordinates to UTM coordinates and store them
Calculate & Display
Figure 7-9: Locator Module Data Flow Block Diagram
55
After header checking and CRC checksum verification have been completed, the packet received is verified to be a valid data and stored accordingly. The RCISR of UART0 will then be disabled and the RCISR of UART1 is enabled to obtain the Locator Module’s current GPS coordinate using the same method as in the Broadcast Module. The current GPS data and the initial GPS data of the Locator Module are then passed into the same deg2utm function that is used in the Broadcast Module to obtain two sets of UTM coordinates. The three sets of UTM coordinate data (the previous and the current UTM coordinates of Locator Module and a set of UTM coordinates of Broadcast Module) are then passed into calculation process to compute the distance between transmission and receiver modules and the angular location of the Broadcast Module with respect of the direction of which the receiver module is heading to. This is achieved by calculating the smallest angle of the reception and Broadcast Module with respect to the difference of previous and current UTM coordinates of the Locator Module. Therefore, it is very crucial to keep updating the Locator Module’s current coordinate in order to maintain correct angular display.
Figure 7-10: Angular Direction of Broadcast Module
Figure 7-10 shows a scenario when the Locator Module is heading towards North East and the Broadcast Module is located at South East of Locator Module with respect to North. In this case, even though it might be sufficient to display the location of the Broadcast Module with respect to North, it would be to the user’s advantage if it displays the angular direction of the Broadcast Module with respect to the direction of the Locator Module is facing. In this case, the LCD display will show an arrow pointing right (East). Another addition to receiver module that doesn’t exist on the Broadcast Module is the LCD display. The data computed will be displayed on the 4x20 LCD display in the following format: 1. First line will be blank. There will be a blinking attention message if data is received for the first time or after no update occurred after 5 seconds. 2. Second line will display the angular direction (arrows) of which the Broadcast Module is coming. The arrows are multiplications of 45°.
56
3. Third line will display a straight line the distance between Locator Module and Broadcast Module. 4. Fourth line will display the emergency vehicle type that sent the packet (Ambulance, FireTruck, or Police). 5. Figure 7-11shows the 4x20 LCD attached on the Locator Module.
Figure 7-11: LCD Display on Locator Module
57
8 SYSTEM ASSESSMENT AND ANALYSIS
The system requirements as stated in both the design document and Section 3 – System Design Requirements and goals – were as follows: 1) Alert a driver of an approaching emergency vehicle within 150m when it is perpendicular to the driver’s vehicle/ 2) Alert a driver of an approaching emergency vehicle within 500m when it is in front of or behind the driver’s vehicle. 3) Alert a driver of the direction of the approaching vehicle in an easy-to-read, nondistracting manner
8.1 Accomplishments
The team was able to transmit and receive UTM coordinates up to 600m when the two vehicles had line of sight. There were cases where a distance of 800m was achieved. With the help of software control, emergency vehicles within 500m or 150m would trigger the display on the reception end. Note that the range can be limited, with software filtering, to either 500m or 150m, but not both. This is due to the fact that the RF receiver has a circular range of detection. The only method of achieving both of the first two goals, and of course the third goal is to determine the direction of the transmission vehicle. At this point, the team is working on an algorithm to determine the direction of the transmission vehicle relative to the reception vehicle, without the aid of a digital compass and axial sensors. The accomplishments are summarized in a sequential method from the transmission to the reception end. Transmission End 1) Receive NMEA0183 data from the GPS receiver. 2) Extract relevant information for the stream of NMEA0183 data. 3) Convert the relevant information into UTM coordinates. 4) Package the results with headers and a CRC generated checksum 5) Send the packet of data out to the modem, where the packet converted into a RF signal Reception End 6) The RF signal is amplified before transmission. 7) Receive the packet from the modem and acquire NMEA0183 data from the GPS receiver. 8) Perform CRC and extract the data. 9) Again extract relevant information from the NMEA0183 data and perform a UTM conversion. 10) Calculate the distances between the two sets of UTM coordinates. 11) Display the results on the LCD in an easy to read, and non-distracting manner.
58
8.2 Shortcomings and Limitations
There are three major shortcomings at this point in the development stage. First is the precision and accuracy of the distance calculation between two vehicles. The second is determining the direction of the transmission module relative to the reception module. The third is to demonstrate the broadcast nature of the system while staying under budget. The precision and accuracy of the distance calculation is limited by the microcontroller’s inability to handle long doubles. This was overlooked in the initial design process because the original plan was to use the microcontrollers as data relays, and have a laptop process the calculation and display the results. After numerous meetings with the professors, the team was encouraged to create a standalone product. At that point in time, most of the hardware components were purchased already. Moreover, with the tight budget constraint and time available, the team could not afford to switch microcontrollers. In short, the team attempted to perform the NMEA0183 to UTM conversion without a computer, using the same formulas. The team knew from the beginning that determining the direction of the transmission module relative to the reception module would be difficult without the help of a digital compass and an axial sensor. Not only was it difficult, but with the tight budget, a reliable digital compass and axial sensors were out of the question. Recall that the GPS receivers and modems exhausted more than half of the budget. Currently, the algorithm for determine the direction is still in development. To demonstrate the broadcast nature of the system and the different scenarios the system may encounter, at least three modems are required. Again the budget constraint is the cause of the problem. Nonetheless, two different broadcast scenarios, besides the point to point communication, were considered, and solutions for each are provided in the net section. The first scenario is when there are multiple receivers within one transmitter’s broadcast range. The second scenario is when there are multiple transmitters and one receiver all within each other’s range.
8.3 Recommendations
In order to obtain a precise distance between the two modules, a 16-bit microcontroller that supports long double types is necessary. This will allow the conversion from NMEA0183 to UTM coordinates to carry more digits in the variables. In addition, a digital compass and an axial sensor on the reception end will allow the receiver module to determine the position of the transmission module relative to the receiver module. Both solutions will increase the cost of the product but will ensure the precision and accuracy of the resulting data. The solution to solving the first broadcast scenario is that as long as the receivers are far enough apart, they will both receive the broadcasted packet and not interfere with each
59
other. The solution to the second scenario is for each transmitter to sniff the line. If there is data then it implies that the line is busy, otherwise, the line is clear and can be used. This scheme is similar to Ethernet. In addition to sniffing, each transmitter will transmit once every few hundred milliseconds; this is called time division multiplexing.
60
9 CONCLUSION
In essence, this project has a relatively simple concept; however, it does have a very challenging technical aspect to it. The final goal of the project is to build a device that can detect and display the direction of the emergency vehicle with respect to the driver, the absolute distance between the emergency vehicle and the driver, and the type of the emergency vehicle. The team managed to amplify the range of the transceivers and have them communicate effectively using open frequencies. Also, the approximate distances between the vehicles are calculated with uncertainties due to the computational limitations of the microcontroller. The type of emergency vehicle can be detected and displayed without problem. There exists considerable potential for this project in the future. The government could require this device be on every car. The market would be enormous. Indeed, for a more realistic implementation, certain aspects of the device must be enhanced. For example, the transceivers could use emergency frequency band to avoid interruption and interference from the public. Microprocessors could be used for higher distance accuracy. Digital compass and axial sensors could be used for direction detection. Circuits could be compressed to IC’s to reduce the overall size of the device. The team strongly believed that the project is not just a device to fill the market, but a vision that will demonstrate a sense of courtesy and morality to the public.
61
10 REFERENCES
[1] “XbeeTM Zigbee OEM RF Module.” MaxStream Embedded Wireless for Every Thing TM http://www.maxstream.net/products/xbee/xbee-oem-rf-module-zigbee.php “Fresnel Zone Detail.s” MaxStream Embedded Wireless for Every Thing TM http://www.maxstream.net/support/knowledgebase/article.php?kb=90 “Fresnel Zone.” Wikipedia http://en.wikipedia.org/wiki/Image:Fresnelsche_zone.gif “FFMC.” Gumstix http://www.gumstix.com/index.html “GVA-84+ Surface Mount Monolithic Amplifier.” Mini-Circuits http://pdf1.alldatasheet.com/datasheet-pdf/view/162479/MINI/GVA-84+.html “ADCH-80 RF Choke 50 MHz to 10000 MHz.” Mini-Circuits http://pdf1.alldatasheet.com/datasheet-pdf/view/94515/MINI/ADCH-80.html “High Frequency Laminates and Flexible Circuit Materials.” Rogers Corporation http://www.rogerscorporation.com/mwu/tip12.htm “Basic prototypes.” AP Electronics http://www.apcircuits.com/ “Differential Impedance calculator.” In-Circuit Design Pty Ltd http://www.icd.com.au/cgi-bin/cgiwrap/icd/calculate_diff12.pl “LM7805 datasheet.” Fairchild Semiconductor http://www.fairchildsemi.com/ds/LM/LM7805.pdf “Brown-out.” Wikipedia http://en.wikipedia.org/wiki/Brownout “MIC94063 datasheet.” Micrel www.micrel.com John R. McInnis, “Service Consultant.” GM Barnes Wheaton “8 bit AVR microcontroller with 16/32/64K bytes in-system programmable flash, Page 73.” Atmel
[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
62
[15] [16] [17] [18] [19]
“8 bit AVR microcontroller with 16/32/64K bytes in-system programmable flash, Page 193.” Atmel “NMEA 0183 formatting.” Die GPS-Homepage http://www.kh-gps.de/nmea-faq.htm “UTM coordinates latitude longitude degrees WGS84.” Matlab Central http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=109 15 “Source code for these CRC computations.” Netrino http://www.netrino.com/Connecting/2000-01/crc.zip “Easier said than done.” Netrino http://www.netrino.com/Connecting/2000-01/index.php
63
APPENDIX A - MODEM BENCHMARKING
Initial Distance Testing: Objectives:
1) Create a mobile prototype with which to perform tests. 2) Gain a general idea of how far the UM12 could transmit. 3) Watch for any blatant correlations between distance and transmission time.
Setup:
After the modem transmission test and the implementation of a 9V battery regulated to 5V using a using an LM7085 circuit, the only step taken to create a prototype was the inclusion of two laptops. Both laptops used USB-to-Serial cables to which the modem was connected. The laptops were then placed on lab chairs to create a convenient mobile prototype. Using HyperTerminal, text files increasing in size were sent to see if the transmission would slow down and the distance between the modems was increased to test the same.
Indoor Test: Distance (m) 34.5 62.7 62.7 62.7 62.7 62.7 62.7 File Size (kb) 1 < 1.5 4 5 Success Yes Yes No Yes Yes Yes No
Table K-1 Indoor Test Results
The indoor test shows a limitation of the modem: file sizes greater than 4 kb cannot be transmitted. There is the possibility that this is a limitation of HyperTerminal, but that will be a moot point as long as the GPS data is under 4 kb. While the distances did not make a difference on the success of the transmission, there was a notable lag before a transmission was received (approximately a second or two). However, since this lag continued regardless of distance, it was suspected that the lag was a result of HyperTerminal’s handshaking protocol. This hypothesis has yet to be tested. Furthermore, it was noted that the speed of transmission would increase when sending the same file twice This was because HyperTerminal caches files and therefore the files seem
64
to be transmitting faster the second time around. This theory was tested by renaming subsequent files before sending and was found to be true.
Outdoor Test:
In order to try the prototype using some realistic distances, they were taken onto main mall and tested informally.
Distance Macleod to Agronomy Engineering Cairn to Agronomy Engineering Cairn to B-lot EOSC to B-lot File Size (kb) 2 2 2 2 Success Yes Yes Yes Yes
Table A-2 Outdoor Test Results
Once again, the only notable delay was during the handshaking period and in addition, the only way the testers were able to communicate was through hand gestures.
NMEA 0183 Data Transmissions Objective:
1) Transmit NMEA 0183 data (GPS data) from one modem to another using a GPS Simulator on the transmitting end and HyperTerminal on the receiving end. 2) Gain a general idea on NMEA packet sizes.
Setup:
Transmitter: Using a Franson GPSGate 2.5, NMEA data was simulated and outputted to both a real and virtual COM port. The Virtual COM Port was used by HyperTerminal to monitor the data being sent for comparison purposes.
The following settings were used for GPSgate on the transmitting end:
65
Figure L-1: GPSGate, Input and Output Settings
Figure A-2: GPSGate COM4 Serial Port Settings
Choosing a baud rate of 1200 is extremely important. Since the terms bit-rate and baud rate are sometimes used interchangeably (as in the case with HyperTerminal where bitrate means baud rate). Since the baud rate of a modem is the bit-rate divided by 3, in the first test, the baud rate was set to 400. As a result, the data appeared garbled on the receiving end.
66
Figure A-3: GPSGate Simulator Settings
The following settings were used for HyperTerminal:
Figure A-4: COM1 is the virtual port outputted to by GPSgate
67
Figure A-5: Virtual COM1 properties
Figure A-6: Sample of GPS data being outputted from Virtual COM1
68
Receiver:
Figure A-7: COM3 is the port which the Receiving modem is connected to
Figure A-8: COM3 properties
69
Once again, the choice of Bps rate is extremely important since the 1200 refers not to bitrate, but to baud rate.
Figure A-9: NMEA Data being received and detected by HyperTerminal
NMEA Transmission Test:
The data was transmitted accurately with none of the data being garbled, however, knowing the lag was close to impossible since the time data sent in NMEA format was based off some relative clock, not the transmitting computer’s clock. Additionally, the size of a GPS data packet is less than a 1 kb which is excellent considering that there is information which can be filtered and not transmitted – satellite information for example.
Transmission Robustness – Part 1 Objective:
1) Test the approximate robustness of the NMEA data received using the Google Earth output option for Franson GPSGate 2.5.
Setup: Transmitter: The setup for the transmitter is exactly the same as in the NMEA data transmission test
70
with one exception: the GPS data is sent out by the simulator every 5 seconds as opposed to 1 second. Receiver: The main difference between this setup and that for the receiver in NMEA data transmission test is the use of Franson GPSGate’s Google Earth output option.
Figure A-10: Settings to receive and display on Google Earth
71
Figure A-11: COM3 Port settings for GPSGate
Data from the COM3 port will be fed directly to Google Earth through GPSGate. The coordinates used in Figure _ (screen of simulator from before) are for two known locations and the receiving computer’s clock is watched to gauge the approximate time it takes for the data to be received and mapped on Google Earth.
Robustness Results:
Google earth would take approximately 1-2 seconds to receive and map the GPS data. This time is more than satisfactory for the needs of the Emergency Vehicle detector since one successful packet of GPS data is all that is needed in order to triangulate the general direction from which the vehicle is coming.
72
APPENDIX B – DETAILS ON HAC-UM12 MODEM
HAC UM12 433MHz MODEM SPECIFICATIONS Modulation Mode Working Frequency Transmission Power Interface Data Format Receiving Sensitivity Working Temperature Power Supply Dimensions Transmitting Current Receiving Current Sleep Current Interface Velocity Working humidity
GFSK 429.00 – 433.30 MHz 10dBm 8E1/8N1 -118dBm@1200bps -10 C – 60 C +3.3 – 5.5V DC 47x26x10 mm ≤40mA ≤30mA <20uA 1200bps 10%-90% relative humidity w/o condensation
Table L-1: Modem Specifications
FUNCTIONALITY OF THE HAC-UM12 433MHz MODEM: In order to use the modem, it was required that there was a general understanding on how it works.
Figure M-1: Block Diagram for Functionality of the HAC-UM12
For the transmitting end, the data is received via the communications cable and travels from the connector to the Microcontroller Unit (MCU). The MCU error checks the data, converts it from digital to analog via an inbuilt ADAC, and then sends it to the RF IC. The RF IC is responsible for the Gaussian Frequency-Shift Keying (FSK) modulation and transmits the modulated signal after. FSK modulation is a form of frequency modulation where the modulating signal shifts the output frequency between predetermined values. The instantaneous frequency is shifted between two discrete values called the mark frequency and the space frequency.
73
Figure N-2: Example of FSK modulation
GFSK modulation is the same as FSK modulation, except that it uses a Guassian filter to reduce any overshoot. The connector on the HAC-UM12’s pin configuration is shown in Figure B-3
Figure B-3: Connector pin diagram
Pin No. 1
Pin Name
Description
Level
GND Vcc
Grounding of power Supply
Power supply DC
Connected to the Terminal Grounding of Power Supply
Remarks
2
+3.3~5.5V
74
3 4 5 6 7 8
RxD/TTL TxD/TTL SGND A(TxD) B(RxD) SLEEP RESET
Serial data receiving end Serial data transmitting end Grounding of the signal A of RS-485 or
TxD of RS-232
TTL TTL
TxD RxD A(RxD) B(TxD)
COM1 COM1 COM2 COM2 Low Efficiency Mode Negative Impulse Reset
B of RS-485 or RxD of RS-232 Sleep Control (input) Reset (input)
TTL TTL
Sleep Signal Reset Signal
8
Table B-2: Power Specs for the Modem
75
VCC +5V LED D1 1N4148 JP10 R1 4.7k R14 10k U2 D9 G-LED 10 30 31 11 RXD1 RXD0 TXD0 TXD1 PC7 PC6 PC5 PC4 PC3 PC2 PC1 PC0 TDI TDO TMS TCK NVCC +5V C9 PD7 PD6 PD5 PD4 PD3 PD2 PD1 PD0 ~SLEEP TxD/TLL RxD/TLL TXD1 RXD1 TXD0 RXD0 21 20 19 18 17 16 15 14 C12 1uF 1uF C10 1uF 29 28 27 26 25 24 23 22 C7 1uF C8 1uF 11 10 1 3 4 5 2 6 U1 VCC AVCC ~RESET GND GND 40 39 38 37 36 35 34 33 PA0 PA1 PA2 PA3 PA4 PA5 PA6 PA7 PB0 PB1 PB2 PB3 PB4 PB5 PB6 PB7 XTAL2 XTAL1 AREF 12 13 32 ATmega164P X1 20MHz R2 10k VCC +5V LED NVCC +5V JP9 JP8 D8 1N4005 D6 1N4005 1 R13 1K C31 0.1uF C30 1000uF C29 0.33uF D7 G-LED U3 LM7805 GND VI VO 3 1 2 3 4 5 6 7 8 9 9 12 R2OUT R1OUT T1IN T2IN C1+ C1C2+ Vcc C2V+ VMAX232 R2IN R1IN T1OUT T2OUT 8 13 14 7
~SLEEP R16 10k
APPENDIX C - MICROCONTROLLER SCHEMATIC
NVCC +5V VCC +5V C25 0.1uF C6 0.1uF SW1 RESET ~RESET
J3
RxD/TLL TxD/TLL
~SLEEP ~RESET
1 2 3 4 5 6 7 8 9
GND VCC RxD/TTL TxD/TTL SGND TxD/RS232 RxD/RS232 ~SLEEP ~RESET
HAC-UM12
D0 D1 D2 D3 D4 D5 D6 D7 RS R/W E LED PWR_EN MOSI MISO SCK
NVCC +5V NVCC +5V 16 C11 0.1uF GND 15
J5A
1A 2A 3A
RS-232 GPS
J6A
NOTE: THE OUTPUTS ARE INVERTED
LCD1 D7 D6 D5 D4 D3 D2 D1 D0 14 13 12 11 10 9 8 7 D7 D6 D5 D4 D3 D2 D1 15 16 D0 LED A LED K LCD DSP 16x2 R17 20 U4 VCC +5V NVCC +5V 1 2 3 2 R12 1K C27 0.1uF C28 1uF D5 G-LED PWR_EN VOUT GND EN MIC94063 VCC Vo GND RS R/W E 2 3 1 4 5 6
1A 2A 3A
NVCC +5V
RS-232 PC
JP11
NVCC +5V
RV1 10k Var
C1 22pF SW3 J4 1 2 SW KEY -SPST +12V 1 2 F2 0.5A
C2 22pF
NC GND VIN
6 5 4
VCC +5V
VCC +5V VCC +5V R5 10k R6 10k R7 10k R8 10k J1 TCK TDO TMS TDI 1 3 5 7 9 JTAG 2 4 6 8 10 R9 10k R10 10k J2 ~RESET MISO SCK ~RESET 1 3 5 ISP Date: Sunday , July 08, 2007 2 4 6 MOSI R11 10k
Controlled Document
Title Size Document Number Custom 0000-0001-SCH
Emergency Vehicle Detection: Receiv er uC
Rev D
Sheet
1
of
1
76
RS R/W E
Emergency Vehicle Detection: MCU Revised: Monday, July 23, 2007 0000-0001-SCH Revision: E Bill Of Materials July 23,2007 18:34:16 Item Quantity Reference 1 2 C1,C2 2 6 C6,C11,C15,C25,C27,C31 3 6 C7,C8,C9,C10,C12,C28 4 2 C13,C14 5 1 C29 6 1 C30 7 1 D1 8 3 D5,D7,D9 9 2 D6,D8 10 1 F2 11 4 JP8,JP9,JP10,JP11 12 1 J1 13 1 J2 14 1 J3 15 1 J4 16 1 J5 17 1 J6 18 1 LCD1 19 1 RV1 20 1 R1 21 10 R2,R5,R6,R7,R8,R9,R10,R11,R14,R16 22 2 R12,R13 23 1 R17 24 1 SW1 25 1 SW3 26 1 U1 27 1 U2 28 1 U3 29 1 U4 30 1 U7 31 1 U8 32 1 X1 Part 22pF 0.1uF 1uF 2400pF 0.33uF 1000uF 1N4148 G-LED 1N4005 0.5A JUMPER JTAG ISP HAC-UM12 +9V RS-232 GPS RS-232 PC LCD DSP 16x2 10k Var 4.7k 10k 1K 20 RESET SW KEY-SPST ATmega164P MAX232 LM7805 MIC94063 GVA-84+ ADCH-80+ 18.843MHz
77
APPENDIX D – PCB DESIGN
Type: RO4350B Layers: 2
78
APPENDIX E – POWER SUPPLY TESTING AND RESULTS
Power Supply Circuit and testing of LM7805 Regulator
The D.C. power supply from the lab was used as the input voltage into the regulator. For VIN between 7 – 25 Volts, the rated output voltage should be 5 volts. This test was confirmed by using an oscilloscope. As the input voltage is increased from 0 to 7 volts, the output slowly increases from 0 to 5 volts and stayed constant until reaching 25 volts. As VIN was increased beyond 25 volts, the output gradually increased from 5 volts to 7 volts. The capacitors at the input/output of the regulator have a rating of 25V/10V respectively according to the concept of de-rating any electrical apparatus. Figure D-1 shows the schematic of the Power Supply.
Figure E-1: Final schematic of Power Supply Circuit
During the preliminary stages, four regulators were used but upon further research, a better heatsink was found which resulted in the entire system being powered by a single regulator.
Protection schemes
Included in the design
Fuse - Since the entire system draws less than 400 mA, a 500mA fast fuse was put in between the adapter and the regulator. The fuse prevents from any spikes in current from reaching the components. If for some reason the current supplied by the battery exceeds 500 mA, the fuse will blow instantly and isolate the components.
79
Diode – A diode is placed in front of the fuse to prevent any currents flowing into the power supply. The cumulative current drawn by the system is under 400 mA hence the diodes chosen for our design have a tolerance of 1 A. LED’s – The first two LED’s (on the PCB) are for debugging purposes. For instance, if the voltage regulator has burned then the second LED won’t light up.
Not included in the design
Metal Oxide Varistors (MOV) – A device that shorts to ground when the voltage across it is above its rated clamping voltage (voltage at which the varistor starts to conduct). However, majority of MOV’s have a clamping voltage around 100 volts and only their RA and ZA series have a clamping voltage of 22 volts. For our design, a clamping voltage of 15 – 17 volts is required. Choke – A choke filter ‘chokes’ any AC current from getting to the load and mainly consists of inductors and capacitors. Upon consultation with Tom, it was concluded that a choke filter was not required for our circuit as the hybrid regulator took care of most the filtering.
Brown-out protection
As compared to its neighboring ( counterparts / relative ) components, it features an active load circuit that discharges all capacitive loads through the 200Ω switch when the IC is set to OFF state. This allows for the switch to have a clean reset hence getting rid of any residual voltages while starting up again.
Figure E -2: Internal Circuitry of the MIC94063 IC
80
Car Battery with Multimeter
To measure the exact voltage from the cigarette lighter jack, voltage readings were taken using a multimeter both with and without the adapter. Table D-1 summarizes the results.
Ignition position Without Adapter With Adapter With Adapter and Regulator 5.00 V 0.01 V
Acc During the transition phase On On and with acceleration On with High Beams on On with A/C on
12.40 V 0.01 V 13.70 V 14.03 V 13.70 13.65
9.01 V 0.01 V 9.01 V 9.01 V 9.01 9.01
5.00 V 5.00 V 5.00 V 5.00 V
Table E -1: Multimeter readings
The transition phase refers to the moment when the key is halfway between the ACC and ON position. At this point, all the power going to the electronics in the car, including the jack is disconnected. It is to be noted that the output voltage with the adapter dropped to 0.01 V during the transition phase from ACC to ON however, it went back to 9.01 V once the ignition was in the ON position. Similar results were seen when the High Beams and the Airconditioning system were turned on.
Car Battery with Oscilloscope
The purpose of this exercise is to check if the LM7805 voltage regulator can filter out any voltage fluctuations caused by the battery at startup. Multiple readings were taken in order to get accurate results. OFF – ACC without LM7805N regulator The leads of the oscilloscope were connected directly to the output of the cigarette lighter jack. Readings from the oscilloscope were taken while the key in the ignition went from OFF to ACC position. The graph clearly indicates the 2 stages: Stage 1: Ignition goes from OFF to SEMI-ACC Stage 2: Ignition goes from SEMI-ACC to ACC
81
Figure E-4 and E-6 show readings of when the ignition was turned at slowly. Figures E-5 and E-7 show readings of when the ignition was turned very quickly
Figure E-3
Figure E-4
Figure E-5
Figure E-6
Figure E-7
82
OFF – ACC with LM7805N regulator As can been seen by Figure D-8, the regulator outputs either 0 volts or 5 volts. It goes through only 1stage instead of 2 stages like in the case where the reading was taken without the regulator.
Figure E-8
ACC – ON without LM7805N regulator The falling edge represents the moment when all electronic equipments have been disconnected from the battery. The rising edge represents the voltage from the battery being supplied to all the electronic equipment.
Figure E-9
Figure E-10
By decreasing the period to 500 ns, a voltage spike could be seen just at startup. The ripple dies down quite quickly to 14.1 volts. Peak of the ripple is at 17.4 volts in pic 8 and 17.2 volts in pic 9.
83
Figure E-11
Figure E-12
Figure E-13
ACC – ON with LM7805N regulator The output from the regulator shows no ripple voltage hence satisfying the condition of an regulated output voltage.
Figure E-14
Figure E-15
84
Figure E-16
Figure E-17
Figure E-18
85
APPENDIX F – BUDGET ASSESMENT
Item# Items Description Qty Price Sub-Total (USD/CND)
1
TinyTrak3Plus Kit and GPS position encoder + Case - Deluo Combo GPS receiver Modem Long Range 433MHz: UM12
1 1 2 2 2 1 2 5 5 1 3 2 1 1 4 5 5 10 10 2 4 4
$99.00 $56.00 $49.96 $4.82 $0.90 $7.31 $0.58 $0.65 $0.05 $1.46 $0.26 $0.66 $3.00 $4.50 $1.10 $0.10 $0.10 $0.10 $0.10 $0.40 $0.20 $0.10
$99.00 $56.00 $99.92 $9.64 $1.80 $7.31 $1.16 $3.25 $0.25 $1.46 $0.78 $1.32 $3.00 $4.50 $4.40 $0.50 $0.50 $1.00 $1.00 $0.80 $0.80 $0.40
2 Deluo Universal GPS GPS receiver 3 433MHz long range radio 8-bit uC, 16k Flash, 40PDIP RS-232 Transceiver 16PDIP UART with RS232 28PDIP 20MHz Citizen Crystal HC49/US 5V Regulator TO-220 General purpose 50V 1A DO-41
6 ATmega164P 7 8 MAX232 RS232 Driver IC MAX3110 RS232 Driver + UART IC
9 20MHz Citizen Crystal 10 LM7805 Voltage Regulator
11 1N4001 Diode
12 MAX3110E IC Socket Open Frame Tin 28PIN 13 Reset push button Tactile Push Button 14 On/Off switch 15 LCD parallel 16 LCD parallel 17 Breakoff Pin headers (40) Switch Slide DPDT RT ANG L=9MM 2L*16Char LCD w/ backlight ebay 4L*20Char LCD w/ backlight ebay JTAG,ISP,+12V,HACUM12,JUMPERS
18 Green LED 19 Red LED 20 0.1uF 21 1uF 22 1000uF 23 1N4148 24 1N4002
86
25 10k Var 26 4.7k 27 10k 28 1k 29 22pF 30 DB-9 MALE 31 DB-9 FEMALE 32 MIC94063YC6 TR 33 33pF 34 2mm Conn Package 35 2mm Pin Package 36 Heatsink 37 Wires 38 Jumper Shunt 39 SMA Cables 40 Cyrstal 18.432MHz 41 2400pF 42 0.1uF 43 GVA-84+ 44 ADCH-20+ 45 609-2327-ND 46 0.5A Fuses 47 Screws and Nuts 48 Rocker Switches 49 40 PDIP Socket 50 16 PDIP Socket 51 DC Power Jack 3 Watt
2 2 20 10 4 4 4 4 4 1 1 2 1 1 2 2 10 10 2 1 1 4 1 2 2 2 2
$0.75 $0.05 $0.10 $0.10 $0.10 $0.70 $0.70 $1.54 $0.05 $1.90 $1.00 $0.50 $1.50 $1.00 $15.00 $0.80 $0.22 $1.45 $3.60 $14.75 $2.29 $0.10 $3.00 $4.40 $0.50 $0.40 $2.39 Total USD Items Total CND Items Total
$1.50 $0.10 $2.00 $1.00 $0.40 $2.80 $2.80 $6.16 $0.20 $1.90 $1.00 $1.00 $1.50 $1.00 $30.00 $1.60 $2.18 $14.51 $7.20 $14.75 $2.29 $0.40 $3.00 $8.80 $1.00 $0.80 $4.78 $303.84 $109.62 $431.69
Brass CAP CER 2400PF 50V 5% C0G 0805 (Packs of 10) XR7 (Packs of 10) Monolithic Amplifier RF Choke Crimp Socket Housing
2.1mm
Table F-1: Budget Assesment
87
APPENDIX G – GNAT CHART
May 2007 Jun 2007 27/5 3/6 10/6 17/6 24/6 1/7 Jul 2007 8/7 15/7 22/7
ID
Task Name
Start
Finish
Duration
13/5 20/5
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Idea & Proposal Design Document Order Parts Microcontroller Hardware Microcontroller Firmware RF Amplifier GPS communication Visual Display Midterm Report Hardware Test Complete System Test Field Testing Packaging Report
10/05/2007 5/23/2007 6/11/2007 6/4/2007 6/19/2007 7/10/2007 6/28/2007 6/28/2007 6/16/2007 7/4/2007 7/7/2007 7/22/2007 7/15/2007 7/16/2007
5/22/2007 5/28/2007 7/14/2007 6/24/2007 7/25/2007 7/22/2007 7/7/2007 7/4/2007 6/18/2007 7/6/2007 7/21/2007 7/25/2007 7/18/2007 7/25/2007
1.86w .86w 4.86w 3w 5.29w 1.86w 1.43w 1w .43w .43w 2.14w .57w .57w 1.43w
88