SYSTEM AND METHOD FOR EMERGENCY VEHICLE DETECTION AND ALERTING

Abstract

A system and method is provided for detecting the approach of official and emergency vehicles and alerting drivers. The system is comprised of a vehicle device, a client device, a local device and a dongle. The local device includes a set of acoustic sensors and a set of light wave sensors. The local device is connected to the dongle. The dongle is connected to the local device, the vehicle device and the client device. In use, the sensors record analog light wave and acoustic signals. The signals are processed through a series of rolling frequency and amplitude summary tables to determine the type of emergency vehicle and whether or not it is approaching. If so, an alert is generated and sent to the vehicle device and the client device where it is displayed.

Claims

1. A system for detecting an emergency vehicle comprising: a local device, having a first processor of a set of processors and a first memory of a set of memories, operatively connected to a light wave sensor and an acoustic sensor; a dongle, having a second processor of the set of processors and a second memory of the set of memories, operatively connected to the local device; a vehicle device, having a third processor of the set of processors and a third memory of the set of memories; a set of instructions, resident in the set of memories that when executed by the set of processors cause the system to: receive a set of light wave signals from the light wave sensor; generate a light wave spectral profile from the set of light wave signals; generate a light profile buffer from the light wave spectral profile; receive a set of sound wave signals from the acoustic sensor; generate a sound wave spectral profile from the set of sound wave signals; generate a sound profile buffer from the sound wave spectral profile; generate a light profile buffer summary from the light profile buffer; generate a sound profile buffer summary from the sound profile buffer; compare the light profile buffer summary, to a light emergency vehicle signature table, to determine a light emergency vehicle type; compare the sound profile buffer summary, to a sound emergency vehicle signature table, to determine a sound emergency vehicle type; and, display, on the vehicle device, one of a group of the light emergency vehicle type and the sound emergency vehicle type.

2. The system of claim 1, wherein the light wave spectral profile further comprises a set of light wave maximum amplitude values, indexed by a set of frequency bands.

3. The system of claim 2, wherein the step of generating the light profile buffer further comprises constructing a first in first out table of the set of light wave maximum amplitude values.

4. The system of claim 3, wherein the step of generating the light profile buffer summary further comprises: segregating the set of light wave maximum amplitude values into a set of frequency bands; summing a subset of the set of light wave maximum amplitude values in each frequency band of the set of frequency bands; to calculate a set of amplitude totals; and, segregating the set of amplitude totals according to a set of cutoff values.

5. The system of claim 4, wherein the step of comparing the light profile buffer summary further comprises determining the light emergency vehicle type within a predetermined confidence interval.

6. The system of claim 2, wherein the set of frequency bands further comprises at least a 450 nm band, a 500 nm band, a 550 nm band, a 570 nm band, a 600 nm band and a 650 nm band.

7. The system of claim 1, wherein the sound wave spectral profile further comprises a set of sound wave maximum amplitude values, indexed by a set of frequency bands.

8. The system of claim 7, wherein the step of generating the sound profile buffer further comprises constructing a first in first out table of the set of sound wave maximum amplitude values.

9. The system of claim 8, wherein the step of generating the sound profile buffer summary further comprises: segregating the set of sound wave maximum amplitude values into a set of frequency bands; summing a subset of a set of soundwave maximum amplitude values in each frequency band of the set of frequency bands to calculate a set of amplitude totals; and, segregating the set of amplitude totals according to a set of cutoff values.

10. The system of claim 9, wherein the step of comparing the sound profile buffer summary further comprises determining the sound emergency vehicle type within a predetermined confidence interval.

11. The system of claim 4, wherein the set of frequency bands further comprises at least a 63 Hz band, a 160 Hz band, a 400 Hz band, a 1 kHz band, a 2.5 kHz band, a 6.25 kHz band, and a 16 kHz band.

12. The system of claim 1, wherein the sound profile buffer further comprises: a first maximum frequency value; the sound emergency vehicle signature table further comprises a second maximum frequency value; and, the set of instructions further comprises instructions that when executed cause the system to: compare the first maximum frequency value to the second maximum frequency value to derive a comparison condition; and, send an alert message to the vehicle device based on the comparison condition.

13. The system of claim 12, further comprising: a client device, operatively connected to the dongle; and, wherein the set of instructions include further instructions that when executed cause the system to: display, on the client device, one of a group of the light emergency vehicle type, the sound emergency vehicle type and the alert message.

14. The system of claim 13, further comprising: a server, operatively connected to the client device; and, wherein the set of instructions include further instructions that when executed cause the steps of: retrieve a set of vehicle conditions from the vehicle device upon one of a group of determining the light emergency vehicle type and determining the sound emergency vehicle type; and, send the set of vehicle conditions to the server.

15. A method for detecting an emergency vehicle comprising: providing a local device, having a first processor of a set of processors and a first memory of a set of memories, operatively connected to a light wave sensor and an acoustic sensor; providing a dongle, having a second processor of the set of processors and a second memory of the set of memories, operatively connected to a local drive; providing a vehicle device, having a third processor of the set of processors and a third memory of the set of memories; providing a set of instructions, resident in the set of memories that when executed by the set of processors cause the steps of: receiving a set of light wave signals; generating a light wave spectral profile from the set of light wave signals; generating a light profile buffer from the light wave spectral profile; receiving a set of sound wave signals; generating a sound wave spectral profile from the set of sound wave signals; generating a sound profile buffer from the sound wave spectral profile; generating a light profile buffer summary from the light profile buffer; generating a sound profile buffer summary from the sound profile buffer; comparing the light profile buffer summary to a light emergency vehicle signature table to determine a light emergency vehicle type; comparing the sound profile buffer summary to a sound emergency vehicle signature table to determine a sound emergency vehicle type; and, displaying, on the vehicle device, one of the group of the light emergency vehicle type and the sound emergency vehicle type.

16. The method of claim 15, wherein the step of generating the light wave spectral profile further comprises storing a set of light wave maximum amplitude values indexed by a set of frequency bands.

17. The method of claim 16, further comprising the step of providing the set of frequency bands as at least a 450 nm band, a 500 nm band, a 550 nm band, a 570 nm band, a 600 nm band and a 650 nm band.

18. The method of claim 15, wherein the step of generating the sound wave spectral profile further comprises storing a set of sound wave maximum amplitude values is indexed by a set of frequency bands.

19. The method of claim 18, further comprising the step of providing the set of frequency bands as at least a 63 Hz band, an 160 Hz band, a 400 Hz band, a 1 kHz band, a 2.5 kHz band, a 6.25 kHz band, and a 16 kHz band.

20. The method of claim 15, wherein the step of generating the light profile buffer further comprises constructing a first in first out table of a set of light wave spectral profiles including the light wave spectral profile.

21. The method of claim 20, wherein the step of generating the light profile buffer summary further comprises: bands; segregating the first in first out table into a set of ranges, according to a set of frequency summing the set of ranges into a set of totals; and, characterizing the set of totals according to a set of cutoff values.

22. The method of claim 21, wherein the step of comparing the light profile buffer summary further comprises determining the light emergency vehicle type within a predetermined confidence interval.

23. The method of claim 15, wherein the step of generating the sound profile buffer further comprises constructing a first in first out table of a set of sound wave spectral profiles including the sound wave spectral profile.

24. The method of claim 23, wherein the step of generating the sound profile buffer summary further comprises: segregating the first in first out table into a set of ranges, according to a set of frequency bands; summing a set of ranges into a set of totals; and, characterizing the set of totals according to a set of cutoff values.

25. The method of claim 15, wherein the step of comparing the sound profile buffer summary further comprises determining the sound emergency vehicle type within a predetermined confidence interval.

26. The method of claim 15, further comprising: providing the sound profile buffer as a first maximum frequency value; providing the sound emergency vehicle signature table with a second maximum frequency value; and, providing further instructions in the set of instructions, that when executed cause the steps of: comparing the first maximum frequency value to the second maximum frequency value to derive a comparison condition; and, sending an alert message to the vehicle device based on the comparison condition.

27. The method of claim 26, further comprising: providing a client device, operatively connected to the dongle; and, providing further instructions in the set of instructions, that when executed cause the steps of: displaying, on the client device, one of a group of the light emergency vehicle type, the sound emergency vehicle type and the alert message.

28. The method of claim 27, further comprising: providing a server, operatively connected to the client device; and, providing further instructions in the set of instructions, that when executed cause the steps of: retrieving a set of vehicle conditions from the vehicle device upon one of a group of determining the light emergency vehicle type and determining the sound emergency vehicle type; and, send the set of vehicle conditions to the server.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In the detailed description of the preferred embodiments presented below, reference is made to the accompanying drawings.

[0019] FIG. 1A is a network diagram of a preferred embodiment of a system for detecting emergency vehicles and generating alerts.

[0020] FIG. 1B is a block diagram of a preferred placement of a local device for detecting emergency vehicles.

[0021] FIG. 2A is an architecture diagram of a preferred embodiment of a local device for detecting emergency vehicles.

[0022] FIG. 2B is an architecture diagram of a wireless dongle for a local device.

[0023] FIG. 3 is an architecture diagram of a vehicle device in a system for detecting emergency vehicles.

[0024] FIG. 4 is an architecture diagram of a client device in a system for detecting emergency vehicles

[0025] FIGS. 5A and 5B is a flow chart of a preferred method of emergency vehicle detection.

[0026] FIG. 6A is a flow chart of a preferred method of updating a light profile buffer.

[0027] FIG. 6B is a flow chart of a preferred method of updating a sound profile buffer.

[0028] FIG. 7A is a flow chart of a preferred method of processing light signals.

[0029] FIG. 7B is a flow chart of a preferred method of processing sound signals.

[0030] FIG. 8A is a flow chart of a method of identifying an emergency vehicle.

[0031] FIG. 8B is a flow chart of a method of identifying an emergency vehicle.

[0032] FIG. 9 is a flow chart of a preferred method of generating alerts.

[0033] FIG. 10 is a flow chart of a preferred method of transmitting alerts.

DETAILED DESCRIPTION OF THE INVENTION

[0034] In the description that follows, like parts are marked throughout the specification and figures with the same numerals, respectively. The figures are not necessarily drawn to scale and may be shown in exaggerated or generalized form in the interest of clarity and conciseness. Unless otherwise stated all tolerances are ±10%.

[0035] Referring to FIGS. 1A and 1B, emergency vehicle (EV) detection system 100 will be described.

[0036] EV detection system 100 is comprised of system server 104 operatively connected to database 102. Database 102 includes a sound EV signature table and a light EV signature table, as will be further described.

[0037] System server 104 connected client device 108 through network 106. Network 106 is a wide area network such as the internet. Client device 108 is a mobile computing device, such as a smart phone or tablet. Client device includes application 110. In a preferred embodiment, application 110 is a mobile application having messaging capabilities installed on client device 108. In an alternate embodiment, application 110 is a standard SMS messaging application. Client device 108 is wirelessly connected to dongle 113 and vehicle device 114 via Bluetooth or Wi-Fi.

[0038] Local device 112 is preferably located on roof 125 of vehicle 124, but it may also be located in other positions on the exterior of the vehicle. In a preferred embodiment, local device 112 is positioned near rear end 128 of vehicle 124 at the central apex of the roof. In a preferred embodiment, local device 112 is housed in a transparent or translucent shell which includes means for omnidirectional light capture, such as a dome lens or reflective surfaces.

[0039] In a preferred embodiment, local device 112 is connected to vehicle device 114 through dongle 113. Dongle 113 includes a standard 24-pin connector, preferably connected to OBD II port 115, and communicates with vehicle device 114 through controller area network (CAN) BUS 127. In another embodiment, local device 112 utilizes a wireless connection, such as Wi-Fi or Bluetooth, to communicate directly with vehicle device 114.

[0040] Dongle 113 is further connected to vehicle device 114. Vehicle device 114 is generally comprised of an electronic control unit (ECU), as will be further described. Vehicle device 114 is preferably located in a dashboard positioned near front 126 of vehicle 124.

[0041] Vehicle device 114 is connected to sensors 120 and 121 and displays 122 and 123 resident on the vehicle. In a preferred embodiment, sensors 120 and 121 include brake actuation sensors, speedometers, tachometers, accelerometers, impact sensors, turn signal activation sensors, and airbag deployment sensors. Sensors 120 and 121 are exemplary, as modern vehicles include many types of sensors. Displays 122 and 123 include in dash video and LCD displays. The sensors and displays communicate with vehicle device 114 through the CAN BUS.

[0042] Referring then to FIG. 2A, a preferred embodiment of local device 112 will be described.

[0043] Local device 112 includes processor 200 operatively connected to memory 202, Bluetooth module 204, Wi-Fi module 206, and battery 203. Local device 112 also is operatively connected to digital sound analyzer 212 and digital light analyzer 218.

[0044] In a preferred embodiment, the local device is implemented on a dedicated Arduino Uno available from Arduino, LLC of Somerville, MA. Local device 112 includes two USB 2.0 ports 205 and 207. USB port 205 is connected to Bluetooth module 204. USB port 207 is connected to Wi-Fi module 206.

[0045] Local device 112 includes GPIO connector 224. Digital sound analyzer 212 and digital light analyzer 218 are connected to the processor through GPIO connector 224. Light wave sensor 116 is connected to digital light analyzer 218. Acoustic sensor 118 is connected to digital sound analyzer 212.

[0046] Acoustic sensor 118 is an omnidirectional microphone having a sensitivity range between about −42 dB to −25 dB, such as CMEJ-4622-25-L082 available from CUI Devices of Tualatin, Oregon. The amplifier is a chipset designed to increase the gain of the microphone, such as MAX9814 by Maxim Integrated Products, Inc. of San Jose, CA. Digital sound analyzer 212 has a graphic equalizer that divides the audio spectrum into multiple frequency bands, such as part no. MSGEQ7 available from Mixed Signal Integration Corporation of San Jose, CA.

[0047] Light wave sensor 116 is an photo cell having a spectral range of approximately 350 nm to 1100 nm, such as ISL 29125 VEMD2520X01 available from Vishay Intertechnology, Inc. of Malvern, PA. Digital light analyzer 218 preferably has 6 visible channels each with 40 nm full width at half maximum (FWHM) covering the frequency range 410-690 nm, such as part no. PIM412 available from Pimoroni Ltd. of Yorkshire, UK.

[0048] Processor 200 is connected to memory 202 via access slot 222. Code resident on the memory card is used by the processor to actuate the functions of the system, as will be further described.

[0049] In one embodiment, local device includes battery 203. In another embodiment, local device may be hardwired into the vehicle power system.

[0050] Referring then to FIG. 2B, a preferred embodiment of dongle 113 will be described.

[0051] Dongle 113 includes processor 230 operatively connected to memory 232, Wi-Fi module 234, and Bluetooth module 236. In a preferred embodiment, Wi-Fi module 234 generates a secure wireless connection to local device 112 and Bluetooth module 236 connects to client device 108.

[0052] In a preferred embodiment, the dongle is implemented on a dedicated Arduino Uno. Dongle 113 includes three peripheral ports 235, 237, and 239. The peripheral ports may be USB 2.0 ports, or GPIO connectors. Port 235 is connected to Wi-Fi module 234. In a preferred embodiment, Wi-Fi module 234 is ESP8266 available from Seeed Technology Co., Ltd. of Shenzhen, China. Port 237 is connected to Bluetooth module 236. In a preferred embodiment, Bluetooth module 236 is KC-05 Bluetooth module a available from ElectroPeak, Inc. of Shenzhen, China.

[0053] Port 239 is connected to CAN Bus shield 238. In a preferred embodiment, port 239 is a GPIO connector and connects CAN Bus shield 238 to processor 230. CAN Bus shield 238 connects directly to the OBD II port of a vehicle and includes a CAN controller and a CAN transceiver to transmit commands to a vehicle ECU and log vehicle data, such as part no. 103030215 available from Seeed Technology Co., Ltd. of Shenzhen, China.

[0054] Processor 230 is connected to memory 232 via access slot 233. Code resident on the memory card is used to send interrupt signals and messages along the CAN Bus to the vehicle device and to receive and store vehicle response data, as will be further described.

[0055] Referring then to FIG. 3, a preferred embodiment of vehicle device 114 will be further described.

[0056] Vehicle device 114 is resident in the vehicle and is generally comprised of processor 306 operatively connected to infotainment display 302, multi-information display 304, communication interface 310, speakers 312, memory 308, and CAN Bus 314. CAN Bus 314 provides an operative communication channel between the vehicle device and the dongle. Communication interface 310 includes Bluetooth capabilities. In alternate embodiments, communication interface 310 may also include Wi-Fi, and cellular capabilities.

[0057] Referring then to FIG. 4, a preferred embodiment of client device 108 will be described.

[0058] In a preferred embodiment, client device 108 is a smart phone having processor 402 operatively connected to memory 404, Bluetooth module 406, Wi-Fi module 408, battery 410, cellular transceiver 412, and display 414.

[0059] Referring then to FIGS. 5A and 5B, preferred method 500 for detecting emergency vehicles will be further described. Method 500 takes the form of a software program resident in memory 202 which is executed by processor 200 of local device 112.

[0060] At step 501, the method begins.

[0061] At step 502, client device 108 downloads the EV signature tables, light wave and acoustic band ranges and cut off values α, β, γ, and δ from the server.

[0062] At step 503, processor 200 downloads the EV signature tables, light wave and acoustic band ranges and cut off values α, β, γ, and δ from client device 108 from the dongle.

[0063] At step 504, processor 200 waits a predetermined period of time. In a preferred embodiment, the processor waits in 2-3 second epochs. Of course, other preset time periods may be used.

[0064] At step 505, analog signals from light wave sensor 116 are read and digitized by digital light analyzer 218. A light waveform spectral profile (LWSP) is generated for time, t.sub.x. In a preferred embodiment, the LWSP is stored as a maximum amplitude value, LA.sub.x, for each of a series of frequency band ranges, LB.sub.1-6. An example, of a LWSP is shown below:

TABLE-US-00001 TABLE 1 LWSP.sub.x f LB.sub.1 LB.sub.2 LB.sub.3 LB.sub.4 LB.sub.5 LB.sub.6 A LA.sub.x1 LA.sub.x2 LA.sub.x3 LA.sub.x4 LA.sub.x5 LA.sub.x6

[0065] In a preferred embodiment, there are six (6) frequency bands, LB.sub.1-6. Preferably, frequency band LB.sub.1 is 450 nm, frequency band LB.sub.2 is 500 nm, frequency band LB.sub.3 is 550 nm, frequency band LB.sub.4 is 570 nm, frequency band LB.sub.5 is 600 nm, and frequency band LB.sub.6 is 650 nm. Each frequency band has a ±40 nm full width at half maximum (FWHM). Other band ranges may be used. In a preferred embodiment, A is stored for each LB as counts per μW/cm.sup.2.

[0066] At step 506, the light profile buffer is updated with the most recent LWSP, as will be further described.

[0067] At step 508, analog signals from acoustic sensor 118 are read and digitized by digital sound analyzer 212. A sound waveform spectral profile (SWSP) is generated for time, t.sub.x. In a preferred embodiment, the SWSP is stored as an amplitude value, SA.sub.x, for each of a series of frequency band ranges, SB.sub.1-7. In a preferred embodiment, the SWSP includes the maximum frequency detected at time t.sub.x. An example, of a SWSP is shown below:

TABLE-US-00002 TABLE 2 SWSPx f SB.sub.1 SB.sub.2 SB.sub.3 SB.sub.4 SB.sub.5 SB.sub.6 SB.sub.7 HF A SA.sub.x1 SA.sub.x2 SA.sub.x3 SA.sub.x4 SA.sub.x5 SA.sub.x6 SA.sub.x7 HFV.sub.x

[0068] In a preferred embodiment, there are seven (7) frequency bands, SB.sub.1-7. Preferably, frequency band SB.sub.1 is 63 Hz, frequency band SB.sub.2 is 160 Hz, frequency band SB.sub.3 is 400 Hz frequency band SB.sub.4 is 1 kHz, frequency band SB.sub.5 is 2.5 kHz, frequency band SB.sub.6 is 6.25 kHz, and frequency band SB.sub.7 is 16 kHz. In a preferred embodiment, A is stored for each SWSP in mW/m.sup.2. Alternatively, A may be stored in dB. Other band ranges may be used. In a preferred embodiment, HF is stored as Hz. Generally, emergency vehicle frequencies range between 500 Hz and 1500 Hz.

[0069] At step 510, the sound profile buffer is updated with the most recent SWSP, as will be further described.

[0070] At step 512, a light profile buffer summary is generated, as will be further described.

[0071] At step 514, the light profile buffer summary is compared to the light EV signature table to determine whether or not an emergency vehicle is detected, as will be further described. If so, the method proceeds to step 516. If not, the method proceeds to step 518.

[0072] At step 516, the light EV type for the emergency vehicle identified in step 514 is stored.

[0073] At step 518, a sound profile buffer summary is generated, as will be further described.

[0074] At step 520, the sound profile buffer summary is compared to the sound EV signature table to determine whether or not an emergency vehicle is detected, as will be further described. If so, the method proceeds to step 522. If not, the method proceeds to step 528.

[0075] At step 522, the sound EV type for the emergency vehicle identified at step 520 is stored.

[0076] At step 524, the maximum frequency in the sound profile buffer summary is compared to the maximum frequency associated with the sound EV type sound signature.

[0077] At step 526, the processor determines whether or not the EV is approaching or retreating. If the maximum frequency in the sound profile buffer summary is lower than the maximum frequency associated with the EV sound signature, then the EV is assumed to be retreating from vehicle 124. If the maximum frequency in the sound profile buffer summary is higher than the maximum frequency associated with the EV sound signature, then the EV is assumed to be approaching vehicle 124. In the event that the maximum frequency in the sound profile buffer summary is exactly equal to the maximum frequency associated with the EV sound signature, then, by convention, the EV is assumed to be approaching vehicle 124. If the EV is retreating, the method proceeds to step 528. If the EV is approaching, the method proceeds to step 532.

[0078] At step 528, the processor determines whether or not a light EV type was stored in step 516. If so, the method proceeds to step 530. If not, the method returns to step 502.

[0079] At step 530, the sound EV type stored at step 522 is discarded.=, so as to prioritize the light EV type over the sound EV type which is now assumed to be retreating.

[0080] At step 532, an EV alert message is generated, as will be further described.

[0081] At step 534, the EV alert message is transmitted to the vehicle and the client device for display, as will be further described. The method then returns to step 502.

[0082] Referring then to FIG. 6A, step 506 will be further described.

[0083] In general, the light profile buffer is comprised of the set of the amplitude values for the five (5) most recent light waveform spectral profiles (LWSP), LWSP.sub.0-4, taken at times t.sub.0-4 and stored in a first in first out table (FIFO). An example, of a light profile buffer is shown below:

TABLE-US-00003 TABLE 3 Light Profile Buffer LWSP.sub.x time LB.sub.1 LB.sub.2 LB.sub.3 LB.sub.4 LB.sub.5 LB.sub.6 LWSP.sub.0 t.sub.0 LA.sub.01 LA.sub.02 LA.sub.03 LA.sub.04 LA.sub.05 LA.sub.06 LWSP.sub.1 t.sub.1 LA.sub.11 LA.sub.12 LA.sub.13 LA.sub.14 LA.sub.15 LA.sub.16 LWSP.sub.2 t.sub.2 LA.sub.21 LA.sub.22 LA.sub.23 LA.sub.24 LA.sub.25 LA.sub.26 LWSP.sub.3 t.sub.3 LA.sub.31 LA.sub.32 LA.sub.33 LA.sub.34 LA.sub.35 LA.sub.36 LWSP.sub.4 t.sub.4 LA.sub.41 LA.sub.42 LA.sub.43 LA.sub.44 LA.sub.45 LA.sub.46

[0084] At step 602, the method begins.

[0085] At step 604, LWSP.sub.4, amplitude values LA.sub.41-46, are deleted.

[0086] At step 606, LWSP.sub.0 through LWSP.sub.3 are shifted down, LWSP.sub.0 becomes LWSP.sub.1, LWSP.sub.1 becomes LWSP.sub.2, LWSP.sub.2 becomes LWSP.sub.3, and LWSP.sub.3 becomes LWSP.sub.4, as shown in Table 4 below:

TABLE-US-00004 TABLE 4 Light Profile Buffer LWSP.sub.x time LB.sub.1 LB.sub.2 LB.sub.3 LB.sub.4 LB.sub.5 LB.sub.6 LWSP.sub.new t.sub.0 LWSP.sub.0 t.sub.1 LA.sub.01 LA.sub.02 LA.sub.03 LA.sub.04 LA.sub.05 LA.sub.06 LWSP.sub.1 t.sub.2 LA.sub.11 LA.sub.12 LA.sub.13 LA.sub.14 LA.sub.15 LA.sub.16 LWSP.sub.2 t.sub.3 LA.sub.21 LA.sub.22 LA.sub.23 LA.sub.24 LA.sub.25 LA.sub.26 LWSP.sub.3 t.sub.4 LA.sub.31 LA.sub.32 LA.sub.33 LA.sub.34 LA.sub.35 LA.sub.36

[0087] At step 608, the LWSP.sub.new is stored in the t.sub.0 row. LWSP.sub.new contains the most recent set of readings from the sensors, at now t.sub.0.

[0088] At step 610, the updated light profile buffer is returned.

[0089] Referring then to FIG. 6B, step 510 will be further described.

[0090] In general, the sound profile buffer is comprised of the set of the amplitude values for the five (5) most recent sound waveform spectral profiles (SWSP), SWSP.sub.0-4, taken at times t.sub.0-4 and stored in a FIFO table. An example, of a sound profile buffer is shown below:

TABLE-US-00005 TABLE 5 Sound Profile Buffer SWSP.sub.x time SB.sub.1 SB.sub.2 SB.sub.3 SB.sub.4 SB.sub.5 SB.sub.6 SB.sub.7 SWSP.sub.0 t.sub.0 SA.sub.01 SA.sub.02 SA.sub.03 SA.sub.04 SA.sub.05 SA.sub.06 SA.sub.07 SWSP.sub.1 t.sub.1 SA.sub.11 SA.sub.12 SA.sub.13 SA.sub.14 SA.sub.15 SA.sub.16 SA.sub.17 SWSP.sub.2 t.sub.2 SA.sub.21 SA.sub.22 SA.sub.23 SA.sub.24 SA.sub.25 SA.sub.26 SA.sub.27 SWSP.sub.3 t.sub.3 SA.sub.31 SA.sub.32 SA.sub.33 SA.sub.34 SA.sub.35 SA.sub.36 SA.sub.37 SWSP.sub.4 t.sub.4 SA.sub.41 SA.sub.42 SA.sub.43 SA.sub.44 SA.sub.45 SA.sub.46 SA.sub.47

[0091] At step 622, the method begins.

[0092] At step 624, SWSP.sub.4, amplitude values SA.sub.41-47, are deleted.

[0093] At step 626, SWSP.sub.0 through SWSP.sub.3 are shifted down, SWSP.sub.0 becomes SWSP.sub.1, SWSP.sub.1 becomes SWSP.sub.2, SWSP.sub.2 becomes SWSP.sub.3, and SWSP.sub.3 becomes SWSP.sub.4, as shown in Table 6 below:

TABLE-US-00006 TABLE 6 Sound Profile Buffer SWSP.sub.x time SB.sub.1 SB.sub.2 SB.sub.3 SB.sub.4 SB.sub.5 SB.sub.6 SB.sub.7 SWSP.sub.new t.sub.0 SWSP.sub.0 t.sub.1 SA.sub.01 SA.sub.02 SA.sub.03 SA.sub.04 SA.sub.05 SA.sub.06 SA.sub.07 SWSP.sub.1 t.sub.2 SA.sub.11 SA.sub.12 SA.sub.13 SA.sub.14 SA.sub.15 SA.sub.16 SA.sub.17 SWSP.sub.2 t.sub.3 SA.sub.21 SA.sub.22 SA.sub.23 SA.sub.24 SA.sub.25 SA.sub.26 SA.sub.27 SWSP.sub.3 t.sub.4 SA.sub.31 SA.sub.32 SA.sub.33 SA.sub.34 SA.sub.35 SA.sub.36 SA.sub.37

[0094] At step 628, the SWSP.sub.new is stored in the t.sub.0 row. SWSP.sub.new contains the most recent set of readings from the sensors at now, t.sub.0.

[0095] At step 630, the updated sound profile buffer is returned.

[0096] Referring then to FIG. 7A, a preferred method of step 512 will be further described.

[0097] In general, the light profile buffer summary is comprised of a set of ranked values for summations of amplitudes for each of the frequency band ranges for each time signature. In a preferred embodiment, character values of “H”, “M”, and “L” are assigned as the ranked values. A set of predetermined cutoff levels α, β, and 0 are used to rank the ranges, where a>β>0. It should be appreciated that a different number of band ranges and different cut off values may be used.

[0098] At step 702, the method begins.

[0099] At step 704, the current light profile buffer is retrieved.

[0100] At step 706, a frequency band set is retrieved. The frequency band set is comprised of the amplitude values over all times, t.sub.0-4, for a chosen frequency band, LB.sub.x.

[0101] At step 708, the frequency band set is summed down the column to derive a total value, BT.sub.x, according to the following equation:

BT.sub.x=LA.sub.0x+LA.sub.1x+LA.sub.2x+LA.sub.3x+LA.sub.4x

[0102] At step 710, the system determines whether or not the total value BT.sub.x is greater than a predetermined value, α. In a preferred embodiment, α is about 200 counts per μW/cm.sup.2. If so, the method proceeds to step 712. If not, the method proceeds to step 714.

[0103] At step 712, the ranked value for BT.sub.x is set to “H”. The method then proceeds to step 722.

[0104] At step 714, the system determines whether or not the total value BT.sub.x is greater than a predetermined value, β. In a preferred embodiment, β is about 100 counts per μW/cm.sup.2. If so, the method proceeds to step 716. If not, the method proceeds to step 718.

[0105] At step 716, the ranked value for BT.sub.x is set to “M”. The method then proceeds to step 722.

[0106] At step 718, the system determines whether or not the total value BT.sub.x is greater than 0. If so, the method proceeds to step 720. If not, the method proceeds to step 721.

[0107] At step 720, the ranked value for BT.sub.x is set to “L”. The method then proceeds to step 722.

[0108] At step 721, if the total value is less than zero an error is reported and the method returns.

[0109] At step 722, the system queries whether or not each frequency band set in the light profile buffer has been examined. If not, the method returns to step 706 and the next frequency band set is retrieved. If so, the method proceeds to step 724.

[0110] At step 724, the light profile buffer summary is returned. An example of a prophetic light profile buffer summary is shown below.

TABLE-US-00007 TABLE 7 Light Profile Buffer Summary Band LB.sub.1 LB.sub.2 LB.sub.3 LB.sub.4 LB.sub.5 LB.sub.6 Summary L M L L L H

[0111] Referring then to FIG. 7B, a preferred method of step 518 will be further described.

[0112] In general, the sound profile buffer summary is comprised of ranked values for the summations of amplitudes for each of the frequency band ranges for each time signature. In a preferred embodiment, character values of “H”, “M”, and “L” are assigned. A set of predetermined cutoff levels γ, δ, and 0 are used to rank the ranges, where γ>δ>0. It should be appreciated that a different number of band ranges and different cutoff values may be used. The sound profile buffer summary is further comprised of the highest frequency value in the sound profile buffer.

[0113] At step 752, the method begins.

[0114] At step 754, the current sound profile buffer is retrieved.

[0115] At step 756, a frequency band set is retrieved. The frequency band set is comprised of the amplitude values over all times, t.sub.0-4, for a frequency band, SB.sub.x.

[0116] At step 758, the frequency band set is summed down the column to derive a total value, SBT.sub.x, according to the following equation:

SBT.sub.x=SA.sub.0x+SA.sub.1x+SA.sub.2x+SA.sub.3x+SA.sub.4x

[0117] At step 760, the system determines whether or not the total value SBT.sub.x is greater than a predetermined value, γ. In a preferred embodiment, γ is about 5×10.sup.−6 mW/m.sup.2. If so, the method proceeds to step 762. If not, the method proceeds to step 764.

[0118] At step 762, the ranked value for SBT.sub.x is set to “H”. The method then proceeds to step 772.

[0119] At step 764, the system determines whether or not the total value SBT.sub.x is greater than a predetermined value, δ. In a preferred embodiment, δ is about 1.58×10.sup.−7 mW/m.sup.2. If so, the method proceeds to step 766. If not, the method proceeds to step 768.

[0120] At step 766, the ranked value for SBT.sub.x is set to “M”. The method then proceeds to step 772.

[0121] At step 768, the system determines whether or not the total value SBT.sub.x is greater than 0. If so, the method proceeds to step 770. If not, the method proceeds to step 771.

[0122] At step 770, the ranked value for SBT.sub.x is set to “L”. The method then proceeds to step 772.

[0123] At step 771, if the total value is less than zero an error is reported and the method returns.

[0124] At step 722, the system queries whether or not each frequency band set in the light profile buffer has been examined. If not, the method returns to step 756 and the next frequency band set is retrieved. If so, the method proceeds to step 774.

[0125] At step 774, the highest f value, HFV, is retrieved from the sound profile buffer.

[0126] At step 776, the sound profile buffer summary is returned. An example of a prophetic sound profile buffer summary is shown below.

TABLE-US-00008 TABLE 8 Sound Profile Buffer Summary SB.sub.1 SB.sub.2 SB.sub.3 SB.sub.4 SB.sub.5 SB.sub.6 SB.sub.7 HVF Summary L M L H M L L H

[0127] Referring then to FIG. 8A, a preferred method of step 514 will be further described.

[0128] In general, determining whether or not an EV is detected requires a comparison of the current light profile buffer summary to all EV light signatures stored in memory to find a matching vehicle type.

[0129] At step 802, the method begins.

[0130] At step 804, the light profile buffer summary is retrieved.

[0131] At step 806, an EV signature from the light EV signature table is retrieved. In a preferred embodiment, the light EV signature table includes a list of EV types and a set of values assigned for the EV type for each of the frequency bands. In a preferred embodiment, character values of “H”, “M”, and “L” are assigned, as previously described. An example of a Light EV Signature Table is shown below.

TABLE-US-00009 TABLE 9 Light EV Signature Table EV Type LB.sub.1 LB.sub.2 LB.sub.3 LB.sub.4 LB.sub.5 LB.sub.6 Police 1 L H L L L H Police 2 L H L L L L Police 3 H H H H H L Fire Rescue 1 H L H H H H Fire Rescue 2 L L L L L H Fire Rescue 3 M L M M M H Ambulance 1 H L H H H M Ambulance 2 H M H H H L Ambulance 3 H M H H H M

[0132] At step 808, the light profile buffer summary is compared to the selected EV signature.

[0133] At step 810, the processor determines whether or not each of the values in the light profile buffer summary match the corresponding value in the selected EV signature. If all values match, the method proceeds to step 814. In a preferred embodiment, for a 100% confidence interval all character values must match. In another preferred embodiment, for a 66% confidence interval all but 2 frequency bands match. Other confidence intervals may be used. If any value does not a match, the method proceeds to step 812.

[0134] At step 812, the processor determines whether or not every EV signature from the Light EV Signature Table has been compared to the light profile buffer summary. If not, the method returns to step 806. If so, the method proceeds to step 816 and returns a null.

[0135] At step 814, when the light profile buffer summary matches an EV signature, the corresponding EV type from the Light EV Signature Table is returned.

[0136] Referring then to FIG. 8B, a preferred method of step 520 will be further described.

[0137] In general, determining whether or not an EV is detected requires a comparison of the current sound profile buffer summary to all EV sound signatures stored in memory to find a matching EV type.

[0138] At step 822, the method begins.

[0139] At step 824, the sound profile buffer summary is retrieved.

[0140] At step 826, an EV signature from the sound EV signature table is retrieved. In a preferred embodiment, the sound EV signature table includes a list of EV types, a set of values assigned for the EV type for each of the frequency bands, and a highest frequency value, HFV. In a preferred embodiment, character values of “H”, “M”, and “L” are assigned, as previously described. An example of a Sound EV Signature Table is shown below.

TABLE-US-00010 TABLE 10 Sound EV Signature Table EV Type SB.sub.1 SB.sub.2 SB.sub.3 SB.sub.4 SB.sub.5 SB.sub.6 SB.sub.7 HFV Police 1 L H H M L L L HFV.sub.1 Police 2 L M H L L L L HFV.sub.2 Police 3 L M M H L L L HFV.sub.3 Fire Rescue 1 L H M L L L L HFV.sub.4 Fire Rescue 2 L L L H L L L HFV.sub.5 Fire Rescue 3 L M L H L L L HFV.sub.6 Ambulance 1 L L L H L L L HFV.sub.7 Ambulance 2 L H H M L L L HFV.sub.8 Ambulance 3 L H M M L L L HFV.sub.9

[0141] At step 828, the sound profile buffer summary is compared to the selected EV signature.

[0142] At step 830, the processor determines whether or not each of the values in the sound profile buffer summary match the corresponding values in the selected EV signature. In a preferred embodiment, for a 100% confidence interval all character values must match. In another preferred embodiment, for a 66% confidence interval all but 2 frequency bands match. Other confidence intervals may be used. If all values match, the method proceeds to step 834. If all the values do not a match, the method proceeds to step 832.

[0143] At step 832, the processor determines whether or not every EV signature from the Sound EV Signature Table has been compared to the sound profile buffer summary. If not, the method returns to step 826. If so, the method proceeds to step 836 and returns a null.

[0144] At step 834, when the sound profile buffer summary matches an EV signature, the corresponding EV type from the Sound EV Signature Table is returned.

[0145] Referring then to FIG. 9, a preferred method of step 532 will be further described.

[0146] At step 902, the method begins.

[0147] At step 904, the processor determines if there is both a light EV type and a sound EV type are stored in memory. If so, the method proceeds to step 906. If not, the method proceeds to step 912.

[0148] At step 906, the light EV type is compared to the sound EV type.

[0149] At step 908, the processor determines whether or not the light EV type matches the sound EV type. If so, the method proceeds to step 912. If not, the method proceeds to step 910.

[0150] At step 910, alert messages are generated and returned for both the light EV type and the sound EV type. In a preferred embodiment, an alert message includes the type of emergency vehicle approaching. It should be noted that the system may have detected more than one type of EV. If so, the alerts indicate the multiple types of EVs.

[0151] At step 912, a single alert message is generated and returned, including the type of emergency vehicle approaching.

[0152] Referring then to FIG. 10, a preferred method of step 534 will be further described.

[0153] At step 1002, the method begins when an EV is detected.

[0154] At step 1004, an alert message is generated at local device 112 for each EV type detected, as previously described. At step 1006, each alert message is transmitted to dongle 113.

[0155] At step 1008, processor 230 of the dongle logs the alert message(s) from the local device.

[0156] At step 1009, the alert message is transmitted to client device 108. In a preferred embodiment, the alert message is transmitted through Bluetooth. In another embodiment, the alert message is transmitted over Wi-Fi. In yet another embodiment, the alert message may be transmitted via SMS.

[0157] At step 1010, the alert message is displayed on client device 108. Static or video messages may be displayed on the client device display. Audio files may be played on the client device as well.

[0158] At step 1012, a first CAN Bus interrupt message is generated. The first CAN Bus interrupt message includes the alert message and the instructions needed to connect with the vehicle device and display the alert message(s) on a vehicle display. The message may also include instructions to play audio files.

[0159] At step 1014, the first CAN Bus interrupt message is transmitted to the vehicle device.

[0160] At step 1016, the alert message is displayed and repeated for predetermined period of time. In a preferred embodiment, the message is displayed between about 15 and 20 seconds. Static or video messages may be displayed. Audio files may be played as well.

[0161] At step 1018, a second CAN Bus interrupt message is generated which includes a request for vehicle data. In a preferred embodiment, the vehicle data requested includes vehicle response data, such as speed, brake engagement, turn signal indicator use, and air bag deployment status.

[0162] At step 1020, the vehicle data request is transmitted to vehicle device 114.

[0163] At step 1022, the vehicle device retrieves the data requested.

[0164] At step 1024, the data is returned to the dongle.

[0165] At step 1026, the dongle stores the vehicle response data.

[0166] At step 1028, the dongle generates a message which includes a data log of vehicle response data received and the vehicle identification number.

[0167] At step 1030, the message is transmitted to client device 108.

[0168] At step 1032, the client device logs the message.

[0169] At step 1034, the message is sent to server 104.

[0170] At step 1036, the vehicle response data is stored in the server database.