Very similar to this SuperUser question, I'd like to know if there's a way to know when the SMS is actually engaged.

Note that I do not want to know if the sensor is enabled (which can be done from the Terminal with sudo pmset -g). Specifically I want to know when the sensor trips and forces the hard drive's head to park, and when it senses the danger is clear and allows the head to move again. In an ideal case a Growl notification would be fantastic, but even a log would suffice.

I ask because as Apple notes on their support page, the SMS can be tripped in certain environments such as nightclubs when it would be undesirable. However the only way to know if you are in such an environment is by guessing since I haven't found a way to tell the frequency or length of time the SMS actually causes head parks. I understand the simple thing to do is disable the sensor outright, but the point of the question is how to gain visibility into the actual activity of the sensor.


The Sudden Motion Sensor state is available through IOKit.

An open source library, SMSLib, provides an Objective-C interface and sample command line tool for accessing the state of the Sudden Motion Sensor:

SMSLib is the software library used by SeisMac and SeisMaCalibrate to access the Sudden Motion Sensors in recent Macintosh laptops. Written in Objective-C, it provides easy and stable access, abstracting hardware differences across eleven different models of laptop. For better accuracy, you can use SeisMaCalibrate to calibrate your laptop's Sudden Motion Sensors. SMSLib is open source, released under the University of Illinois/NCSA Open Source License.

Additional sample code and tools are available on Amit Singh's Sudden Motion Sensor page.

A relevant technical question was asked on StackOverflow about this topic, Polling the accelerometer/motion sensor in a MacBook Pro.

| improve this answer | |
  • That definitely provides a mechanism for seeing the raw state of the accelerometer (you'll see I even mentioned Amit Singh's page myself), but it doesn't sound like it's able to tell you if the operating system has decided the park the hard drive's head due to the severity of the input. My question is specifically about gaining visibility into the hard drive's state in direct response to SMS input. – beporter Jul 25 '13 at 18:03
  • @beporter the SMS code suggests the state needs to be actively polled for changes; this suggests there is no obvious user level notification or hook to observe for changes. You will need a IOKit tool that actively polls for changes and notifies you. – Graham Miln Jul 26 '13 at 10:40
  • My point is that the operating must already be doing that polling itself, and triggering a head park above some SMS input threshold. As you say, there doesn't appear to be any way to obtain whether the system is currently "above" or "below" that threshold in the same way that pmset -g ps will report whether the system is currently on AC power or not. – beporter Jul 26 '13 at 16:14
  • @beporter do have an Apple Developer Connection membership? If so, consider using a Developer Technical Support (DTS) incident for this question. I suspect the state changes are too short to be noticeable. Also, are you see jitters in audio output or recording to disk? Are you seeing behaviour that might hint that head parking is a problem? – Graham Miln Jul 28 '13 at 15:54
  • Yes, the original impetus for the question was severe response times measured in double-digit seconds from an otherwise "okay" (SMART, stress tests, other machines, etc.) disk. Those issues have since been resolved but I wanted a way to determine (conclusively, not just by disabling it) whether SMS triggering an extended head part was at fault. I'll upvote, but can't accept since there is no way (yet) to obtain the state I was asking about. Thanks! – beporter Jul 29 '13 at 16:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .