US20150232024A1 - Horn Input to In-Vehicle Devices and Systems - Google Patents
Horn Input to In-Vehicle Devices and Systems Download PDFInfo
- Publication number
- US20150232024A1 US20150232024A1 US14/703,170 US201514703170A US2015232024A1 US 20150232024 A1 US20150232024 A1 US 20150232024A1 US 201514703170 A US201514703170 A US 201514703170A US 2015232024 A1 US2015232024 A1 US 2015232024A1
- Authority
- US
- United States
- Prior art keywords
- sound
- sound signal
- horn
- spectral density
- power spectral
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
- B60Q5/00—Arrangement or adaptation of acoustic signal devices
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10K—SOUND-PRODUCING DEVICES; METHODS OR DEVICES FOR PROTECTING AGAINST, OR FOR DAMPING, NOISE OR OTHER ACOUSTIC WAVES IN GENERAL; ACOUSTICS NOT OTHERWISE PROVIDED FOR
- G10K9/00—Devices in which sound is produced by vibrating a diaphragm or analogous element, e.g. fog horns, vehicle hooters or buzzers
- G10K9/18—Details, e.g. bulbs, pumps, pistons, switches or casings
Definitions
- the present application relates to user input to transport systems and devices, in-vehicle data-acquisition systems and transport telematics devices; and more particularly, the use of the horn in a vehicle, or other form of transport, for user input to a device or system that is located in or on the transport.
- In-vehicle devices and systems will refer herein to devices and systems that are installed on a vehicle.
- Aftermarket in-vehicle devices and systems will refer to devices and systems that are installed on a vehicle after the vehicle has been manufactured, i.e. these devices are not factory installed.
- this application description will focus on the use of the horn as an input interface to aftermarket telematics devices which are electronic devices, the application applies to in-vehicle devices and systems in general, aftermarket or factory installed, electronic or not.
- the application is not restricted to aftermarket devices and systems since embodiments of the application can be implemented at the vehicle manufacturing plant. However, as developed below, a definite need for the application is associated with certain unreadily accessible aftermarket devices and systems.
- the application is not restricted to vehicles since operators of other forms of transport use horns as a means of warning others or gaining attention to the transport operations and the application applies to these transports as well.
- vehicle will be used for readability but should be interpreted as including these other forms of transport.
- Vehicle telematics devices and systems employ telecommunications and information processing for a variety on-board functions and communication capabilities. Examples of vehicle telematics functions include emergency warning, GPS navigation, integrated hands-free cell phones, automatic crash notification, wireless safety communications, and automatic driving assistance.
- vehicle telematics functions include emergency warning, GPS navigation, integrated hands-free cell phones, automatic crash notification, wireless safety communications, and automatic driving assistance.
- Several new car manufacturers offer factory-installed telematics systems in their new vehicles. For example, General Motors Corporations offers the OnStar® system, Ford Corporation offers the SYNC® system, and Hughes Telematics offers their system through OEM arrangements with manufactures such as Mercedes-Benz Corporation.
- aftermarket telematics device and system industry offers telematics devices for use in existing vehicles.
- These aftermarket telematics products enable the upgrade of older vehicles with similar telematics functions as those available on new cars.
- these aftermarket telematics products may provide additional functions, for example fleet tracking, or the capture of vehicle telemetry data for usage based vehicle insurance rating. Examples of fleet tracking devices are available from CES Wireless Corporation and Sierra Wireless Corporation.
- the Snapshot® device from Progressive Insurance Company is a well-known telematics device for usage-based insurance.
- the ‘Snapshot’ device plugs into and draws power from the vehicle's standardized on-board diagnostic port, referred to as an ‘OBDII’ connector.
- OBDII plug-in devices provide a straightforward user installation.
- several commercial fleet tracking devices are still rugged ‘bricks’ the size of a blackboard eraser or larger that are intended for professional installation involving more elaborate mechanical mountings and custom wiring.
- a device may be installed inside the dashboard of the vehicle.
- these concealed locations may not be problematic if a well-designed user interface is provided.
- Such a user interface may be readily integrated into the design of the dash or steering wheel, allowing for ergonomically placed controls or touch screen displays.
- a quality user interface to factory installed telematics systems provides a valuable feature that may be used in marketing to enhance vehicle sales.
- aftermarket telematics systems such as fleet tracking devices, automatic crash notification devices, and usage based insurance devices, would benefit from an accessible push button switch user input interface.
- These systems do not require a more elaborate interface such as a touch screen or keypad.
- a push button switch user input interface is desirable so the driver can respond to synthesized voice prompts in order to configure or command the telematics system.
- an un-prompted push button user input could serve as an emergency HELP/MAYDAY switch to initiate contact with a telematics service center or ‘911’ emergency dispatch operator.
- switch any type of binary or ON/OFF control signaling method that is easily and directly activated and/or inactivated by the user.
- An example of this type of switch is a push button near the overhead interior light in the passenger compartment of a vehicle that the occupants use to turn the light ON or OFF.
- user here generally refers to the operator of the vehicle but may also include vehicle occupants.
- a push button switch as a user input interface to an aftermarket device that is concealed from the user, for example a device that is under or inside the dash of the passenger compartment.
- One such method for example, is to mount a switch somewhere on the dash and connect the switch to the device by means of wires or wireless signaling. This is undesirable cosmetically—very few vehicle owners want a button glued or otherwise attached to the dashboard of their vehicle.
- a remote wireless button creates the need for a power source, and if a battery is used for power, the requirement to replace or recharge the battery.
- Another approach that is also undesirable is to rewire an existing control on the dash so that it is wired to the aftermarket device instead of being wired by the car manufacturer. This approach would be difficult to implement, result in permanent vehicle damage, and may void the vehicle's warranty.
- Voice activation may initially appear to be an attractive solution for providing a simple user input interface for an inaccessibly installed aftermarket device.
- the audio signal processing technology that is required to provide a reliable voice activation user interface has a large processing burden and may be difficult to economically justify.
- These telematics devices plug into the OBDII connector for device mounting, power source, and access to vehicle diagnostic data.
- Voice activation technology is superfluous for a simple push button switch type of user interface for these reduced cost telematics devices.
- the push button switch may only be needed for user-aided configuration of the device and for providing the user with HELP/MAYDAY button functionality.
- What would be optimal is an inexpensive and accessible user input interface for in-vehicle devices and systems that can serve the function of a simple push button switch.
- this type of user interface is needed for low cost, user-installed, consumer-oriented, OBDII-mounted telematics devices.
- Such an interface will allow enhanced functionality, for example, by allowing the user to configure and command the device in response to audio prompts and by providing the user with a HELP/MAYDAY button function that can be used to obtain help in an emergency.
- the present application provides systems and methods that use a vehicle horn to provide an inexpensive user input interface that can serve the function of a push button switch for an in-vehicle device or system.
- Example embodiments contain a vehicle horn with a horn control button switch, a sound sensor, such as a microphone, and a sound processor.
- An example method makes use of a calibration phase and a sensing phase. During the calibration phase, horn sound data is acquired and processed to extract horn identification parameters. During the sensing phase, sound data is acquired and processed using the horn identification parameters.
- This sensing processing determines: 1) if the detected horn sound appears to match the one used for calibration, and 2) whether the vehicle driver is using the horn for normal alerting purposes to a third party, or to communicate with the in-vehicle device. In the latter case, the driver uses the vehicle horn to provide an effective push button input to the device.
- FIGS. 1A and 1B diagram a system and method, respectively, of an example embodiment of the present application.
- the example system of the application diagrammed in FIG. 1A includes a horn sound generation apparatus, sound sensing and processing apparatus, and an optional voice prompt generation apparatus.
- the horn sound generation apparatus is a horn 110 that is activated by a vehicle horn switch 120 that the driver uses to honk the horn.
- the sound sensing apparatus consists of a sound sensor 130 and a sound processor 140 .
- the voice prompt generator apparatus 150 may be an audio player of prerecorded voice recordings.
- the sound sensor 130 , the sound processor 140 and the voice prompt generator 150 may reside in the in-vehicle device 155 as shown in FIG. 1A .
- these apparatus elements in other embodiments may be external to the in-vehicle device and the decision for Push Button ON/OFF 145 may be communicated with the device via well-known wireline or wireless techniques, for example by means of a Bluetooth wireless link.
- the example method of the application diagrammed in FIG. 1B consists of the Acquisition of Sound Sensor Data process 155 which involves sampling data from the sound sensor 130 , the process called Calibration Phase Horn Sound Acquisition and Processing 160 which determines the Horn Identification Calibration Parameters 170 and the process called Sensing Phase Sound Acquisition and Processing 180 which uses the Horn Identification Calibration Parameters 170 and determines a decision for Push Button ON/OFF 190 .
- the signal processing in the calibration phase analyzes the harmonic nature of the user's vehicle horn sound to parametrically characterize the harmonics in the sound.
- the signal processing in the sensing phase uses these parameters to detect the presence or absence of a sound with the same parametrically defined harmonics.
- the in-vehicle device 155 of FIG. 1A is an aftermarket telematics device that plugs into the vehicle's OBDII diagnostic port and performs automatic crash notification (ACN).
- ACN automatic crash notification
- Such a telematics device is described in U.S. patent application Ser. No. 13/276,991 titled “Detecting a Transport Emergency Event and Directly Enabling Emergency Services” which is incorporated in its entirety by reference herein.
- the driver is instructed to “depress the horn for 4 seconds” after which the device may report that it is ‘calibrated and active’.
- the amount of time the horn should be depressed for calibration and activation can be less or more than 4 seconds.
- the device may issue voice prompts to the driver, “depress the horn for 4 seconds if you want to call the 911 operator.” If he or she does, a 911 call is immediately placed. Many other use cases are available for even this one example embodiment of the application.
- One example embodiment may provide a method that includes generating a prompt to initiate a sound signal, receiving the sound signal responsive to generating the prompt, recording the sound signal in memory, computing a power spectral density of the sound signal, determining a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilizing a plurality of components of the power spectral density of the sound signal between the sound start-up and the sound drop-off points to create a set of sound calibration parameters, and processing subsequent sound signals with the calibration parameters to determine if they are comparable to the sound signal.
- Another example embodiment may provide an apparatus that includes a processor configured to generate a prompt to initiate a sound signal, a receiver configured to receive the sound signal responsive to the generated prompt, a memory configured to record the sound signal, a processor configured to compute a power spectral density of the sound signal, determine a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilize a plurality of components of the power spectral density of the sound signal between the sound start-up and sound drop-off points to create a set of sound calibration parameters, and process subsequent sound signals the calibration parameters to determine if they are comparable to the sound signal.
- Another example embodiment may provide a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform generating a prompt to initiate a sound signal, receiving the sound signal responsive to generating the prompt, recording the sound signal in memory, computing a power spectral density of the sound signal, determining a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilizing a plurality of components of the power spectral density of the sound signal between the sound start-up and sound drop-off points to create a set of sound calibration parameters, and processing subsequent sound signals with the calibration parameters to determine if they are comparable to the sound signal.
- FIG. 1A depicts a diagram of an example system of the application that consists of horn generation apparatus, sound sensing and processing apparatus and an optional voice prompt generation apparatus.
- FIG. 1B depicts a diagram of the method of the application that consists of a calibration phase and a sensing phase.
- FIG. 2 is a diagram of the calibration phase of an example embodiment of the application.
- FIG. 3A illustrates an example amplitude versus time plot of horn sound data acquired for calibration in an example embodiment of the application using an analog-to-digital converter when considerable background noise is present.
- FIG. 3B and FIG. 3C are power spectral density (PSD) estimates in an example embodiment of the application before and after the user depresses the horn button, respectively.
- PSD power spectral density
- FIG. 3D illustrates the horn calibration parameters in an example embodiment of the application.
- FIG. 4 is a diagram of the sensing phase of an example embodiment of the application.
- FIG. 5 depicts a diagram of a processor and a connected memory that can be resident on one or more of the devices or modules according to an embodiment of the application.
- the present application provides a system, method and non-transitory computer readable medium that provides using a vehicle horn as an inexpensive user input interface to serve the function of a simple push button switch for an in-vehicle device or system.
- the use of the vehicle horn as a user input interface to an in-vehicle device or system is novel.
- This description of example embodiments illustrates application details that take advantage of the properties of the vehicle horn sound to allow efficient processing that can be implemented on a a processor (such as a low cost processor). Given these examples, many other embodiments are obvious to one skilled in the art.
- FIG. 2 is a diagram of an example embodiment of the calibration phase horn sound acquisition and processing 160 of the application.
- the beginning of the Acquisition of Sound Sensor Data for Calibration 210 occurs when the operator is issued the “depress the horn for 4 seconds” voice prompt.
- the calibration process may continue monitoring the sound sensor for a pre-determined duration, for example, 6 seconds after the prompt is played.
- the voice prompt is a preferred but optional means of prompting the user.
- Other well-known user prompt methods and apparatus which may be used include, for example, a processor generated beep sound or blinking light, the meaning of which might be explained in a user manual or training video. For readability, this description will henceforth refer only to the voice prompt implementation.
- FIG. 3A illustrates an example amplitude versus time plot of sound data acquired for calibration using an analog-to-digital converter with a sample rate of 8000 samples per second.
- the horn goes ON at the first narrow arrow 310 and goes OFF at the second narrow arrow 320 .
- This example horn data is from a 2001 Chevrolet Tahoe parked near a busy road.
- the sound data is input to a Power Spectrum Measurement function 220 which computes a sequence of power spectral density (PSD) estimates, where each PSD provides amplitude versus frequency information.
- PSD power spectral density
- FIGS. 3B and 3C are PSD estimates computed using FFT techniques on data that is located as indicated by the broad arrows 330 and 340 , respectively in FIG. 3A .
- FIG. 3B is computed from sound data that was acquired before the user depressed the horn button and shows the spectrum of the background noise.
- FIG. 3C is computed from sound data that was acquired with the horn ON. It is clear from comparing FIGS. 3A , 3 B and 3 C that the horn being ON is easier to see in the computed PSD amplitude versus frequency data than the original amplitude versus time sampled sound data.
- a Signal Power Measurement 230 inputs the PSD data from the Power Spectrum Measurement 220 and that a subsequent Horn ON/OFF Decision 240 is based on the signal power measurement from PSD data.
- An example of a simple signal power measurement algorithm that is suitable here is to take the average of the 10 largest amplitude PSD bins above some moderately low frequency, for example 500 Hz.
- the Horn ON/OFF Decision 240 would then be accurate using a threshold of 500, for example. It is well known to those skilled in the art that many other reliable approaches exist (such as simply summing all of the PSD bins above 500 MHz) for making a horn ON/OFF decision given sound data recorded in a short duration observation window immediately following a prompt for the user to honk the horn.
- the calibration phase Horn ON/OFF Decision 240 has the advantage that during calibration the user may be encouraged to reduce the ambient sound noise.
- the Horn ON/OFF Decision 240 is input to the Spectrum Analysis 250 which also inputs the sequential PSD data vectors from the Power Spectrum Measurement 220 .
- the Spectrum Analysis 250 may input a new 128 element PSD data vector every 64 milliseconds.
- the PSD data vectors displayed in FIGS. 3B and 3 C are examples of such PSD data vectors.
- An example embodiment of the Spectrum Analysis 250 processing is to simply determine the frequency and amplitude of the M largest ‘tones’, e.g., sharp spectral features, for frequencies above some moderately low frequency, for example 500 Hz.
- the Spectrum Analysis 250 in this example embodiment may then output the frequency and amplitude data of the M largest tones as the Horn Identification Calibration Parameters 260 .
- vehicle horn sound recognition can be based on a relatively simple analysis, for example, of efficiently computed power spectral density data, is one aspect of the application.
- Sound recognition in general is like speech recognition in that it can be both algorithmically and computationally demanding as discussed, for example, by Michael Cowling and Renate Sitte in the article “ Analysis of Speech Recognition Techniques for use in a Non - Speech Sound Recognition System ”, in Proceedings 6th International Symposium on Digital Signal Processing for Communication Systems, (2002) and in the article “Comparison of Techniques for Environmental Sound Recognition”, in Pattern Recognition Letters 24 (2003).
- vehicle horn as a user input to provide the function of a push button switch for in-vehicle devices is attractive in part due to the relatively straightforward signal processing required for horn sound recognition and the ability to do this processing with a low percentage of the total computational capacity of an inexpensive embedded processor.
- the diagrammed example embodiment of the Calibration Phase Horn Sound Acquisition and Processing 160 also includes a Parameter Qualification 270 that inputs the Horn Identification Calibration Parameters 260 and the signal detection information from Horn ON/OFF Decision 240 .
- the Parameter Qualification 270 decides if the calibration is satisfactory and, in this example embodiment, provides a Calibration Quality Report as output to the Calibration Control module 280 .
- the Calibration Quality Report may, based on the signal detection information from Horn ON/OFF Decision 240 , indicate that the horn was not properly held continuously ON as requested or that the background noise level needs to be reduced.
- the calibration is suspect and deserves to be repeated.
- the data in the Horn Identification Calibration Parameters 260 are reproduced within the expected variability, then the calibration may be trusted.
- the sound processor and voice prompt apparatus of FIG. 1A may report to the user that “horn input (to the in-vehicle device) is calibrated and active”.
- FIG. 4 is a diagram of an example embodiment of the Sensing Phase Sound Acquisition and Processing 180 of the application.
- sound data may be continuously acquired by Continuous Acquisition of Sound Sensor Data 410 and processed by the Power Spectrum Measurement 420 which may be identical to the Power Spectrum Measurement 220 of FIG. 2 .
- the PSD data from 420 is then input to a Spectrum Analysis element 430 , which is similar to the Spectrum Analysis 250 in FIG. 2 that is described above for the calibration phase processing.
- An important difference is that the Spectrum Analysis 430 has no prior knowledge that the horn is ON or OFF and simply outputs a sequence of Locally Measured Identification Parameters 440 . Indeed, this sequence of parameters usually corresponds to sound sensor data that is acquired when the horn is OFF.
- the parameter extraction algorithm that the Spectrum Analysis 430 uses to process the PSD data vectors during sensing is defined by the parameter extraction algorithm that the Spectrum Analysis 250 uses to process the PSD data vectors during calibration.
- the Power Spectrum Measurement elements 220 and 420 are block processing, since they calculate a PSD using FFT techniques. For example, these processing elements may output a 128 length PSD data vector every 64 milliseconds.
- the subsequent sensing phase processing elements 430 , 440 , 450 , 460 and 470 in FIG. 4 are intended to operate at the same rate as 420 , i.e., they may also execute every 64 milliseconds in this example embodiment.
- a Determine Detection Statistic element 450 inputs both the Horn Identification Calibration Parameters 260 that were determined during the calibration phase and the Locally Measured Identification Parameters 440 .
- the Determine Detection Statistic processing element 450 executes an algorithm for computing a detection statistic.
- the detection statistic algorithm is preferably motivated by some statistical detection theory so that the numerical value of the statistic is useful for determining whether the horn is ON (or OFF).
- a suitable reference on detection theory is Fundamentals of Statistical Signal Processing, Volume 2 : Detection Theory , by Steven M. Kay, Prentice Hall (1998).
- a simple approach that is consistent with the traditional Gaussian detection theory and the linear horn model of the Lemaitre et al. and the linear FFT processing is to define the processing of the Determine Detection Statistic module 450 in terms of a simple spectral amplitude matched filter.
- the Locally Measured Identification Parameters 440 consists of M PSD amplitude values at these same M frequencies, and we notate these amplitude values as the M-element vector LMIP.
- D(k) max ⁇ HICP(n)*LMIP(k)
- HICP(n) is an M element vector containing the n th set of amplitudes in the Horn Identification Calibration Parameters 260 ;
- LMIP(k) is an M element vector defined by the Locally Measured Identification Parameters 440 for the k th processing block;
- the * represents vector dot product which is an element by element multiplication with summation over the products;
- the detection statistic D(k) can be compared to a threshold T and the horn is decided to be ON if D(k)>T and is decided to be OFF otherwise.
- the threshold T may be preset or determined during the calibration phase and included in the Horn Identification Calibration Parameters 260 .
- the Push Button Detection Decision 470 makes the decision on whether the vehicle operator has used the horn to communicate ‘push button’ to the in-vehicle device and outputs this decision as shown in FIG. 4 .
- Push Button Detection Decision 470 may analyze the variability of the detection statistic D(k) sequence to determine an effective signal to noise ratio (SNR) for this statistic as
- SNR signal to noise ratio
- the sequence of local horn ON or OFF decisions may also disqualify the ‘button pushed’ from being decided to be true, based on the duration of the horn sound being too short. A “4” second duration horn sound is required for the ‘button pushed’ hypothesis to be decided true.
- FIG. 5 depicts a processor 502 and a connected memory 504 that can be resident on any of the devices described or depicted herein, for example the In-Vehicle Device diagramed in FIG. 1A .
- a novel use of the vehicle horn as a user input interface to an in-vehicle device has been described.
- the above example embodiment illustrates application details that take advantage of the properties of the vehicle horn sound to allow efficient processing that can be implemented on a low cost processor.
- Several of the individual process modules in both the calibration phase diagrammed in FIG. 2 and the sensing phase and the calibration phase diagrammed in FIG. 4 may be combined or further distributed.
- the Signal Power Measurement and Horn ON/OFF Decision modules may be considered part of the Signal Analysis module.
- Many other embodiments of both the calibration phase processing and the sensing phase processing should be obvious to one skilled in the art.
- a computer program may be embodied on a computer readable medium, such as a storage medium.
- a computer program may reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.
- An exemplary storage medium may be coupled to the processor such that the processor may read information from, and write information to, the storage medium.
- the storage medium may be integral to the processor.
- the processor and the storage medium may reside in an application specific integrated circuit (“ASIC”).
- ASIC application specific integrated circuit
- the processor and the storage medium may reside as discrete components.
- the capabilities of the systems can be performed by one or more of the operations or components described herein or in a distributed architecture and may include a transmitter, receiver or pair of both.
- all or part of the functionality performed by the individual operations may be performed by one or more of these operations.
- the functionality described herein may be performed at various times and in relation to various events, internal or external to the operations or components.
- the information sent between various operations can be sent between the operations via at least one of: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device and/or via plurality of protocols. Also, the messages sent or received by any of the operations may be sent or received directly and/or via one or more of the other operations.
- a “system” could be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a smartphone or any other suitable computing device, or combination of devices.
- PDA personal digital assistant
- Presenting the above-described functions as being performed by a “system” is not intended to limit the scope of the present application in any way, but is intended to provide one example of many embodiments of the present application. Indeed, methods, systems and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technology.
- a operation may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
- VLSI very large scale integration
- a operation may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.
- a operation may also be at least partially implemented in software for execution by various types of processors.
- An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified operation need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the operation and achieve the stated purpose for the operation. Further, operations may be stored on a computer-readable medium, which may be, for instance, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium used to store data.
- RAM random access memory
- a operation of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
- operational data may be identified and illustrated herein within operations, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
Abstract
Description
- This application claims priority to and is a continuation of U.S. application Ser. No. 13/907,885, entitled “Horn Input to In-Vehicle Devices and Systems”, filed Jun. 1, 2013, now issued U.S. Pat. No. 9,024,739, issued May 5, 2015, which claims priority to U.S. provisional application No. 61/658,613, entitled “Horn Input to In-Vehicle Devices and System”, filed Jun. 12, 2012. This application is related to commonly assigned application Ser. No. 13/276,991, entitled “Detecting a Transport Emergency Event and Directly Enabling Emergency Services”, filed Oct. 19, 2011, now issued U.S. Pat. No. 8,676,151, issued Mar. 18, 2014, and U.S. application Ser. No. 13/907,880, entitled “Qualifying Automatic Vehicle Crash Emergency Calls to Public Safety Answering Points”, filed Jun. 1, 2013, and U.S. application Ser. No. 13/907,883, entitled “Qualifying Automatic Vehicle Crash Emergency Calls to Public Safety Answering Points”, filed Jun. 1, 2013, now issued U.S. Pat. No. 9,020,690, issued Apr. 28, 2015 and U.S. application Ser. No. 13/907,887, entitled “Mounting Angle Calibration for an In-Vehicle Accelerometer Device”, filed Jun. 1, 2013, and U.S. application Ser. No. 13/907,889, entitled “Automatic Speech Message Validation of an Emergency Teletype Text Message”, filed Jun. 1, 2013. The contents of which are hereby incorporated by reference in their entireties.
- The present application relates to user input to transport systems and devices, in-vehicle data-acquisition systems and transport telematics devices; and more particularly, the use of the horn in a vehicle, or other form of transport, for user input to a device or system that is located in or on the transport.
- In-vehicle devices and systems will refer herein to devices and systems that are installed on a vehicle. Aftermarket in-vehicle devices and systems will refer to devices and systems that are installed on a vehicle after the vehicle has been manufactured, i.e. these devices are not factory installed. Although this application description will focus on the use of the horn as an input interface to aftermarket telematics devices which are electronic devices, the application applies to in-vehicle devices and systems in general, aftermarket or factory installed, electronic or not. The application is not restricted to aftermarket devices and systems since embodiments of the application can be implemented at the vehicle manufacturing plant. However, as developed below, a definite need for the application is associated with certain unreadily accessible aftermarket devices and systems. Furthermore, the application is not restricted to vehicles since operators of other forms of transport use horns as a means of warning others or gaining attention to the transport operations and the application applies to these transports as well. The term ‘vehicle’ will be used for readability but should be interpreted as including these other forms of transport.
- Vehicle telematics devices and systems employ telecommunications and information processing for a variety on-board functions and communication capabilities. Examples of vehicle telematics functions include emergency warning, GPS navigation, integrated hands-free cell phones, automatic crash notification, wireless safety communications, and automatic driving assistance. Several new car manufacturers offer factory-installed telematics systems in their new vehicles. For example, General Motors Corporations offers the OnStar® system, Ford Corporation offers the SYNC® system, and Hughes Telematics offers their system through OEM arrangements with manufactures such as Mercedes-Benz Corporation.
- In addition, a growing aftermarket telematics device and system industry offers telematics devices for use in existing vehicles. These aftermarket telematics products enable the upgrade of older vehicles with similar telematics functions as those available on new cars. Additionally, these aftermarket telematics products may provide additional functions, for example fleet tracking, or the capture of vehicle telemetry data for usage based vehicle insurance rating. Examples of fleet tracking devices are available from CES Wireless Corporation and Sierra Wireless Corporation. The Snapshot® device from Progressive Insurance Company is a well-known telematics device for usage-based insurance. Like several of the newer aftermarket telematics products, the ‘Snapshot’ device plugs into and draws power from the vehicle's standardized on-board diagnostic port, referred to as an ‘OBDII’ connector. The OBDII plug-in devices provide a straightforward user installation. In comparison, several commercial fleet tracking devices are still rugged ‘bricks’ the size of a blackboard eraser or larger that are intended for professional installation involving more elaborate mechanical mountings and custom wiring.
- The installation location of both factory installed and certain aftermarket devices and systems may not always fall within convenient arm's reach of the operator. For example, a device may be installed inside the dashboard of the vehicle. In the case of factory installed telematics systems, these concealed locations may not be problematic if a well-designed user interface is provided. Such a user interface may be readily integrated into the design of the dash or steering wheel, allowing for ergonomically placed controls or touch screen displays. Indeed, a quality user interface to factory installed telematics systems provides a valuable feature that may be used in marketing to enhance vehicle sales.
- In the case of many aftermarket devices however, the concealed nature of the device installation is problematic to providing even a minimal user input interface. These types of aftermarket telematics systems, such as fleet tracking devices, automatic crash notification devices, and usage based insurance devices, would benefit from an accessible push button switch user input interface. These systems do not require a more elaborate interface such as a touch screen or keypad. For example, a push button switch user input interface is desirable so the driver can respond to synthesized voice prompts in order to configure or command the telematics system. Also, an un-prompted push button user input could serve as an emergency HELP/MAYDAY switch to initiate contact with a telematics service center or ‘911’ emergency dispatch operator.
- Note the terms ‘switch’, ‘push button’ and ‘push button switch’ are used interchangeably here and meant to include any type of binary or ON/OFF control signaling method that is easily and directly activated and/or inactivated by the user. An example of this type of switch is a push button near the overhead interior light in the passenger compartment of a vehicle that the occupants use to turn the light ON or OFF. The term ‘user’ here generally refers to the operator of the vehicle but may also include vehicle occupants.
- Several undesirable systems and methods exist for providing a push button switch as a user input interface to an aftermarket device that is concealed from the user, for example a device that is under or inside the dash of the passenger compartment. One such method, for example, is to mount a switch somewhere on the dash and connect the switch to the device by means of wires or wireless signaling. This is undesirable cosmetically—very few vehicle owners want a button glued or otherwise attached to the dashboard of their vehicle. A remote wireless button creates the need for a power source, and if a battery is used for power, the requirement to replace or recharge the battery. Another approach that is also undesirable is to rewire an existing control on the dash so that it is wired to the aftermarket device instead of being wired by the car manufacturer. This approach would be difficult to implement, result in permanent vehicle damage, and may void the vehicle's warranty.
- Voice activation may initially appear to be an attractive solution for providing a simple user input interface for an inaccessibly installed aftermarket device. However, the audio signal processing technology that is required to provide a reliable voice activation user interface has a large processing burden and may be difficult to economically justify. These telematics devices plug into the OBDII connector for device mounting, power source, and access to vehicle diagnostic data. Voice activation technology is superfluous for a simple push button switch type of user interface for these reduced cost telematics devices. For example, the push button switch may only be needed for user-aided configuration of the device and for providing the user with HELP/MAYDAY button functionality.
- What would be optimal is an inexpensive and accessible user input interface for in-vehicle devices and systems that can serve the function of a simple push button switch. For example, this type of user interface is needed for low cost, user-installed, consumer-oriented, OBDII-mounted telematics devices. Such an interface will allow enhanced functionality, for example, by allowing the user to configure and command the device in response to audio prompts and by providing the user with a HELP/MAYDAY button function that can be used to obtain help in an emergency.
- The present application provides systems and methods that use a vehicle horn to provide an inexpensive user input interface that can serve the function of a push button switch for an in-vehicle device or system. Example embodiments contain a vehicle horn with a horn control button switch, a sound sensor, such as a microphone, and a sound processor. An example method makes use of a calibration phase and a sensing phase. During the calibration phase, horn sound data is acquired and processed to extract horn identification parameters. During the sensing phase, sound data is acquired and processed using the horn identification parameters. This sensing processing determines: 1) if the detected horn sound appears to match the one used for calibration, and 2) whether the vehicle driver is using the horn for normal alerting purposes to a third party, or to communicate with the in-vehicle device. In the latter case, the driver uses the vehicle horn to provide an effective push button input to the device.
-
FIGS. 1A and 1B diagram a system and method, respectively, of an example embodiment of the present application. The example system of the application diagrammed inFIG. 1A includes a horn sound generation apparatus, sound sensing and processing apparatus, and an optional voice prompt generation apparatus. The horn sound generation apparatus is ahorn 110 that is activated by avehicle horn switch 120 that the driver uses to honk the horn. The sound sensing apparatus consists of asound sensor 130 and asound processor 140. The voiceprompt generator apparatus 150, for example, may be an audio player of prerecorded voice recordings. In some embodiments thesound sensor 130, thesound processor 140 and the voiceprompt generator 150 may reside in the in-vehicle device 155 as shown inFIG. 1A . Alternatively, these apparatus elements in other embodiments (not shown) may be external to the in-vehicle device and the decision for Push Button ON/OFF 145 may be communicated with the device via well-known wireline or wireless techniques, for example by means of a Bluetooth wireless link. - The example method of the application diagrammed in
FIG. 1B , consists of the Acquisition of SoundSensor Data process 155 which involves sampling data from thesound sensor 130, the process called Calibration Phase Horn Sound Acquisition andProcessing 160 which determines the HornIdentification Calibration Parameters 170 and the process called Sensing Phase Sound Acquisition andProcessing 180 which uses the HornIdentification Calibration Parameters 170 and determines a decision for Push Button ON/OFF 190. In preferred embodiments, the signal processing in the calibration phase analyzes the harmonic nature of the user's vehicle horn sound to parametrically characterize the harmonics in the sound. The signal processing in the sensing phase then uses these parameters to detect the presence or absence of a sound with the same parametrically defined harmonics. - In one example embodiment of the application, the in-
vehicle device 155 ofFIG. 1A is an aftermarket telematics device that plugs into the vehicle's OBDII diagnostic port and performs automatic crash notification (ACN). Such a telematics device is described in U.S. patent application Ser. No. 13/276,991 titled “Detecting a Transport Emergency Event and Directly Enabling Emergency Services” which is incorporated in its entirety by reference herein. In this example embodiment, during the calibration phase the driver is instructed to “depress the horn for 4 seconds” after which the device may report that it is ‘calibrated and active’. The amount of time the horn should be depressed for calibration and activation can be less or more than 4 seconds. If the active ACN device sometime later detects a relatively minor, low speed vehicle crash, the device may issue voice prompts to the driver, “depress the horn for 4 seconds if you want to call the 911 operator.” If he or she does, a 911 call is immediately placed. Many other use cases are available for even this one example embodiment of the application. - One example embodiment may provide a method that includes generating a prompt to initiate a sound signal, receiving the sound signal responsive to generating the prompt, recording the sound signal in memory, computing a power spectral density of the sound signal, determining a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilizing a plurality of components of the power spectral density of the sound signal between the sound start-up and the sound drop-off points to create a set of sound calibration parameters, and processing subsequent sound signals with the calibration parameters to determine if they are comparable to the sound signal.
- Another example embodiment may provide an apparatus that includes a processor configured to generate a prompt to initiate a sound signal, a receiver configured to receive the sound signal responsive to the generated prompt, a memory configured to record the sound signal, a processor configured to compute a power spectral density of the sound signal, determine a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilize a plurality of components of the power spectral density of the sound signal between the sound start-up and sound drop-off points to create a set of sound calibration parameters, and process subsequent sound signals the calibration parameters to determine if they are comparable to the sound signal.
- Another example embodiment may provide a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform generating a prompt to initiate a sound signal, receiving the sound signal responsive to generating the prompt, recording the sound signal in memory, computing a power spectral density of the sound signal, determining a sound start-up point and a sound drop-off point of the sound signal based on signal power identified from the computed power spectral density, utilizing a plurality of components of the power spectral density of the sound signal between the sound start-up and sound drop-off points to create a set of sound calibration parameters, and processing subsequent sound signals with the calibration parameters to determine if they are comparable to the sound signal.
-
FIG. 1A depicts a diagram of an example system of the application that consists of horn generation apparatus, sound sensing and processing apparatus and an optional voice prompt generation apparatus. -
FIG. 1B depicts a diagram of the method of the application that consists of a calibration phase and a sensing phase. -
FIG. 2 is a diagram of the calibration phase of an example embodiment of the application. -
FIG. 3A illustrates an example amplitude versus time plot of horn sound data acquired for calibration in an example embodiment of the application using an analog-to-digital converter when considerable background noise is present. -
FIG. 3B andFIG. 3C are power spectral density (PSD) estimates in an example embodiment of the application before and after the user depresses the horn button, respectively. -
FIG. 3D illustrates the horn calibration parameters in an example embodiment of the application. -
FIG. 4 is a diagram of the sensing phase of an example embodiment of the application. -
FIG. 5 depicts a diagram of a processor and a connected memory that can be resident on one or more of the devices or modules according to an embodiment of the application. - The present application provides a system, method and non-transitory computer readable medium that provides using a vehicle horn as an inexpensive user input interface to serve the function of a simple push button switch for an in-vehicle device or system. The use of the vehicle horn as a user input interface to an in-vehicle device or system is novel. This description of example embodiments illustrates application details that take advantage of the properties of the vehicle horn sound to allow efficient processing that can be implemented on a a processor (such as a low cost processor). Given these examples, many other embodiments are obvious to one skilled in the art.
-
FIG. 2 is a diagram of an example embodiment of the calibration phase horn sound acquisition and processing 160 of the application. In this embodiment, under the control of thecalibration control module 280, the beginning of the Acquisition of Sound Sensor Data forCalibration 210 occurs when the operator is issued the “depress the horn for 4 seconds” voice prompt. The calibration process may continue monitoring the sound sensor for a pre-determined duration, for example, 6 seconds after the prompt is played. Note here and elsewhere that the voice prompt is a preferred but optional means of prompting the user. Other well-known user prompt methods and apparatus which may be used include, for example, a processor generated beep sound or blinking light, the meaning of which might be explained in a user manual or training video. For readability, this description will henceforth refer only to the voice prompt implementation. -
FIG. 3A illustrates an example amplitude versus time plot of sound data acquired for calibration using an analog-to-digital converter with a sample rate of 8000 samples per second. In this example, although there is considerable background noise, it is still apparent that the horn goes ON at the firstnarrow arrow 310 and goes OFF at the secondnarrow arrow 320. This example horn data is from a 2001 Chevrolet Tahoe parked near a busy road. - Referring to
FIG. 2 , the sound data is input to a PowerSpectrum Measurement function 220 which computes a sequence of power spectral density (PSD) estimates, where each PSD provides amplitude versus frequency information. For example, well known methods exist for using Fast Fourier Transform (FFT) algorithms to efficiently compute PSD estimates for sampled and digitized data.FIGS. 3B and 3C are PSD estimates computed using FFT techniques on data that is located as indicated by thebroad arrows FIG. 3A .FIG. 3B is computed from sound data that was acquired before the user depressed the horn button and shows the spectrum of the background noise.FIG. 3C is computed from sound data that was acquired with the horn ON. It is clear from comparingFIGS. 3A , 3B and 3C that the horn being ON is easier to see in the computed PSD amplitude versus frequency data than the original amplitude versus time sampled sound data. - Referring again to
FIG. 2 , it is for this reason (e.g., that the horn being ON is readily apparent in the PSD data) that aSignal Power Measurement 230 inputs the PSD data from thePower Spectrum Measurement 220 and that a subsequent Horn ON/OFF Decision 240 is based on the signal power measurement from PSD data. An example of a simple signal power measurement algorithm that is suitable here is to take the average of the 10 largest amplitude PSD bins above some moderately low frequency, for example 500 Hz. (For example if there were only 7 bins above some frequency and if these 7 bins are represented by the vector PSDbins=[988 25 44 82 720 51 6 33] then the average of the 2 largest bins is (988+720)/2=854.) For the data shown inFIGS. 3B and 3C , this provides signal power measurements of 188 and 1163, respectively. The Horn ON/OFF Decision 240 would then be accurate using a threshold of 500, for example. It is well known to those skilled in the art that many other reliable approaches exist (such as simply summing all of the PSD bins above 500 MHz) for making a horn ON/OFF decision given sound data recorded in a short duration observation window immediately following a prompt for the user to honk the horn. The calibration phase Horn ON/OFF Decision 240 has the advantage that during calibration the user may be encouraged to reduce the ambient sound noise. - Referring again to
FIG. 2 , the Horn ON/OFF Decision 240 is input to theSpectrum Analysis 250 which also inputs the sequential PSD data vectors from thePower Spectrum Measurement 220. For example, given a sound data sample rate of 8000 samples per second and block processing FFT based PSD measurement with block size of 512 real sound samples and an FFT size of NFFT=256, theSpectrum Analysis 250 may input a new 128 element PSD data vector every 64 milliseconds. The PSD data vectors displayed inFIGS. 3B and 3C are examples of such PSD data vectors. An example embodiment of theSpectrum Analysis 250 processing is to simply determine the frequency and amplitude of the M largest ‘tones’, e.g., sharp spectral features, for frequencies above some moderately low frequency, for example 500 Hz. Since individual tones may span multiple PSD frequency bins this separated tone processing is different than determining the M largest PSD data elements, as is well known (The M largest PSD elements may contain bins that are adjacent and hence do not belong to separate tones.) TheSpectrum Analysis 250 in this example embodiment may then output the frequency and amplitude data of the M largest tones as the HornIdentification Calibration Parameters 260. -
FIG. 3D illustrates the HornIdentification Calibration Parameters 260 for a version of this example embodiment wherein theSpectrum Analysis 250 simply records the frequency and amplitude parameters M=5 largest separated tones. The 5 largest tones are identified by the letters “a” to “e” in bothFIGS. 3C and 3D . The data in the frequency and amplitude columns of the table inFIG. 3D constitute the HornIdentification Calibration Parameters 260. - It is observed in practice that for horn sounds of several seconds, the PSD data is nearly stationary for some vehicle horns but slowly changing for other vehicle horns. Both of these types of observed vehicle horns are in agreement with the vehicle horn model of Guillaume Lemaitre, Patrick Susini, Suzanne Winsberg, Stephen McAdams in “The Sound Quality of Car Horns: Designing New Representative Sounds”, Acta Acustica united with Acustica, Vol. 95 (2009). The slowly changing, non-stationary vehicle horns motivate taking multiple sets of measurements during the calibration horn sound. For example, the frequency and amplitude data of the M largest tones can be measured every half second for a 4-second calibration horn sound. In this case, the Horn
Identification Calibration Parameters 260 consists of N=8 sequential sets of frequency and amplitude data. The total number of parameters to be stored in the HornIdentification Calibration Parameters 260 for M=5 is then N*M*2 or 8*5*2=80 parameters each of which can be stored in 2 bytes for a small total parameter storage requirement of 160 bytes. - Note that the realization that vehicle horn sound recognition can be based on a relatively simple analysis, for example, of efficiently computed power spectral density data, is one aspect of the application. Sound recognition in general, however, is like speech recognition in that it can be both algorithmically and computationally demanding as discussed, for example, by Michael Cowling and Renate Sitte in the article “Analysis of Speech Recognition Techniques for use in a Non-Speech Sound Recognition System”, in Proceedings 6th International Symposium on Digital Signal Processing for Communication Systems, (2002) and in the article “Comparison of Techniques for Environmental Sound Recognition”, in Pattern Recognition Letters 24 (2003). Using the vehicle horn as a user input to provide the function of a push button switch for in-vehicle devices is attractive in part due to the relatively straightforward signal processing required for horn sound recognition and the ability to do this processing with a low percentage of the total computational capacity of an inexpensive embedded processor.
- Referring again to
FIG. 2 , the diagrammed example embodiment of the Calibration Phase Horn Sound Acquisition andProcessing 160 also includes aParameter Qualification 270 that inputs the HornIdentification Calibration Parameters 260 and the signal detection information from Horn ON/OFF Decision 240. TheParameter Qualification 270 decides if the calibration is satisfactory and, in this example embodiment, provides a Calibration Quality Report as output to theCalibration Control module 280. For example, the Calibration Quality Report may, based on the signal detection information from Horn ON/OFF Decision 240, indicate that the horn was not properly held continuously ON as requested or that the background noise level needs to be reduced. Alternatively, the Calibration Quality Report may ask for a repeat calibration based on the absence of any harmonic relationships between the M=5 largest tones in the HornIdentification Calibration Parameters 260. Note the comments inFIG. 3D for examples of the expected harmonic nature of a vehicle horn sound. Typically, if none of the higher frequency tones have frequencies that are multiples of one of the two lowest frequency tones then the calibration is suspect and deserves to be repeated. If upon repetition of the calibration process, the data in the HornIdentification Calibration Parameters 260 are reproduced within the expected variability, then the calibration may be trusted. Upon successful completion of the calibration phase, the sound processor and voice prompt apparatus ofFIG. 1A may report to the user that “horn input (to the in-vehicle device) is calibrated and active”. -
FIG. 4 is a diagram of an example embodiment of the Sensing Phase Sound Acquisition andProcessing 180 of the application. In this example, sound data may be continuously acquired by Continuous Acquisition ofSound Sensor Data 410 and processed by thePower Spectrum Measurement 420 which may be identical to thePower Spectrum Measurement 220 ofFIG. 2 . The PSD data from 420 is then input to aSpectrum Analysis element 430, which is similar to theSpectrum Analysis 250 inFIG. 2 that is described above for the calibration phase processing. An important difference is that theSpectrum Analysis 430 has no prior knowledge that the horn is ON or OFF and simply outputs a sequence of Locally MeasuredIdentification Parameters 440. Indeed, this sequence of parameters usually corresponds to sound sensor data that is acquired when the horn is OFF. The parameter extraction algorithm that theSpectrum Analysis 430 uses to process the PSD data vectors during sensing is defined by the parameter extraction algorithm that theSpectrum Analysis 250 uses to process the PSD data vectors during calibration. - Note that in this example embodiment, the Power
Spectrum Measurement elements phase processing elements FIG. 4 are intended to operate at the same rate as 420, i.e., they may also execute every 64 milliseconds in this example embodiment. - Referring to
FIG. 4 , in this example embodiment of the Sensing Phase Sound Acquisition andProcessing 180, a Determine DetectionStatistic element 450 inputs both the HornIdentification Calibration Parameters 260 that were determined during the calibration phase and the Locally MeasuredIdentification Parameters 440. The Determine DetectionStatistic processing element 450 executes an algorithm for computing a detection statistic. The detection statistic algorithm is preferably motivated by some statistical detection theory so that the numerical value of the statistic is useful for determining whether the horn is ON (or OFF). A suitable reference on detection theory is Fundamentals of Statistical Signal Processing, Volume 2: Detection Theory, by Steven M. Kay, Prentice Hall (1998). - For example, a simple approach that is consistent with the traditional Gaussian detection theory and the linear horn model of the Lemaitre et al. and the linear FFT processing is to define the processing of the Determine Detection
Statistic module 450 in terms of a simple spectral amplitude matched filter. In this example embodiment, the N sets of M PSD amplitude values at the M frequencies are such that the M frequencies are the kept the same for all N sets that constitute the HornIdentification Calibration Parameters 260, and we notate these amplitude values as N M-element vectors HICP(n) where n=1:N. Furthermore, the Locally MeasuredIdentification Parameters 440 consists of M PSD amplitude values at these same M frequencies, and we notate these amplitude values as the M-element vector LMIP. A suitable detection statistic is then defined by the maximum of N vector dot products of LMIP and HICP(n) for n=1:N. The processing sequence of this detection statistic can then be written - D(k)=max {HICP(n)*LMIP(k)|n=1:N}; where D(k) is the detection statistic for block processing index k=1, 2, 3, . . . ; which in the example embodiment represents the sequence of blocks that are separated by 64 milliseconds of time. HICP(n) is an M element vector containing the nth set of amplitudes in the Horn
Identification Calibration Parameters 260; LMIP(k) is an M element vector defined by the Locally MeasuredIdentification Parameters 440 for the kth processing block; the * represents vector dot product which is an element by element multiplication with summation over the products; and the max{|n=1:N} indicates the maximum with respect to the N sets of M PSD amplitude values in the calibration data in HornIdentification Calibration Parameters 260. - Referring again to
FIG. 4 , in this example embodiment of the Sensing Phase Sound Acquisition andProcessing 180, a Local Horn ON/OFFDecision processing element 460 inputs the sequence of detection statistics D(k) for k=1, 2, 3 . . . and for each processing block k makes a decision as to whether the vehicle horn is ON or OFF. For example the detection statistic D(k) can be compared to a threshold T and the horn is decided to be ON if D(k)>T and is decided to be OFF otherwise. The threshold T may be preset or determined during the calibration phase and included in the HornIdentification Calibration Parameters 260. - Referring to
FIG. 4 , in this example embodiment of the Sensing Phase Sound Acquisition andProcessing 180, a PushButton Detection Decision 470 inputs the sequence of detection statistics D(k) for k=1, 2, 3 . . . from the Determine Detection Statistic 450 and also inputs the sequence of local horn ON or OFF decisions from Local Horn ON/OFF Decision 460. The PushButton Detection Decision 470 makes the decision on whether the vehicle operator has used the horn to communicate ‘push button’ to the in-vehicle device and outputs this decision as shown inFIG. 4 . For example, PushButton Detection Decision 470 may analyze the variability of the detection statistic D(k) sequence to determine an effective signal to noise ratio (SNR) for this statistic as - SNR=mean{D(k) k=1, 2, 3 . . . }/std{D(k) k=1, 2, 3 . . . }; which is the ratio of the mean of the D(k) sequence to the standard deviation of the D(k) sequence. If this SNR measurement is below some threshold Tsnr, then the decision is that the ‘button’ has not been pushed. The sequence of local horn ON or OFF decisions may also disqualify the ‘button pushed’ from being decided to be true, based on the duration of the horn sound being too short. A “4” second duration horn sound is required for the ‘button pushed’ hypothesis to be decided true.
- Note that any reference to an algorithm described or depicted herein is software or a computer program that is run by a processor resident on one or more devices or modules described or depicted herein.
FIG. 5 depicts aprocessor 502 and aconnected memory 504 that can be resident on any of the devices described or depicted herein, for example the In-Vehicle Device diagramed inFIG. 1A . - A novel use of the vehicle horn as a user input interface to an in-vehicle device has been described. The above example embodiment illustrates application details that take advantage of the properties of the vehicle horn sound to allow efficient processing that can be implemented on a low cost processor. Several of the individual process modules in both the calibration phase diagrammed in
FIG. 2 and the sensing phase and the calibration phase diagrammed inFIG. 4 may be combined or further distributed. For example in the calibration phase ofFIG. 2 , the Signal Power Measurement and Horn ON/OFF Decision modules may be considered part of the Signal Analysis module. Many other embodiments of both the calibration phase processing and the sensing phase processing should be obvious to one skilled in the art. - The operations of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a computer program executed by a processor, or in a combination of the two. A computer program may be embodied on a computer readable medium, such as a storage medium. For example, a computer program may reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.
- An exemplary storage medium (non-transitory storage medium) may be coupled to the processor such that the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit (“ASIC”). In the alternative, the processor and the storage medium may reside as discrete components.
- Although an exemplary embodiment of the system, method, and computer readable medium of the present application has been illustrated in the accompanied drawings and described in the foregoing detailed description, it will be understood that the application is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the spirit or scope of the application as set forth and defined by the following claims. For example, the capabilities of the systems can be performed by one or more of the operations or components described herein or in a distributed architecture and may include a transmitter, receiver or pair of both. For example, all or part of the functionality performed by the individual operations, may be performed by one or more of these operations. Further, the functionality described herein may be performed at various times and in relation to various events, internal or external to the operations or components. Also, the information sent between various operations can be sent between the operations via at least one of: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device and/or via plurality of protocols. Also, the messages sent or received by any of the operations may be sent or received directly and/or via one or more of the other operations.
- One skilled in the art will appreciate that a “system” could be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a smartphone or any other suitable computing device, or combination of devices. Presenting the above-described functions as being performed by a “system” is not intended to limit the scope of the present application in any way, but is intended to provide one example of many embodiments of the present application. Indeed, methods, systems and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technology.
- It should be noted that some of the system features described in this specification have been presented as operations, in order to more particularly emphasize their implementation independence. For example, a operation may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A operation may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.
- A operation may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified operation need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the operation and achieve the stated purpose for the operation. Further, operations may be stored on a computer-readable medium, which may be, for instance, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium used to store data.
- Indeed, a operation of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within operations, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
- It will be readily understood that the components of the application, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the application as claimed, but is merely representative of selected embodiments of the application.
- One having ordinary skill in the art will readily understand that the application as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations that are different than those which are disclosed. Therefore, although the application has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the application. In order to determine the metes and bounds of the application, therefore, reference should be made to the appended claims.
- While preferred embodiments of the present application have been described, it is to be understood that the embodiments described are illustrative only and the scope of the application is to be defined solely by the appended claims when considered with a full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms etc.) thereto.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/703,170 US20150232024A1 (en) | 2012-06-12 | 2015-05-04 | Horn Input to In-Vehicle Devices and Systems |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261658613P | 2012-06-12 | 2012-06-12 | |
US13/907,885 US9024739B2 (en) | 2012-06-12 | 2013-06-01 | Horn input to in-vehicle devices and systems |
US14/703,170 US20150232024A1 (en) | 2012-06-12 | 2015-05-04 | Horn Input to In-Vehicle Devices and Systems |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/907,885 Continuation US9024739B2 (en) | 2012-06-12 | 2013-06-01 | Horn input to in-vehicle devices and systems |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150232024A1 true US20150232024A1 (en) | 2015-08-20 |
Family
ID=49714819
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/907,885 Expired - Fee Related US9024739B2 (en) | 2012-06-12 | 2013-06-01 | Horn input to in-vehicle devices and systems |
US14/703,170 Abandoned US20150232024A1 (en) | 2012-06-12 | 2015-05-04 | Horn Input to In-Vehicle Devices and Systems |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/907,885 Expired - Fee Related US9024739B2 (en) | 2012-06-12 | 2013-06-01 | Horn input to in-vehicle devices and systems |
Country Status (1)
Country | Link |
---|---|
US (2) | US9024739B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130332105A1 (en) * | 2012-06-12 | 2013-12-12 | Guardity Technologies, Inc. | Mounting Angle Calibration for an In-Vehicle Accelerometer Device |
US10632908B2 (en) * | 2018-09-19 | 2020-04-28 | Ria Dubey | Method and apparatus for vehicular communication |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9024739B2 (en) * | 2012-06-12 | 2015-05-05 | Guardity Technologies, Inc. | Horn input to in-vehicle devices and systems |
US10540723B1 (en) * | 2014-07-21 | 2020-01-21 | State Farm Mutual Automobile Insurance Company | Methods of providing insurance savings based upon telematics and usage-based insurance |
US10664920B1 (en) | 2014-10-06 | 2020-05-26 | State Farm Mutual Automobile Insurance Company | Blockchain systems and methods for providing insurance coverage to affinity groups |
US20210166320A1 (en) | 2014-10-06 | 2021-06-03 | State Farm Mutual Automobile Insurance Company | System and method for obtaining and/or maintaining insurance coverage |
US20210358045A1 (en) | 2014-10-06 | 2021-11-18 | State Farm Mutual Automobile Insurance Company | Medical diagnostic-initiated insurance offering |
US11574368B1 (en) | 2014-10-06 | 2023-02-07 | State Farm Mutual Automobile Insurance Company | Risk mitigation for affinity groupings |
US10713728B1 (en) | 2014-10-06 | 2020-07-14 | State Farm Mutual Automobile Insurance Company | Risk mitigation for affinity groupings |
CN104369690B (en) * | 2014-11-10 | 2016-10-05 | 东南(福建)汽车工业有限公司 | One realizes voice and buzzer switchable dual pathways alarm device |
US9706404B2 (en) | 2015-04-07 | 2017-07-11 | Visa International Service Association | Out of band authentication with user device |
CN106303831B (en) * | 2016-09-29 | 2022-05-13 | 未来汽车科技(深圳)有限公司 | Method and device for processing audio signal of liquid crystal instrument and vehicle |
CN107294826B (en) * | 2017-05-27 | 2020-05-15 | 惠州市德赛西威汽车电子股份有限公司 | CAN network-based TBOX parameter calibration method and device |
DE102019202662B4 (en) * | 2019-02-27 | 2021-01-14 | Volkswagen Aktiengesellschaft | Method for checking the functionality of an emergency call device of a motor vehicle and motor vehicle for carrying out the method |
US11521239B2 (en) | 2020-04-27 | 2022-12-06 | Vbi Group, Inc. | Vehicle inventory and advertisement campaign system |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6118888A (en) * | 1997-02-28 | 2000-09-12 | Kabushiki Kaisha Toshiba | Multi-modal interface apparatus and method |
US6549757B1 (en) * | 1997-10-13 | 2003-04-15 | Telediffusion De France | Method and system for assessing, at reception level, the quality of a digital signal, such as a digital audio/video signal |
US20040081020A1 (en) * | 2002-10-23 | 2004-04-29 | Blosser Robert L. | Sonic identification system and method |
US20050232411A1 (en) * | 1999-10-27 | 2005-10-20 | Venugopal Srinivasan | Audio signature extraction and correlation |
US20100260353A1 (en) * | 2009-04-13 | 2010-10-14 | Sony Corporation | Noise reducing device and noise determining method |
US20130328671A1 (en) * | 2012-06-12 | 2013-12-12 | Guardity Technologies, Inc. | Horn Input to In-Vehicle Devices and Systems |
US20140087696A1 (en) * | 2011-05-25 | 2014-03-27 | Gemalto Sa | Secured element for performing a user authentication and user authentication method |
US20140089116A1 (en) * | 2012-09-24 | 2014-03-27 | Wal-Mart Stores, Inc. | Determination of customer proximity to a register through use of sound and methods thereof |
US20140292501A1 (en) * | 2013-03-27 | 2014-10-02 | Electronics And Telecommunications Research Institute | Apparatus and method for providing haptic effect using sound effect |
US20140294201A1 (en) * | 2011-07-28 | 2014-10-02 | Thomson Licensing | Audio calibration system and method |
-
2013
- 2013-06-01 US US13/907,885 patent/US9024739B2/en not_active Expired - Fee Related
-
2015
- 2015-05-04 US US14/703,170 patent/US20150232024A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6118888A (en) * | 1997-02-28 | 2000-09-12 | Kabushiki Kaisha Toshiba | Multi-modal interface apparatus and method |
US6549757B1 (en) * | 1997-10-13 | 2003-04-15 | Telediffusion De France | Method and system for assessing, at reception level, the quality of a digital signal, such as a digital audio/video signal |
US20050232411A1 (en) * | 1999-10-27 | 2005-10-20 | Venugopal Srinivasan | Audio signature extraction and correlation |
US20040081020A1 (en) * | 2002-10-23 | 2004-04-29 | Blosser Robert L. | Sonic identification system and method |
US20100260353A1 (en) * | 2009-04-13 | 2010-10-14 | Sony Corporation | Noise reducing device and noise determining method |
US20140087696A1 (en) * | 2011-05-25 | 2014-03-27 | Gemalto Sa | Secured element for performing a user authentication and user authentication method |
US20140294201A1 (en) * | 2011-07-28 | 2014-10-02 | Thomson Licensing | Audio calibration system and method |
US20130328671A1 (en) * | 2012-06-12 | 2013-12-12 | Guardity Technologies, Inc. | Horn Input to In-Vehicle Devices and Systems |
US20140089116A1 (en) * | 2012-09-24 | 2014-03-27 | Wal-Mart Stores, Inc. | Determination of customer proximity to a register through use of sound and methods thereof |
US20140292501A1 (en) * | 2013-03-27 | 2014-10-02 | Electronics And Telecommunications Research Institute | Apparatus and method for providing haptic effect using sound effect |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130332105A1 (en) * | 2012-06-12 | 2013-12-12 | Guardity Technologies, Inc. | Mounting Angle Calibration for an In-Vehicle Accelerometer Device |
US9599633B2 (en) * | 2012-06-12 | 2017-03-21 | Guardity Technologies, Inc. | Mounting angle calibration for an in-vehicle accelerometer device |
US10632908B2 (en) * | 2018-09-19 | 2020-04-28 | Ria Dubey | Method and apparatus for vehicular communication |
Also Published As
Publication number | Publication date |
---|---|
US9024739B2 (en) | 2015-05-05 |
US20130328671A1 (en) | 2013-12-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9024739B2 (en) | Horn input to in-vehicle devices and systems | |
US9392431B2 (en) | Automatic vehicle crash detection using onboard devices | |
CN106209138B (en) | Vehicle cautious emergency response system and method | |
US20110109450A1 (en) | System and method for detecting child left in vehicle using vehicle ignition detection via on-board diagnostics | |
CN101951468B (en) | Video recording device for vehicle and installation state informing method thereof | |
CN105844211A (en) | System and method for classifying a road surface | |
US10159410B2 (en) | Method and apparatus for biometric data gathering and dissemination | |
CN110929074A (en) | Vehicle-mounted voice broadcasting method and system | |
CN106126058A (en) | Based reminding method and device | |
KR101768640B1 (en) | Traffic accident receiving system and method using Minimum Set of Data | |
CN111882822A (en) | Reminding method and device for preventing children from being left in car and server | |
CN109932152B (en) | Automobile horn resonance detection device and detection method | |
EP2139276A2 (en) | Self-test method for a vehicular telematics unit | |
US10346132B2 (en) | Acceleration-based window glass break detection | |
JP2021182131A (en) | Method, device and system, electronic device, computer readable storage medium and computer program for outputting information | |
JP2019068222A (en) | Loudspeaker monitoring device and loudspeaker monitoring method | |
KR101862461B1 (en) | Method and apparatus for estimating location of sound source location based on wideband frequency | |
WO2015145731A1 (en) | Vehicle information notification device | |
CN110901655B (en) | Automobile main driving position identification method and terminal equipment | |
CA3031260C (en) | Acceleration-based window glass break detection | |
CN114763097A (en) | Intelligent warning control method and system for vehicle exterior whistling | |
EP3767621A1 (en) | Onboard device, traveling state estimation method, server device, information processing method, and traveling state estimation system | |
KR100899660B1 (en) | Apparatus and method for warning to driving concentration | |
CN115583218A (en) | Method and system for detecting vehicle theft event | |
CN116645979A (en) | Voice test method and device, electronic equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GUARDITY TECHNOLOGIES, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MCKOWN, RUSSELL CARL;MADER, JOSEPH THOMAS;MADER, THOMAS EDWARD;REEL/FRAME:037377/0141 Effective date: 20130531 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: WOLAVER, STEPHEN WAYNE, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: BYRD, STEPHANIE LYNNE, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MEEHLHAUSE, MARK GARY, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: RICHARDSON FAMILY LIVING TRUST, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MYERS, LEIGH ANN, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: WILKINSON, ROBERT TODD, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: ROBERTS, DAVID HEATH, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: JOHNSON, MARK G., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: HEWITT, AL EARNEST, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: DOUD, TIMOTHY, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: HENDRIX, JAMES SCOTT, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: YOUNG FAMILY LIVING TRUST, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MADER, THOMAS EDWARD, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: SEAR, TIMOTHY R.G., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: SEAGRAVE, TERRY DEAN, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: PAGE, MATTHEW D, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: LAFON, LAURI, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: LOMBARDI, JAMES A., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: CARR, ROBERT LAWRENCE, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: WAGERS, STEVEN MICHAEL, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MANON, LUIS G., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: HEWITT, MARY ANN, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: ADAMS FAMILY LIVING TRUST, THE, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: JENKINS, WARREN BLAKE, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: ZEMAITIS, STEVEN RICHARD, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MADER, JOSEPH THOMAS, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MCCULLOUGH, PATRICK D., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MCVEIGH, RAYMOND SCOTT, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: GILES, JEFFREY CRATON, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: MYERS, DAVID GLEN, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: CONRAD FAMILY TRUST, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 Owner name: KASMIERSKY, VALERIE KAY, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GUARDITY TECHNOLOGIES, INC.;REEL/FRAME:039271/0778 Effective date: 20160718 |