kernelthread.com

The PowerBook Sudden Motion Sensor

© Amit Singh. All Rights Reserved.

Apple added a feature called Sudden Motion Sensor (SMS) to the PowerBook line in early 2005. The sensor attempts to prevent data loss by parking the heads of an active disk drive after detecting a "sudden motion", which could be due to strong vibrations or a fall.

The SMS is also called the Mobile Motion Module. The Mac OS X kernel refers to it as "ams", for Apple Motion Sensor. Hereafter, we use the term "AMS" to refer to both the hardware and its software abstraction.

Background

In modern disk drives, the "flying height" between the platter and the head is very small. This increases the possibility of a disturbed head colliding with the platter. Modern drives support "parking" their heads in a safe position under various circumstances. In particular, heads are automatically parked when a system is powered off or sleeping. AMS adds the ability to park the heads in the event of an accidental drop, strong vibrations, or other abrupt movements. It works by detecting changes in the computer's orientation or the presence of accelerated movement. When the threshold for emergency action is reached, say, because of shock or "free fall", an interrupt is generated. Processing of this interrupt by the AMS driver may result in a "park" command being sent to the drive in a platform-dependent manner.

In the current context, we define free fall as a sudden change in G force.

For example, if a PowerBook is just beginning to fall from a desk, AMS would park the drive heads to reduce the possibility of damage to the drive upon impact. Conversely, when AMS detects that the PowerBook's orientation is once again level, it unlocks the drive heads so that the system can continue to use the disk normally.

AMS is an integrated feature of the main logic board, and is not tied to a specific disk drive. It is yet another Inter-Integrated Circuit (I2C) device added to Apple's hardware repertoire. Examples of other I2C devices used by Apple include fan controllers, temperature monitors, voltage monitors, and so on.

I2C

Philips developed the I2C bus in the early 1980s. I2C is a multi-master control bus using which various ICs in a system can communicate with each other. It uses only two control lines, and has a software-defined protocol. I2C compatible devices typically have on-chip communication interfaces for direct communication with each other over the bus.

While the I2C specification does not explicitly limit the number of devices (ICs) connected to an I2C bus, the maximum total capacitive load is limited (for example, to 400 pF in Version 2.1), thereby indirectly limiting the number of devices that can be connected to a single bus.

Too Sensitive?

It is interesting to note that depending on your working environment, the default sensitivity of AMS may be too aggressive. For example, loud music, perhaps with rather high bass and consequential vibrations, can activate AMS undesirably. If the PowerBook in question is itself involved in the generation or recording of the music, AMS may cause unacceptable interruptions. It is possible to disable the AMS module using the pmset power management configuration utility.

$ pmset -g Active Profiles: Battery Power 1* AC Power 3 Currently in use: acwake 0 ... ams 1 $ sudo pmset -a ams 0 $ pmset -g ... ams 0

Toggling AMS availability using pmset is permanent in that the change is preserved across reboots. You must explicitly re-enable AMS.

$ sudo pmset -a ams 1 $ pmset -g ... ams 1

Determining a PowerBook's Orientation

AMS Axes
Figure 1. AMS Axes

AMS can be accessed from user-space for various purposes, such as:

With the exception of temporarily enabling or disabling AMS, as described earlier, the end user should not need to manipulate the AMS hardware in any other way. Nevertheless, the orientation data provided by the sensor can be used for some interesting demonstrations.

One set of data provided by AMS is the triplet { x, y, z }, where the meaning of each quantity is pictorially depicted in Figure 1.

Another way to look at this is that the x, y, and z values represent the decomposition of the acceleration vector acting on the PowerBook. You can view individual components of this vector change by rotating the laptop (thereby changing the angle of the gravity vector) or applying external acceleration (such as a sideways sudden motion).

It is interesting to note that the accelerometer in the PowerBook is calibrated to read (0,0,0) when the laptop is in freefall in a vacuum. In practice, all AMSs may not be calibrated perfectly, or equally. Thus, x and y values may not be zero in a perfectly "stable" position. Moreover, depending on your surroundings and the configured sensitivity of the AMS hardware, you may see minor fluctuations in values even when there is no perceptible movement.

While I have no knowledge of how AMS works internally, it quite likely uses a "silicon" sensor based on integrated micro-electromechanical systems (iMEMS) technology. Acceleration or inclination causes an electrical property of the sensor, say capacitance, to be altered. The sensor's interface can appropriately translate these tiny changes to present them as acceleration "readings".

Demonstrations

This section contains some examples of using the orientation data obtained from the AMS module.

My primary reason for looking at AMS was to come up with some instructive and interesting examples for certain chapters of a book that I am writing on Mac OS X (see more detailed note at the end of this document).

Faking the AMS

While I did get to play with an AMS-equipped PowerBook for a little while, long enough to be able to retrieve the orientation data, I do not actually possess such a PowerBook. I expected not having the actual hardware to be an annoying stumbling block while preparing the examples. Consequently, I created a trivial "fake" implementation of AMS in software. This dummy AMS gives me "orientation" data based on the displacement of the mouse pointer with respect to the center of the (primary) screen. Thus, x and y are zero when the mouse pointer is perfectly centered. Moving the pointer left and right changes the 'x' values, while moving up and down changes the 'y' values. z values are ignored. Note that the values are artificially constrained to the range [-127,+127]. This means that for the mouse pointer to cause the reported values to change, it must be within a 254 x 254 pixel square whose center coincides with the screen's center.

An important advantage of this approach is that all examples can be tried on machines other than AMS-equipped PowerBooks.

Command-line Monitor

amstracker is a simple command-line utility that retrieves and displays x, y, and z orientation values (in that order) from the AMS hardware (technically, from the AMS driver in the kernel). amstracker can work in three different ways. The first is one-shot, wherein it prints one instantaneous triplet and exits. If you run amstracker with no arguments, this is the mode it will run in.

$ ./amstracker AMS hardware present and initialized -4 1 -20

In the other two modes, amstracker loops forever (until interrupted), retrieving and displaying orientation data periodically. You must specify the time period as seconds or fraction of a second. The modes only differ in that one scrolls its output, while the other updates the values in place.

$ ./amstracker -u 0.1 # update every 0.1 seconds ...

AMSTracker may not be redistributed.

Download AMSTracker.

Orientation Visualizer
AMS Visualizer
Figure 2. AMS Visualizer

AMS Visualizer is a logical graphical extension of the amstracker command-line tool. It displays a 3D image of a PowerBook 15 that appears to "hang" in space. Note that the PowerBook model is hardcoded, but it would be easy to make the image correspond to the physical machine the program is being run on. The orientation of the on-screen image is a real-time approximation of the computer's physical orientation. Thus, if you tilt the PowerBook left, the image will immediately tilt left; if you roll the PowerBook backwards, the image will roll backwards, and so on.

Note that the image is not generated using some form of Virtual Reality technology (such as QTVR), but is "handcrafted" by stitching together high-resolution 2D textures using OpenGL. Each face of the on-screen PowerBook is simply an OpenGL texture.

I have tested the visualizer exactly once on actual hardware, and it appears to work as intended. There may be some scope for improving how the on-screen rendition mimics the motion of the physical computer, but that would require some tweaking and tuning on an AMS-equipped PowerBook.

Note that you can zoom the visualizer window.

Download AMSVisualizer.

version history
Version Changes
1.051 Updated for Mac OS X 10.4.3
1.03 Since people still keep having "y-direction-flipped" issues, the simplest solution is to add toggle buttons that let you flip the default x and y directions of motion dynamically.
1.02 Changed direction of on-screen movement along the y-axis to match that of the physical machine (it was flipped earlier).
1.01 Fixed race condition due to which the application may cause a segmentation fault while exiting.
1.0 Initial release.
A Self-adjusting "Stable" Window
Stable Window
Figure 3. Stable Window

This example creates a window displaying a bicycle wheel. The window is "stable" in the sense that if you rotate the PowerBook left or right, the window compensates by rotating itself by an equal amount in the opposite direction in an attempt to remain in its original orientation with respect to the ground. The bicycle wheel rotates too — independently of the window.

Some might opine that this is in fact a very unstable window. I wouldn't argue with that.

You may move the window while it is "stabilizing" — any compensating rotation is deferred as long as you keep dragging the mouse pointer.

Download StableWindow.

The Perturbed Desktop
The Perturbed Desktop
Figure 4. The Perturbed Desktop

The "perturbed desktop" is hard to describe, and perhaps impossible to justify, even for a book example. It could be thought of as roughly the Stable Window concept applied to the entire graphical user interface, and then made unstable via some constraints. Now, nobody needs (hopefully) such "stable" windows in real life. Nevertheless, it is interesting to note the type of visual operations that are possible in Mac OS X.

The perturbed desktop starts life normally, but soon gets very ... perturbed. The orientation of on-screen windows is set to be a strangely complicated function of several things: the physical orientation of the PowerBook, the amount of resources consumed by the application, and how much the user is using the application. Based on these factors, a given window's orientation keeps changing. Regardless of orientation, however, you can still interact with all windows.

Needless to say, it is quite a hellish experience trying to use the computer in this manner.

Download Perturbed Desktop Movie (2.2 MB, QuickTime format)

Other "Uses"

While the PowerBook only uses the AMS as a defensive measure to prevent accidental damage to the disk drive, such sensors could have a variety of uses. In particular, they have been considered as alternative input methods in user interfaces for video game controllers, phones, PDAs, and other mobile devices. While it is to be seen if they will be successful in these areas, such use at least has a novelty value.

Given that tilting the PowerBook in various directions can be mapped to mouse or keyboard input (say, the arrow keys), one could readily use this feature for purposes such as:

An important caveat is that if one were to use the AMS for anything that involves moving the machine, it would be undesirable to have the module keep parking and unparking the heads as the computer moves. While the AMS is being used for "other" purposes, its emergency head-parking feature should ideally be disabled.

Acknowledgments

I would like to thank my friend Mark "TurkeyBoy" Smith for performing some crazy and dangerous (both to him and the hardware) experiments with his manager's PowerBook. One of the experiments was to drive up and down a hill (I would like to think it was a closed course) in a car at breakneck speeds, measuring acceleration and what not. Such experiments were very helpful in understanding the semantics of the data reported by the sensor.

My Book On Mac OS X

As I began using Mac OS X, I wished to understand how the system is put together and how it works internally. My interest in Mac OS X is based not on years of Mac loyalty or zealotry (I possess neither), but on my years of working in the area of operating systems. The book is a means of sharing the results of my analysis and study of Mac OS X.

I decided to write the book shortly after I published "What is Mac OS X?", which generated an overwhelmingly positive response from "the Internet". I have been working on the book in my spare time since March 2004, which amounts to exactly one year as of this writing. If things go as planned, the book should be out in the second half of 2005. I am very satisfied with the progress made so far, and very excited about the potential outcome of this endeavor.

The book is an "internals" book, describing the architecture and design of Mac OS X. Throughout the book, I have attempted to use interesting programming examples extensively to demonstrate concepts and their working. Consequently, much of the book's content is rather technical in nature. Nevertheless, it is meant to appeal to a wide variety of audiences: ranging from hardcore technophiles to those not at home with the nitty-gritty, and from those who use and like Mac OS X to those who don't. This goal seems rather arduous and far fetched. It is. One of my guiding principles is to favor the cool and the unconventional over the dogmatic and the stereotypical.

The book is not a manual, a guide, or a text-book: it is simply a book that tells you many interesting details of how the operating system works. Hopefully every reader would find something worthwhile in it.

The purpose of this exercise on the PowerBook's motion sensor was to create one or more examples for the book.

I must point out that my goal is not to create an "Undocumented Mac OS X" style of book. In particular, the book will not describe ways to subvert or reverse engineer the operating system. It is possible to claim this since much of the core Mac OS X is open source. While the book describes various topics beyond what is covered by published APIs (such as how various components of Mach work in Mac OS X), the presentation is almost always based on Apple's published source code. Only in a few cases (such as the AMS examples on this page) any semblance of reverse engineering is used in the book.

Kernelthread.com has a few other examples of adaptations from the book, such as "A History of Apple's Operating Systems", an improved version of which is the first chapter in the book, and "hfsdebug", which is a companion program to the filesystems chapter.

I intend to launch the book's accompanying web site well in advance of the book's release, so as to kindle the interest of potential readers by giving them further details of the book's contents. Please stay tuned.

Amit Singh