Resistive force sensor with capacitive discrimination

- Apple

A resistive force sensor with capacitive discrimination is disclosed. According to an example of the disclosure, a sensor is directed to detect resistance and capacitance in an alternating fashion, the resistance indicating a force being applied to an input area of a device, and the capacitance indicating a proximity of a body part to the input area of the device, and the detected resistance and capacitance are utilized to determine whether the body part has pressed the input area of the device.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
FIELD OF THE DISCLOSURE

The disclosure of the present application relates to input mechanisms, and more particularly, to sensing input through the use of force and proximity sensors.

BACKGROUND

Virtually every consumer product device on the market has some form of input mechanism that allows a user to interact with the device. One of the most common input mechanisms is the button, which when pressed by a user causes the device to change a state associated with the button. The button may take many forms, from a mechanical push button, such as a rubber knob commonly found on TV remote controls and calculators, to a virtual button, such as a graphical user interface input area displayed on a flat and/or rigid touch-sensitive surface commonly found on ATMs and some handheld computing devices.

Irrespective of the form, the button is usually associated with two states—“pressed” or “not pressed”. Pressing or selecting a button changes the “not pressed” state to “pressed”, causing the “pressed” state to be activated. Releasing the button changes the “pressed” state back to “not pressed”, causing the “pressed” state to be deactivated. In this sense, the button allows a user to define the state of input into the device.

For example, when a device is powered off and a user presses the power button, the button press activates the power button's “pressed” state, which triggers the device to power on. When the user releases the button, the button release deactivates the “pressed” state, usually to no effect. In a different example, when a user presses a horn on a car (which can be considered a large button), the horn press activates the horn's “pressed” state, triggering the car to sound the horn. When the user releases the horn, the horn release deactivates the “pressed” state, triggering the car to stop sounding the horn.

The mechanism behind the operation of many buttons is a force sensor. When a user presses a button, a force sensor detects the force being applied to the button from the user's finger, hand or other object. When the output of the sensor indicates that the force exceeds a threshold amount (e.g., a strong enough press of the user's finger to indicate the user is intending to press the button), the “pressed” state of the button is activated, triggering an action to be taken by the device due to the button being pressed.

Thus, in order for the button to work properly, it is important that the button's sensor output be interpreted correctly to indicate that the button has been pressed or released. An incorrect interpretation of the button's sensor output can result in a phantom button press or release, which can trigger an unintended action with potentially damaging consequences.

SUMMARY

In order to correctly interpret whether a user is pressing a button of a device, methods of the present disclosure can detect both the force applied to the button area as well as the proximity of a user's finger to the button area.

In this manner, proximity detection can be used to verify that a detected force is actually caused by an intended press of a button and not some other effect, such as temperature change or a stuck button, for example.

For instance, when in certain situations a temperature change causes a force sensor to indicate a force being applied to a button, the combination of proximity detection with force detection can prevent the temperature change from being confused for a user's button press if the proximity sensor indicates that no finger is in the button area.

Similarly, when in certain situations a stuck button causes a force sensor to indicate a force being applied to a button, the combination of proximity detection with force detection can prevent the stuck button from being confused for a user continuing to hold down a button if the proximity sensor indicates that the user's finger has left the button area.

In addition to resolving these signal conditioning issues, the present disclosure teaches that the same physical sensor can be utilized to switch back and forth between force detection and proximity detection, since the same sensor element can be directed to detect both resistance (to indicate applied force) and capacitance (to indicate proximity of a user's finger).

The use of a single sensor device to accomplish both force and proximity sensing can be advantageous from an implementation and a cost standpoint. From an implementation standpoint, it can be beneficial to have dual-sensing ability in one physical sensor because it ensures that the same input area can be detected for force and proximity. From a cost standpoint, it is less expensive to use one physical sensor for detecting both force and proximity, rather than two sensors whereby one is used for detecting only force and the other for detecting only proximity.

Further, the present disclosure teaches the ability of a device to programmatically change threshold amounts of the force and/or proximity output required in order to activate an input state of a button. For example, if the device can alter the level of force required to activate a button's “pressed” state, and/or the level of proximity of a finger to the button area to activate the button's “pressed” state, the effective size of the button area can be changed without changing the physical sensor associated with the button.

Such an ability could allow a user to resize a virtual button displayed on a device surface by merely adjusting the sensor threshold parameters via software control.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a graph of an example of idealized force sensor output and corresponding button input state.

FIG. 2 is a graph of an example of force sensor output with a drifting baseline and corresponding button input state.

FIG. 3 is a graph of an example of force sensor output subject to hysteresis and corresponding button input state.

FIG. 4 is a diagram of an example of switching sensor operation modes.

FIG. 5 is a flow chart of an example of an algorithm for activating a button input state.

FIG. 6 is a flow chart of an example of an algorithm utilizing proximity detection for deactivating a button input state.

FIG. 7 is a flow chart of an example of an algorithm utilizing force detection for deactivating a button input state.

FIG. 8 is a flow chart of an example of an algorithm that accounts for baseline drift and hysteresis.

FIG. 9 is a graph of an example of force sensor output and corresponding button input state that accounts for baseline drift and hysteresis.

FIG. 10 is a flow chart of an example of a button resizing and input state activation algorithm.

FIG. 11 is a diagram of an example of a housing.

FIG. 12 is a diagram of an example of a sensor configuration.

FIG. 13 is a diagram of another example of a sensor configuration.

FIGS. 14a and 14b are diagrams of examples of sensor contact configurations.

FIG. 15 is a diagram of an example of a device.

DETAILED DESCRIPTION

The present disclosure teaches the use of resistive force detection in combination with capacitive proximity detection in order to implement a button, for example. The resistive force detection and capacitive proximity detection may work through a rigid cover or housing, including glass, for example. The same physical sensor element may be used for both resistive force detection and capacitive proximity detection.

The resistive force sensor can be used to detect force applied by a user's finger to an input area of a device. To address situations in which the force sensor output changes due to unintended effects, such as, for example, temperature changes, a stuck button or even a user applying force to the device but not directly over the force sensor area, the capacitive proximity sensor can be used to detect the proximity of the user's finger to the input area in order to confirm the finger press.

Temperature change and sticking buttons relate to signal conditioning issues referred to as baseline drift and hysteresis, respectively. These issues make it difficult to properly interpret the sensor's output signal as clearly indicating either the “pressed” or “not pressed” state.

Baseline drift occurs when factors other than a user pressing a button, such as changes in temperature, cause the sensor to output a signal indicating that a user pressed the button. In this situation, the simple act of placing a cell phone or portable music player in the sun or near a hot appliance could cause the sensor's output to indicate that a button has been pressed.

Hysteresis occurs when a button “sticks”, or fails to return completely to its original position, after being pressed. In this situation, because the “stuck” button is still exerting a force on the sensor, the sensor output may incorrectly indicate that the user is continuing to press the button.

In an effort to better illustrate these issues, a basic description of the workings of a force sensor is warranted. In a basic sense, a force sensor usually works by detecting the resistance of a sensor element, and outputting a signal indicating the level of the detected resistance. A sensor element usually includes two contacts positioned closely together—but not touching—while at rest, as shown in FIGS. 14a and 14b for example. When a force is applied to the contacts, they are pushed closer together causing the contact resistance between them to be reduced. As a force being applied to the sensor element increases, the resistance between the contacts decreases.

Thus, when a force sensor detects a drop in resistance of the sensor element, the drop is interpreted as a force being applied to the sensor. The greater the drop in resistance, the greater the level of force interpreted as being applied to the sensor.

In order to detect a drop in resistance, a baseline resistance is usually established from which to measure any subsequent drop. The baseline resistance is the level of resistance detected in the sensor element when at rest—i.e., when no intended force is being applied to the sensor.

To illustrate these issues graphically, FIG. 1 shows an example of ideal force sensor output that is not affected by baseline drift or hysteresis as a user presses and releases a button.

Although a force sensor output indicates a level of resistance, force sensor output plot 100 plots the sensor output in terms of conductance over time for better presentation purposes. Conductance is the inverse of resistance (depicted as 1/R), and enables the resistance output to be plotted with an increasing, rather than a decreasing, slope in relation to an increasing force being applied to the sensor (and vice-versa).

In an ideal situation, plot 100 shows that the force sensor only provides an output above baseline 130 when the user is pressing the button beginning at point 140. When the user releases the user's finger from the button at point 160, the output returns to baseline 130. In such a situation, a simple threshold algorithm can be utilized to interpret the button press—when the output exceeds a threshold amount of resistance, the button is considered pressed; when the output falls below the threshold amount, the button is considered released.

As shown in plot 100, the “pressed” state of the button is activated at point 150, which is when the force of the finger press exceeds the threshold amount of resistance depicted by activation threshold 120. When the output falls below activation threshold 120 at point 170, the “pressed” state of the button is deactivated, indicating that the button has been released by the user. In a real application, the output is never this clean.

FIG. 2 shows an example of force sensor output that is affected by baseline drift. In this example the user does not press the button, so the sensor output should be considered at baseline at every point. In plot 200, other factors such as temperature change cause the output to drift, leading to drifting baseline 130.

Once the output (and hence drifting baseline 130) drifts from starting baseline 220 and exceeds activation threshold 120 at point 150, the “pressed” state of the button is activated. As shown in plot 210, the output is interpreted as if a user is continuing to press the button after point 150.

Thus, the simple threshold algorithm is impractical to implement in a baseline drift situation.

FIG. 3 shows an example of a force sensor output that is affected by hysteresis. In plot 300, the sensor output is correctly interpreted as the button being pressed when it exceeds activation point 150. However, when the user releases the button at point 160, the button becomes partially stuck and continues to exert a force on the sensor element, leading to a new baseline above activation threshold 120.

In this situation under the simple threshold algorithm, because the output did not fall back below activation threshold 120, the “pressed” state remains activated as illustrated in corresponding plot 310.

Thus, the simple threshold algorithm is also impractical to implement in a hysteresis situation.

Although some algorithms more complex than the simple threshold algorithm, such as a re-baseline algorithm and derivative algorithm, may attempt to interpret force sensor output properly for switch-like operation in light of baseline drift and hysteresis, each possesses drawbacks that hinder their ability to appropriately compensate for these signal conditioning issues.

The re-baseline algorithm adjusts the baseline (or “re-baselines”) to match the current output level at a specified time interval. Unfortunately, this algorithm depends on picking the correct time interval at which to re-baseline. If the algorithm re-baselines too quickly, it will miss button pushes because it will re-baseline to the force applied by the user's finger. If it re-baselines too slowly, it will allow accidental button pushes because it will not catch the baseline drift in time. In some cases, there is no appropriate “happy medium” interval.

The derivative algorithm relies on the derivative of the sensor output. In other words, it looks not at the change in output at discrete intervals in time (as in the re-baseline algorithm), but rather at how quickly the output changes over a short period of time. It therefore requires the user to press quickly on the button in order for the force to be interpreted as a button press. If the user presses slowly by holding a finger over the button and gradually applying force, the button push could be missed all together.

Accordingly, the use of resistive force detection in combination with capacitive proximity detection can overcome these signal conditioning issues when implementing a button, for example.

FIG. 4 shows an example of a controller that can switch the operation of a sensor between two distinct operation modes—a force detection mode for providing output responsive to a force applied by an object, and a proximity detection mode for providing output responsive to a proximity of the object.

In step 420, controller 400 can switch sensor 410 into force detection mode by directing sensor 410 to detect resistance between its sensor contacts. While in force detection mode in step 430, sensor 410 can output a signal indicating the level of detected resistance which may be interpreted by controller 400 as a level of force being applied to sensor 410. In step 440, controller 400 can switch sensor 410 into proximity detection mode by directing sensor 410 to detect capacitance of the sensor element instead of resistance. While in proximity detection mode in step 450, sensor 410 can output a signal indicating the level of detected capacitance which may be interpreted by controller 400 as a level of proximity of an object to sensor 410. As indicated by the bent arrows, switching between the two sensor operation modes may occur in an alternating fashion.

Controller 400 can switch back and forth between detection modes using, for example, a copper pattern shape as a force sensor element for part of the time and as a capacitive sensor element for part of the time. Controller 400 can be programmed or instructed to direct sensor 410 to alternate between resistive force detection and capacitive proximity detection every 25 milliseconds or less, for example, so that a time lag would not be evident to a user between pressing the button and the device identifying the press as a button press (i.e., activating the “pressed” state of the button).

In an another method of the present disclosure, at specified intervals controller 400 may receive only resistive force detection output from one sensor and only capacitive proximity detection output from a different sensor situated in close proximity to the first sensor.

FIG. 5 depicts an example of an algorithm for activating a button input state. In this example, at step 500 a processor (such as controller 400) may recurringly receive force and proximity output from one or more sensors corresponding to an input area of a housing. At step 510 the processor can determine whether the proximity output exceeds a threshold amount of proximity, and at step 520, whether the force output exceeds a threshold amount of force. If the processor determines that the threshold amounts of force and proximity have been exceeded, at step 530 the processor may activate a “pressed” input state indicating a button press on the input area of the housing.

FIG. 6 depicts an example of an algorithm utilizing proximity detection for deactivating a button input state. In this example, a processor can determine whether the proximity output exceeds a threshold amount of proximity at step 600, and whether the force output exceeds a threshold amount of force at step 610, in order to activate the “pressed” input state at step 620. Once the state has been activated, it may remain activated until the proximity output falls below the threshold amount of proximity at step 630, at which time the processor can deactivate the “pressed” state at step 640, indicating user release of the button. This can be advantageous in situations in which a user removes a finger from the input area but the button continues to apply a force due to sticking, for example.

FIG. 7 depicts an example of an algorithm utilizing force detection for deactivating a button input state. In this example, a processor can determine whether the proximity output exceeds a threshold amount of proximity at step 700, and whether the force output exceeds a threshold amount of force at step 710, in order to activate the “pressed” input state at step 720. Once the state has been activated, it may remain activated until the force output falls below the threshold amount of force at step 730, at which time the processor can deactivate the “pressed” state at step 740. This can be advantageous in situations in which it is less likely that a button will stick, and more likely that a user would intend to release a button by lightening up on the force applied to the button without moving away from the button, for example.

FIG. 8, in combination with plot 900 of FIG. 9, depicts an example of an algorithm that accounts for baseline drift and hysteresis. In this example, a processor can continually or intermittently adjust force output baseline 920 to match detected force output levels when a user's body part, such as a finger, is not near the sensor area.

At step 800 the processor can determine if the proximity output exceeds a threshold amount of proximity, indicating proximity of a finger to the sensor area. When the threshold amount of proximity is exceeded at point 940, the processor can disable the adjusting baseline functionality by switching to static baseline 930 mode at step 810. At this point, the processor can continue to determine, without adjusting for baseline drift, whether the proximity and force output exceed the threshold amounts of proximity and force, respectively, at steps 820 and 830, in order to activate the “pressed” button state at step 840.

If the proximity output falls below the threshold amount of proximity (e.g., indicating the finger moved away) at step 820, which occurs prior to the “pressed” state being activated, the processor can simply switch back to adjusting baseline 920 mode at step 870. If the proximity output falls below the threshold amount of proximity at step 850 and points 160 and 950, which occur after the “pressed” state has been activated, the processor can deactivate the “pressed” state at step 860 and switch back to adjusting baseline 920 mode at step 870. As plot 910 illustrates, the button state is correctly activated and deactivated in light of the baseline drift and hysteresis factors.

Of course, in step 850 force output could be utilized instead of proximity output to determine whether to deactivate the switch, similar to step 730, or a combination of both a force output and proximity output may be utilized, for example.

FIG. 10 depicts an example of a button resizing and input state activation algorithm. In this example, as above, a processor can receive force and proximity sensor output at step 1020 to determine whether the threshold amounts have been exceeded at steps 1030 and 1040 for activating the “pressed” button state at step 1050. However, in this example, the processor may also receive at step 1000 a request to resize the button input area to be pressed by a user in order to activate the “pressed” button state.

This request could be generated by a user via a user interface associated with the device. Upon receiving the request, at step 1010 the processor may adjust the force and/or proximity thresholds accordingly in order to change the physical detection coverage for a virtual button displayed on an input area of the device.

FIG. 11 depicts an example of a housing. In this example, the housing may comprise a device including touch screen display area 1100, cover 1110 fabricated from a rigid material such as glass, for example, and input area 1120 where a user may press in order to activate a “pressed” state of a virtual button. Examples of the housing may include portable music players, mobile communications devices and other handheld computing devices.

FIG. 12 depicts an example of a sensor configuration. In this example, a hybrid force/proximity sensor may include deformable material 1210, such as, for example, rubber that is doped with carbon to make the rubber slightly conductive (although somewhat less conductive than a piece of metal is an embodiment). Pattern 1230 on printed circuit board (“PCB”) 1220 may be disposed underneath rubber element 1210. FIGS. 14a and 14b depicts exemplary pattern configurations.

If rubber 1210 is compressed onto PCB 1220 pattern 1230, then the contact resistance between the two halves of the pattern can be reduced. The change in resistance caused by this force may be measured by, for example, a processor. Adhesive 1240 may be included to allow doped rubber 1210 to actually push harder on PCB 1220 pattern 1230, with adhesive 1240 compressing slightly when the user pushes their finger directly on the input area 1120 of the cover 1110.

Cover 1110 may be adhered to frame 1200, which has a small hole. PCB 1220 may be stuck to the bottom of frame 1200 and have pattern 1230 on it.

FIG. 13 depicts an example of a sensor configuration without the hole in the frame. This example is similar to that of FIG. 12, except instead of having a hole drilled all the way through frame 1200, a small indentation may be carved out of frame 1200 in which the circuit 1300 (which may be flexible) and deformable material 1210 may be inserted. Conductive paint 1310 may be applied between cover 1110 and circuit 1300.

FIG. 15 depicts an example of a device. In this example, the device may include processor 1500, memory 1510, controller 400 and sensor 410.

Controller 400 may provide the necessary drive and detection circuitry to obtain force and proximity output from sensor 410. Controller 400 can process the received force and proximity output to determine whether input area 1120 was pressed or released by a user with the intent to activate or deactivate the “pressed” state of a button. In order to activate or deactivate the “pressed” state, controller 400 can send a signal indicating such activation or deactivation to processor 1500 (e.g., a central processor responsible for running the device), which may trigger the appropriate programming functionality to react to the indicated button press or release.

Memory 1510 may include, for example, one or more of the following types of storage media: magnetic disks; optical media; and semiconductor memory devices such as static and dynamic random access memory (RAM), Electrically Programmable Read-Only Memory (“EPROM”), Electrically Erasable Programmable Read-Only Memory (“EEPROM”), Programmable Gate Arrays and flash devices.

The processing functionality described herein may be performed by a processor located on the sensor board itself, controller 400 or the central processor responsible for running the device, for example.

Although the claimed subject matter has been fully described in connection with examples thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the present disclosure as defined by the appended claims.

Claims

1. A method, comprising:

switching operation of a sensor between a first operation mode and a second operation mode, wherein
when operating in the first operation mode, the sensor provides a first output responsive to a force applied by an object, and
when operating in the second operation mode, the sensor provides a second output responsive to a proximity of the object.

2-31. (canceled)

Patent History
Publication number: 20090020343
Type: Application
Filed: Aug 6, 2007
Publication Date: Jan 22, 2009
Applicant: Apple Inc. (Cupertino, CA)
Inventors: Fletcher R. Rothkopf (Mountain View, CA), Stephen Zadesky (Cupertino, CA)
Application Number: 11/882,881
Classifications
Current U.S. Class: Resistive (178/18.05)
International Classification: G06F 3/045 (20060101);