Impact detection for data storage device

Detecting an impact of an electronic device, such as a data storage device (DSD). An acceleration input is received indicating an acceleration of the electronic device and it is determined whether an acceleration change value based on the acceleration input is greater than an absolute threshold. If so, an acceleration change ratio is calculated using the acceleration change value and an average of acceleration change values. The acceleration change ratio is compared to a relative threshold and it is determined that an impact of the electronic device has been detected if the acceleration change ratio is greater than the relative threshold.

BACKGROUND

Data storage devices (DSDs) are often used by electronic devices to record data onto or to reproduce data from a recording media. As electronic devices become increasingly mobile, the risk of mechanical shock to a DSD increases from events such as when the electronic device is dropped. In order to prevent damage to the DSD, some DSDs may take precautionary measures before impact if it is sensed that the electronic device or DSD is falling. In the example of a DSD including a rotating magnetic disk as a recording media, a magnetic head may be moved away from the disk during a fall to prevent contact between the head and the disk at impact after the fall. Such contact between the head and the disk may result in damage to the disk and loss of data stored on the disk.

The increasing mobility and increasing physical movement of electronic devices such as tablet computers have also made it more difficult to accurately determine when a DSD is in a falling state as opposed to some other type of motion which might provide a false indication of falling. A false indication of falling may, for example, result from walking or running with the electronic device or may result from movement of the electronic device as part of a particular application such as a gaming application. False indications of falling can degrade performance of the electronic device due to unnecessary preventative measures taken by the DSD such as moving a head away from a disk during a false fall. On the other hand, the failure to take precautionary measures during an actual fall can result in severely damaging the DSD and/or losing data.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth to provide a full understanding of the present disclosure. It will be apparent, however, to one of ordinary skill in the art that the various embodiments disclosed may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail to avoid unnecessarily obscuring the various embodiments.

FIG. 1illustrates a block diagram of electronic device110including data storage device (DSD)100in communication with host101according to one example embodiment. Electronic device110can be a computer system (e.g., desktop, mobile/laptop, tablet, smartphone, etc.) or other electronic device such as a digital video recorder (DVR). Those of ordinary skill in the art will appreciate that electronic device110and DSD100can include more or less than those elements shown inFIG. 1.

In one embodiment, DSD100includes controller122which can perform an impact detection process as described herein. Controller122can be implemented using one or more processors for executing instructions and can include a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), hard-wired logic, analog circuitry and/or a combination thereof.

In the example ofFIG. 1, DSD100includes rotating magnetic disk102and head129connected to the distal end of actuator130which is rotated by voice coil motor (VCM)132to position head129over disk102. Head129includes at least a read element (not shown) for reading data from disk102, and a write element (not shown) for writing data on disk102.

Disk102comprises a number of radial spaced, concentric tracks for storing data and can form part of a disk pack (not shown) which can include additional disks below disk102.

With reference toFIG. 1, DSD100may also optionally include solid-state non-volatile memory (NVM)128for storing data, for example, for use as a cache or as part of a solid state hybrid drive (SSHD) implementation of DSD100. NVM128stores firmware10which can include computer-readable instructions used by DSD100to implement the impact detection process described below.

While the description herein refers to solid-state NVM generally, it is understood that solid-state memory may comprise one or more of various types of memory devices such as flash integrated circuits, Chalcogenide RAM (C-RAM), Phase Change Memory (PC-RAM or PRAM), Programmable Metallization Cell RAM (PMC-RAM or PMCm), Ovonic Unified Memory (OUM), Resistance RAM (RRAM), NAND memory (e.g., single-level cell (SLC) memory, multi-level cell (MLC) memory, or any combination thereof), NOR memory, EEPROM, Ferroelectric Memory (FeRAM), Magnetoresistive RAM (MRAM), other discrete NVM (non-volatile memory) chips, or any combination thereof.

Volatile memory124can include, for example, a DRAM. Data stored in volatile memory124can include data read from disk102, data to be written to disk102, and/or instructions for DSD100, such as instructions loaded into volatile memory124from firmware10.

Host interface126is configured to interface DSD100with host101and may interface according to a standard such as, for example, PCI express (PCIe), serial advanced technology attachment (SATA), or serial attached SCSI (SAS). As will be appreciated by those of ordinary skill in the art, interface126can be included as part of controller122. AlthoughFIG. 1depicts the co-location of host101and DSD100, in other embodiments the two need not be physically co-located. In such embodiments, DSD100may be located remotely from host101and connected to host101via a network interface. In other embodiments, DSD100may serve as a stand-alone DSD without host101or may be temporarily disconnected from host101.

DSD100also includes spindle motor (SM)138for rotating disk102when writing data to disk102or reading data from disk102. SM138and VCM132are connected to controller122which includes control circuitry such as a servo controller to control SM138and VCM132with VCM control signal30and SM control signal34, respectively. These control signals can be, for example, control currents for controlling the rotation of VCM132and SM138.

Sensor134is configured to detect acceleration of DSD100and can include, for example, an XYZ sensor with three degrees of freedom. In other embodiments, sensor134can include a sensor with six degrees of freedom such as an XYZ-YPR sensor. The detected acceleration can be input to controller122to determine when DSD100is in a falling state. For example, sensor134may detect that DSD100is in a free-fall state or that DSD100is in a tipping-drop state where DSD100rotates about an axis while at least a portion of DSD100drops. Controller122may then implement protective measures to prevent damage to DSD100before impact. In particular, controller122can control VCM132via VCM control signal30to move head129away from disk102in an attempt to avoid contact between head129and disk102during an impact. Contact between head129and disk102can result in damage to disk102and loss of data stored on disk102.

In other embodiments, sensor134may be part of host101in electronic device110. In such embodiments, the input of sensor134may be received by controller122via host interface126.

As noted above, a false indication of falling can degrade performance of an electronic device such as electronic device110due to unnecessary precautionary measures taken by DSD100such as moving head129away from disk102during a false fall. The impact detection process disclosed below therefore ordinarily provides a way to distinguish between actual falls and false indications of falling.

FIG. 2is a graph depicting an acceleration input to controller122from sensor134indicating an acceleration of DSD100during a false fall according to one embodiment. In the example ofFIG. 2, the acceleration input represents a count output by sensor134corresponding to an acceleration detected in one dimension (e.g., in an x, y or z dimension). As shown inFIG. 2, the region circled as a “false fall” might indicate a fall using conventional algorithms of fall detection given the changes or differences in acceleration depicted in this region.FIG. 2also shows that the time before the false fall region as well as the time after the false fall region show similar changes or differences in acceleration of DSD100. These similar changes in acceleration surrounding the false fall region can generally be used to better differentiate between false falls and actual falls. More specifically, the adjacent changes in acceleration can indicate a period of vibration of DSD100resulting from a particular condition of electronic device110(e.g., motion due to walking or running of a user) or from a particular application executed by electronic device110(e.g., haptic feedback or motion sensitive gaming).

The graph ofFIG. 3depicts acceleration of DSD100during an actual fall according to an embodiment. As shown inFIG. 3, there is a significant change in acceleration for the region indicated as an “actual fall” which results from a dropping of electronic device110and a subsequent mechanical shock experienced by DSD100after impact.

In comparison to the false fall ofFIG. 2, the actual fall ofFIG. 3does not include as many large changes in acceleration adjacent to the actual fall region. The following impact detection process ofFIG. 4takes advantage of this difference in acceleration changes to identify false falls for adjusting a fall detection sensitivity of DSD100.

FIG. 4is a flowchart for an impact detection process which can be performed by controller122of DSD100according to one embodiment. In block300, the impact detection process begins. In one embodiment, this may occur whenever head129is positioned over disk102.

In block302, controller122receives an acceleration input from sensor134for a specific time or specific period of time (i.e., a current acceleration input). In an implementation where sensor134is an XYZ sensor, the acceleration input can include three values indicating an acceleration in each of three different dimensions. Such an example is shown in the embodiments ofFIGS. 5 and 8, where the bold line indicates an acceleration in an x dimension, the other solid line indicates an acceleration in a y dimension, and the dotted line indicates an acceleration in a z dimension. As withFIGS. 2 and 3, the accelerations depicted inFIGS. 5 and 8can represent the acceleration input which can be a count output by sensor134.

Returning toFIG. 4, controller122also calculates an acceleration change value and updates an average of acceleration change values in block302based on the acceleration input. In an implementation where sensor134is an XYZ sensor, the acceleration change value can be represented as a “jerk vector” or change in acceleration in x, y and z dimensions. The jerk vector can be expressed as shown below:
Δa=(x1−x0,y1−y0,z1−z0)  Eq. 1
where x1, y1and z1represent accelerations in each of three dimensions for the current acceleration input and x0, y0and z0represent accelerations at a previous time which can be based on a previous acceleration input. The previous acceleration input may be stored, for example, in volatile memory124of DSD100. In one implementation, the difference between the time for the current acceleration input and the previous acceleration input can be 1 ms.

In a different implementation, the acceleration change value can be calculated as the L1 norm of the jerk vector. Using the example of Equation 1 above for the jerk vector, the L1 norm can be expressed as shown below in Equation 2.
L1 norm=Σaxes|Δa|Eq. 2

In yet other implementations, the acceleration change value can be calculated as the L2 norm or the root-mean square of the jerk vector.

Controller122updates the average of acceleration change values in block302using the acceleration change value. For example, when the acceleration change value is calculated as an L1 norm of the jerk vector, the average of acceleration change values can be based on an average L1 norm of the jerk vector over a period of time such as 100 ms. This average of acceleration change values can be expressed as shown below.
Average of Acceleration Change Values=Σaxes|Δa|Eq. 3
The average of acceleration change values may be approximated using a 1st order infinite impulse response (IIR) low pass filter in one implementation to weight more recent acceleration change values more heavily in calculating the average. Weighting more recent acceleration change values more heavily can allow for a more accurate determination of a false fall since more recent changes in acceleration can better indicate whether a current change in acceleration is a continuation of a false fall motion such as vibration.

In block304, controller122determines whether the current acceleration change value for DSD100is greater than an absolute threshold. In the example above where the acceleration change value is the jerk vector, the absolute threshold may be a change in acceleration set for each of the dimensions detected by sensor134. For example, in an implementation where sensor134is an XYZ sensor, the absolute threshold may be a fraction of the gravitational acceleration constant G in each of the three dimensions detected by sensor134.

If using the L1 norm as the acceleration change value, the absolute threshold can be the L1 norm of thresholds in each of the dimensions detected by sensor134. The absolute threshold may then be calculated to correspond to specific design criteria, for example, based on a fraction of the gravitational constant.

FIG. 6depicts acceleration change values (ΔAcceleration) and an average of acceleration change values corresponding to the false fall ofFIG. 5according to an embodiment.FIG. 9depicts acceleration change values and an average of acceleration change values corresponding to the actual fall ofFIG. 8according to an embodiment. The absolute threshold in each ofFIGS. 6 and 9has been set to 0.6×104as indicated by the horizontal bold dashed line. As shown inFIG. 6, there are several instances spread out over the time period where the change in acceleration is greater than the absolute threshold. In the example ofFIG. 9, there are also instances where the change in acceleration is greater than the absolute threshold but these instances are closer together which can be more indicative of an actual fall.

Returning toFIG. 4, if it is determined in block304, that the acceleration change value is not greater than the absolute threshold, the process returns to block302to receive another current acceleration input and update the average of acceleration change values.

On the other hand, if it is determined that the acceleration change value is greater than the absolute threshold, controller122in block306calculates a ratio of the acceleration change value to the average of acceleration change values updated in block302. Using Equations 2 and 3 above as an example, this ratio can be expressed as shown in Equation 4 below.
Ratio=Σaxes|Δa|/Σaxes|Δa|Eq. 4
In one implementation, the division in the ratio of Equation 4 may be implemented using a count leading zeros (CLZ) operation. In the example of Equation 4, the ratio is dimensionless and is independent of sampling rates for sensor134.

The ratio calculated in block306is compared to a relative threshold in block308to determine whether the change in acceleration is due to an actual fall or a false fall.

FIG. 7depicts an example acceleration change ratio during the false fall ofFIGS. 5 and 6according to an embodiment. In this example, the relative threshold has been set to 20 as indicated by the dashed line inFIG. 7. The ratio during the time period from 1,000 ms to 2,000 ms shown inFIG. 7does not reach the relative threshold even though there are large changes in acceleration shown inFIG. 5and the acceleration change values inFIG. 6are greater than the absolute threshold at several times during the same period. This is due to considering the average of acceleration change values and can ordinarily result in differentiation between actual falls and false falls.

In contrast to the graph ofFIG. 7, the graph ofFIG. 10depicts an example acceleration change ratio during the actual fall ofFIGS. 8 and 9. As shown in FIG.10, the ratio spikes over the threshold of 20 at slightly after 1,600 ms. This increase in the ratio over the relative threshold indicates an actual fall. As shown inFIG. 9, the changes in acceleration before and after this time (e.g., at 1,400 ms and at 1,800 ms) are generally not as extreme as the changes in acceleration shown throughout the false fall acceleration changes ofFIG. 6.

Returning toFIG. 4, controller122increments a false fall count in block310if the ratio is not greater than the relative threshold in block308(as in the example ofFIG. 7) and the impact detection process returns to block302to receive another current acceleration input from sensor134.

The false fall count may be stored, for example, in volatile memory124. A record of false falls can be used for initiating a dormant mode to change the sensitivity for fall detection of DSD100. After exceeding the limit for false falls, such as three false falls, controller122can enter a dormant mode where a modification is made to a fall detection process so that the fall detection process becomes less sensitive to changes in acceleration in determining whether DSD100is in a falling state.

An example of a fall detection process can be found in application Ser. No. 14/033,048, filed on Sep. 20, 2013, which is hereby incorporated by reference in its entirety. In such a fall detection process, an initial acceleration threshold can be decreased so that a lower acceleration is needed in the dormant mode to initially indicate a possible falling state. A weighting of a classifier function used to confirm a falling state may also be adjusted in the dormant mode to decrease the sensitivity of the fall detection process. As will be appreciated by those of ordinary skill in the art, other ways of changing fall detection sensitivity are possible.

With reference toFIG. 4, if controller122determines in block308that the ratio is greater than the relative threshold (as in the example ofFIG. 10after 1,600 ms), then controller122determines that an impact has been detected in block312.

The detection of an impact can be used by controller122to confirm that a falling event has ended and to terminate a fall detection cycle. The detection of an impact can also be used as a trigger to move head129back over disk102. Thus, in addition to distinguishing between false falls and actual falls, the foregoing impact detection process can further serve to prevent a premature return to normal operation during an actual fall before impact occurs. For example, where electronic device110is a laptop, the lid of an open laptop can wobble during a fall and may trigger a premature end to a fall detection process in a conventional system. The impact detection process disclosed above can typically avoid such a premature detection of impact by considering the average of acceleration change values.

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, and processes described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Furthermore, the foregoing processes can be embodied on a computer readable medium which causes a processor or computer to perform or execute certain functions.

To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, and modules have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those of ordinary skill in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The activities of a method or process described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The steps of the method or algorithm may also be performed in an alternate order from those provided in the examples. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable media, an optical media, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can 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).

The foregoing description of the disclosed example embodiments is provided to enable any person of ordinary skill in the art to make or use the embodiments in the present disclosure. Various modifications to these examples will be readily apparent to those of ordinary skill in the art, and the principles disclosed herein may be applied to other examples without departing from the spirit or scope of the present disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive and the scope of the disclosure is, therefore, indicated by the following claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.