Patent Application
20080147268
The invention relates generally to the field of electronic automobile control and more specifically to the field of performing automobile features with electronic devices.
Vehicle manufacturers build increasingly more features into today's automobiles. Among those features is remote keyless entry, whereby a key fob signals a receiver in the car to unlock one or more doors. Typically, key fobs include additional automobile features, such as rolling windows up or down, unlocking or opening the trunk, or initiating a panic alarm. There are a wide variety of possible automobile features that a key fob may perform. For example, some key fobs have even been designed to start the automobile.
Key fob capability may either come installed with the automobile at the time of manufacture or installed at a later time. Today, many automobiles are sold with key fob capability already installed in the automobile. Automobile users may even purchase additional key fobs for their vehicle at a later date.
Key fobs are typically designed to be carried on a key chain along with the keys to the automobile. Since the key fob is usually attached to the keys, key fobs usually do not assist in the ever so common problem of locking the keys in the automobile. While automobile users may have an extra key fob or extra set of keys, they do not usually carry both sets with them. Typically, the extra set is kept at home or given to another person. Therefore, the automobile user would be required to locate and retrieve the extra set before it could be of any assistance. This may be inconvenient depending on, for example, the time of day, location of the automobile, or accessibility of the person with the extra set.
Another common problem arises when an automobile user wishes to perform an automobile feature on his automobile but does not have the keys or key fob with him. Many times users may accidentally leave their keys behind, or even intentionally leave their keys behind if they are not planning on using their automobile. The user, for example, may have left his keys in the house or office, but wish to enter his automobile or roll down the windows while in the parking lot or garage. In order to do so, the user would be required to first walk back to the house or office. This may be inconvenient depending on the distance or time required to do so.
What is needed is a device that allows an automobile user to use other devices, besides the key fob, to perform automobile features.
The present invention includes a system and method for performing an automobile feature. Upon communicating with a user device and receiving an indication of an event initiated from the communication, an automobile feature associated with the event is determined and an automobile module is directed to perform the automobile feature.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
a illustrates components of a Bluetooth module within a described device according to one embodiment of the invention;
b illustrates components of a RF module within a described device according to one embodiment of the invention;
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice the present invention. In other instances, well known materials or methods have not been described in detail in order to avoid unnecessarily obscuring the present invention.
Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Moreover, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated, and except as will be readily apparent to those skilled in the art. Thus, the invention can include any variety of combinations and/or integrations of the embodiments described herein.
A method and apparatus for executing a feature on an automobile are described. In one embodiment, a device coupled to the automobile is described which allows a user to execute features on an automobile by using a user device.
Device 100 allows a user to perform automobile features on an automobile with a user device 101. During operation, device 100 is coupled to the automobile and is capable of communicating with a user device 101 operated by a user wishing to perform an automobile feature. Device 100 is also capable of communicating with an automobile module 102 within the automobile that executes the automobile features for the automobile.
User device interface module 110 communicates with a user device 101 via wire-line or wireless technology, e.g. RF, visible light, invisible light, or sonic. For instance, the two devices may communicate via a connection in accordance with IEEE 802 standards. Wireless technologies may involve, for example, IEEE 802.11 Wireless LAN (Local Area Network) standards like 802.11a (operating in the 5 GHz band), 802.11b and 802.11g (operating in the 2.4 GHz band), IEEE 802.15 Wireless PAN (Personal Area Network) standard, Bluetooth which operates in the unlicensed industrial, scientific, and medical (ISM) band at 2.4 to 2.485 GHz, or infrared technology like infrared data association (IRDA). In one embodiment, user device 101 communicates with device 100 via a Bluetooth connection. In another embodiment, user device 101 communicates with device 100 via infrared connection. User device 101 may be any electronic device that may communicate with device 100, e.g. cell phone, Personal Digital Assistant (PDA), handheld electronic device, laptop, computer, etc.
Automobile interface module 120 may communicate with automobile module 102 via wire-line or wireless technology. Automobile module 102 may comprise a RF key fob receiving circuitry that is designed to receive RF signals from a RF key fob. The RF key fob receiving circuitry may be installed in the automobile upon manufacture or as an aftermarket installation. In one embodiment of the invention, the automobile interface module 120 transmits RF signals that emulate the RF signals from a RF key fob. These RF signals are subsequently received by the RF key fob receiving circuitry in the automobile module 102 which executes the appropriate automobile feature. In another embodiment, automobile interface module 120 and automobile module 102 interface through a diagnostic port of an automobile, wherein the automobile module 102 may comprise part of the automobile's electrical and computer system.
It should be appreciated that individual modules may be combined without compromising functionality, e.g. the microcontroller 130 and user device interface module 110 may be combined into a single module. Thus, the underlying principles of the invention are not limited to the specific modules shown.
At step 210, device 100 is initialized upon the supply of power, e.g. when the user turns on the device or plugs it into the automobile. During initialization, basic operation parameters of the microcontroller are configured. The microcontroller's random access memory (RAM) is initialized with the starting contents loaded from the ROM or other non-volatile solid-state memory. In one embodiment, the contents are loaded from a programmable space of the memory, which can be reprogrammed after the time of manufacture of device 100 and take into account user configurations of the device.
A cyclic-redundancy-check (CRC) may be performed to ensure that no errors occurred during the loading of the data into the RAM. If the CRC process fails, the microcontroller 130 may attempt to load the data from the memory into the RAM a few times, prior to reprogramming the memory with the default parameters stored in the microcontroller 130.
A sleep timeout counter may be used and set to a default value during the microcontroller initialization process. The sleep counter may be located in RAM and may be used to determine when the device should enter a low power mode. The counter periodically decrements until it reaches zero and then device 100 enters low power mode. The counter may, for example, be decremented every time the software goes through a whole processing loop. When the counter counts down to zero, the device goes to sleep. Once activity is detected, the counter is set to a default value again.
At step 220, user device interface module 110 and the user device 101 begin communication with each other. A user, for example, wishing to perform an automobile feature using a user device 101, e.g. his cell phone, may initiate communication with the user device interface module 110. User device 101 may, for example, be a Bluetooth-enabled device which scans for nearby Bluetooth devices, detects device 100 as such a device, and then begins communication with it. As another example, user device 101 may be an infrared enabled device which scans for nearby infrared devices, detects device 100 as such a device, and then begins communication with it. User device 101 may also be an 802 enabled device which scans for nearby 802 devices. It should be appreciated that the underlying principles of the invention are not limited to these specific wireless technologies and that a number of varying wireless and wire-line technologies may be used, as discussed earlier.
At step 230, microcontroller 130 waits for an indication of an event to occur before sending a command signal to perform an automobile feature associated with that event. The indication of the event is initiated from communication with the user device 101. In one embodiment, the event is a successful pairing of device 100 and the user device 101. A successful pairing may, for instance, comprise the user device 101 and device 100 successfully exchanging a security code or identification information. The user of the user device 101, for example, may attempt to pair with device 100 by entering an appropriate PIN or password. If the PIN/password is an acceptable code, then there is a successful pairing between the user device 101 and device 100. The successful pairing may, for example, occur via a Bluetooth, IEEE 802, or infrared communication. In another embodiment, an event is a downloading of a feature file from device 100 by the user device 101 (discussed in further detail later). However, it should be appreciated that the underlying principles of the invention are not limited to these specific exemplary definitions of an event.
At step 240, the microcontroller 130 determines which automobile feature is associated with the event that has occurred. For instance, microcontroller 130 may be preprogrammed to determine that the automobile feature of unlocking the doors is associated with a successful pairing of user device 101 and user device interface module 110. As another example, microcontroller 130 may be preprogrammed to determine that the automobile feature of rolling down the windows is associated with the download of a feature file titled “Roll Down Windows”. However, it should be appreciated that the underlying principles of the invention are not limited to these specific exemplary associations described. Furthermore, the microcontroller 130 may be preprogrammed to recognize a single event or multiple events, which may be associated with a single automobile feature or multiple automobile features. Therefore, the underlying principles of the invention are also not limited to any specific number of preprogrammed automobile features or events.
At step 250, the microcontroller 130 sends a command signal to the automobile interface module 120 to direct the automobile module 102 to perform the determined automobile feature from step 240. The command signal may be sent to the automobile interface module 120 via one or more command lines 160. In one embodiment, upon receiving the command signal, the automobile interface module 120 transmits a RF signal that emulates the corresponding command signal from a RF key fob. The RF signal is received by automobile module 102 via its RF key fob receiving circuitry. In one embodiment, the command lines 160 may comprise a command line for each automobile feature possible from a RF key fob. The microcontroller 130 may then send a signal down the appropriate command line for the determined automobile feature from step 240. In another embodiment, a data communication channel is integrated into the automobile interface module 120 so at reduce the number of wiring interconnects and increase the flexibility in function selection. However, the underlying principles of the invention are not limited to a particular communication design between the microcontroller 130 and the automobile interface module 120.
Microcontroller 130 interfaces to Bluetooth module 310 and RF module 320 via data lines 150 and command lines 160, respectively. The Bluetooth module 310 may communicate with a Bluetooth-enabled user device in proximity via Bluetooth wireless technology and is described in further detail in
In one embodiment, the microcontroller 130 interfaces to the Bluetooth module 310 through a universal asynchronous receiver/transmitter (UART) channel. The data lines 150, for example, may comprise a transmit (TX), receive (RX), and two flow control lines (RTS & CTS). The TX and RX of one device connect to the RX and TX of the other device, respectively. Likewise, the CTS and RTS of one device connect to the RTS and CTS of the other device, respectively. In this way, microcontroller 130 and Bluetooth module 310 may send data to each other and also indicate when it is too busy to receive data. In another embodiment, data lines 150 also comprise an additional interrupt line so that microcontroller 130 can be notified anytime Bluetooth module 310 needs attention and subsequently begin communication with it. In this way, the microcontroller may sleep and save power whenever the Bluetooth module 310 is waiting for user interaction. In yet another embodiment, data lines 150 comprise data lines for a USB or other common interface. However, it should be appreciated that the underlying principles of the invention are not limited to a particular type of communication interface.
a illustrates components of Bluetooth module 310 according to one embodiment of the invention. Bluetooth chip 401 is shown coupled to an oscillator 402 and external ROM 403 which contains the Bluetooth software that runs on Bluetooth chip 401. While an external ROM is shown for this exemplary embodiment, it should be appreciated that the underlying principles of the invention are not limited to an external ROM. For instance, flash memory may be used or the Bluetooth chip may include built-in ROMs or flash memory. The Bluetooth chip 401 may comprise all the necessary digital (microcontroller) and analog (radio) circuitry to operate as a completed Bluetooth device. The Bluetooth chip 401 may generate a balanced RF signal that is fed into an external balun transformer 404 which converts the signal to a single line that can be fed into an antenna 406. A bandpass filter is used to block unwanted frequencies from interfering with the Bluetooth communications. Furthermore, Bluetooth chip 401 communicates with microcontroller 130 via data lines 150.
b illustrates components of RF module 320 according to one embodiment of the invention. RF chip 411 may use a standard rolling code or other security technology to provide a secure link to the vehicle. The output of RF chip 411 drives antenna 417 which transmits the appropriate RF signal to automobile module 102 (not shown). Microcontroller 130 (not shown) is coupled to RF chip and may directly drive the automobile feature inputs 413 via command lines 160. In the exemplary embodiment shown, automobile feature inputs 413 comprise door lock 414, door unlock 415, and trunk release 416. In one embodiment, a command line may be present for each automobile feature possible where microcontroller 130 would provide the corresponding signal.
Device 100 comprises microcontroller 130 which couples to the diagnostic port 601 of the automobile through an I/O cell 602 and connector 603, all of which are mounted on a printed circuit board (PCB, not shown). The microcontroller 130 is coupled to a memory 604 where initialization and configuration data is stored to be used by the microcontroller 130.
In one embodiment, the microcontroller 130 has a built-in Erasable Programmable Read Only Memory (EPROM) for storing program instructions, which implement a protocol for a particular automobile, for example, a Chevrolet Corvette. An oscillator 605 couples to the microcontroller 130 and provides a clock signal of a frequency selected to operate with the microcontroller 130.
In one embodiment, the 10 cell 602 interfaces the microcontroller 130 to the automobile diagnostic port's bus in accordance with electrical requirements described in a corresponding specification published by the Society of Automotive Engineering. In one embodiment, the diagnostic port's bus is an OBD-II bus, electrical requirements of which are described in the SAE-J1850 specification titled “Class B Network Communications Interface.” In summary, the microcontroller's voltage levels, thresholds, and edge rates may be different and may need to be adjusted for compatibility with the automobile's bus. The IO cell 602 may interface with the microcontroller 130 through two digital signals: one input and one output. The automobile side, i.e. diagnostic port's electrical connection, is a single bi-directional line that meets the electrical requirements of the diagnostic port's bus. In one embodiment of the invention, the 10 cell 602 drives the OBD-II bus at voltages being 8V high, and 0V low when commanded by the microcontroller's digital output signal. The IO cell 602 may read the diagnostic port's bus and send a 5V high or 0V low digital signal. In one embodiment, the microcontroller 130 can read the input signal even when driving the output signal. This may allow the microcontroller to detect bus contention to support the bit-by-bit arbitration requirements of the OBD-II spec.
Furthermore, it should be noted that the automobile interface module 102 is functionally shown in
Additionally, it should be appreciated that in
At step 710, device 100 enables file system and runs file server so that the user device 101 may access feature files stored within device 100. At step 720, device 100 provides user device 101 with a directory or file list. This list may contain feature files which represent specific automobile features, e.g. unlocking the doors, opening the trunk, rolling down the windows, etc. At step 730, device 100 waits for a file transfer protocol interaction to be initiated. If the user, for instance, wishes to unlock the doors, the user may select the appropriate feature file on the user device 101 for download. The appropriate feature file may be nothing more than a text file named “unlock doors” which tells the user that the download has started and the doors are being unlocked. If the download of a feature file is established to be an event signaling the execution of an automobile feature, then the microcontroller 130 will determine what automobile feature is associated with the particular feature file downloaded, as represented at step 750. At step 760, microcontroller 130 sends the appropriate command signal to the automobile interface module 120 which sends a signal to the automobile module 102 to perform the determined automobile feature.
At step 730, device 100 may also receive a configuration file from the user device 101. The user, for instance, could use user device 101 to create a configuration file and send it to device 100 in order to set certain configuration parameters. A wide array of configuration parameters may be applicable. For example, PIN codes and passwords could be defined by the user; directories, menus and feature files may be named or renamed by the user; and/or authorized user device lists may be defined by the user to allow only certain user devices access. However, the underlying principles of the invention are not limited to these particular set of exemplary configuration parameters. After receiving the uploaded configuration command, microcontroller 130 makes the appropriate configuration changes at step 740 and proceeds to wait for another file transfer protocol interaction.
When device 100 comprises RF module 320, after initial installation it may be required to program the automobile to recognize device 100. Some automobiles today allow new fobs to be added to an existing list of valid fobs, while other automobiles may completely erase the list and require all valid fobs to be reconfigured again whenever a new fob is added. In one embodiment, device 100 comprises a configuration button which, when activated, allows the user to program the target automobile so that it recognizes device 100. The target automobile may be required to be in a “special mode” during such configuration, e.g. requiring the ignition key to be inserted into the automobile. The configuration button may serve a dual purpose: configuring device 100 to operate with the target automobile, and allowing the user to test the RF module 320 to make sure it is working properly with the target automobile. In another embodiment, a Bluetooth-enabled user device 101 instructs device 100 to enter a fob learning mode so that device 100 can be configured to operate with the target automobile.
During normal operation, device 100 is coupled to the automobile. For example, the device may be installed on or inside the automobile, or it may be removable and plugged into the vehicle during normal operation. In one embodiment, device 100 is connected into a diagnostic port in the automobile. Device 100 may be communicating with the automobile module through the diagnostic port and/or using the diagnostic port to power itself. In another embodiment, device 100 may be located inside the device described in U.S. Pat. No. 6,795,760, which is incorporated herein by reference. In yet another embodiment, device 100 is connected to the automobile's electrical and computer system. In yet another embodiment, device 100 wired as part of the automobile's car alarm system. In yet another embodiment, device 100 comprises a solar cell and battery and is located on or inside the automobile so that it may be exposed to sunlight. The use of a solar cell and battery for power purposes is well known in the art and are therefore not described in further detail.
It will be appreciated that the above-described system may be implemented in hardware or software, or by a combination of hardware and software. In one embodiment, the above-described system may be provided in a machine-readable medium. The machine-readable medium may include any mechanism that provides information in a form readable by a machine, e.g. a computer. For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM), magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
