- © 2006 by the Seismological Society of America
I describe the development of a simple seismology application. The application, SeisMac, reads accelerometers built into recent Apple Macintosh laptop computers and displays real-time three-axis seismograms. The results are not highly precise, but they are fun to watch and offer educational possibilities. I write as a software engineer interested in seismology for an audience of seismologists interested in software.
In January 2005, Apple introduced the Sudden Motion Sensor™ (SMS) in its high-end laptops. The SMS is a three-axis accelerometer linked with the hard disk, so that if the laptop suddenly finds itself in free fall it can anticipate an impact and park the hard disk heads in a safe area, thus reducing the effect of the impact. Apple included the SMS in all its laptops starting in July 2005. IBM had begun including a similar feature, the Active Protection System™, in its ThinkPad laptops two years earlier; Acer Inc. is just now releasing its GraviSense™ utility.
Apple did not intend the SMS to be accessible to third-party programmers and consequently has not published a corresponding Application Programming Interface (API). However, when SMS-equipped laptops became available, intrepid programmers began investigating the SMS system using low-level debugging tools. They deduced the software function calls that Apple's own software uses to access the SMS. Soon a number of small programs became available that used the SMS data, including a motion alarm, a carpenter's level, game interfaces (e.g., tilting your laptop to control a 3-D rolling marble), and my favorite, MacSaber, which makes Star Wars light saber noises based on how you move your laptop.
I purchased one of the new MacBook Pros in March 2006 and started experimenting with these SMS-capable programs. A number of the programs' authors had published source code showing how to access the SMS, so I decided to try my hand at writing an SMS-capable program. But what should the program do?
The first hint came when I tested access speed for the SMS on my machine and found that the SMS could yield hundreds of three-axis samples per second. But how should this be displayed? The obvious choice: a moving graph. And what is a moving-graph display of the accelerations recorded on a fixed object? A seismograph (at least to us non-geologists). Thus was born SeisMac.
I decided to offer SeisMac as freeware for a number of reasons. The market would probably be small, and SeisMac would be no more than amusing for most users, so I couldn't make much money from it. I didn't want to commit myself to reliability, since it would use an unsupported Apple API that could fail the next time Apple updated the operating system. Finally, I wanted to contribute to a long tradition of high-quality freeware written for the Macintosh.
I wanted SeisMac to be a simple-to-use, fun-to-look-at tool with a clear interface and few bells and whistles. It should function as a business card, showing my programming abilities. I also wanted it to work on as many different Macintosh laptop models as possible. This was difficult, because Apple has changed the underlying SMS hardware and access functions a number of times. So, I wrote an SMS access library that knew each method of reading the SMS and tried each of them until one succeeded.
The rest of the creation process was fairly standard. Tests, prototypes, interface design, more tests, Exploring different techniques for drawing the graph. Help system, icon, “About” window, packaging, web page. After two weeks of work, it was finished. I released SeisMac on July 4, 2006.
With SeisMac finished and published, I turned to the most obvious omission: calibration. Although the SMS access library includes guesses about the offset and gain values for each accelerometer in each type of Macintosh laptop, they really weren't very accurate, and in some cases were way, way off. As user reports came in I could have tried to improve the guesses, but even with the best per-model defaults there was no way I could allow for individual variations in the accelerometers.
So, how do you calibrate an accelerometer? By subjecting it to a series of known accelerations, recording the accelerator's outputs, and deriving the accelerometer's offset and gain. The problem is that generating accurate accelerations can be difficult, and I wanted users to be able to calibrate their machines without additional equipment.
Luckily, the “acceleration” of the Earth's gravitational pull is quite constant, changing less than 1% from the equator to the poles and from sea level to the top of Everest. Furthermore, the SMS accelerometers' ranges comfortably include plus and minus 1 g, all recent Macintosh laptops are precisely rectangular, and it's easy to find a level surface. That made it simple to subject the three SMS accelerometers to zero and 1 g accelerations, record the responses, and calculate their offsets and gains.
With that in mind, I designed and wrote a second application called, poetically, SeisMaCalibrate. It prompts the user to set the laptop on its bottom, then its side, and finally its back, all the while recording the accelerometers' values. The values are averaged over several seconds in order to filter out any true seismological information, although it's likely that poor results would be obtained during a major earthquake. Values are recorded in the three different orientations, and the offset and gain values are calculated and stored for future SeisMac use.
The results are good. After calibration, my MacBook Pro reads within 1% of the expected values. When the laptop is held at various angles to the horizontal the displayed values matched predicted values, which indicates that the accelerometers are fairly linear as well as repeatable.
As a bonus, SeisMaCalibrate includes a “Create Calibration E-mail” button that, when clicked, creates an e-mail addressed to me containing the full specifications of the user's machine along with its most recent calibration. I've gotten nearly a hundred such e-mails, and they have been quite educational. The SMSs in G4-based laptops all read about 50 counts per g, with zero g being about zero, but every model has different polarities for the different axes. The SMSs in Intel-based laptops are much more consistent; they all read about 255 counts per g, with zero g being about zero, and the axis polarities being consistent. I'll include this information in a future version of the SMS access library so that SeisMac can, without adjustment, display reasonably accurate results.
The response to the applications has been very gratifying. Almost 30,000 people have downloaded SeisMac. A thousand downloaded SeisMaCalibrate as well. More than 200 have written me about the programs, with problems (which I have tried to address), compliments, and suggestions. One pleasant surprise has been the number identifying themselves as seismologists who offered plaudits, criticisms, suggestions, and queries. Several wrote that they had used SeisMac in the classroom. Because no additional hardware is required, and the display is clear and evident, students quickly grasp three-axis seismograms and the relationships between the axes.
One mistake in the first version was in the direction of display. The obvious choice was to display the data left-to-right, while keeping the most recent data onscreen. So, I had the most recent data appear on the left edge of the window, with the graphed data sliding to the right. It took a seismologist to point out that I'd actually managed to display the data right-to-left, which is the opposite of how seismograms usually are drawn. This has been corrected.
One difficulty is that SeisMac is sometimes unable to access the SMS on SMS-enabled G4 PowerBooks or iBooks. On these machines, SeisMac often will function the first time it is run but then not again until the laptop is rebooted. This obviously reduces its utility on these machines. I think that this problem occurs because Apple Computer did not expect third parties to access the SMS driver and so did not prepare for the resulting conflicts. Maybe I could work around the issue. However, there are no more G4 laptops being made, I don't own one, their SMSs have only a fifth of the resolution of those in the current Intel laptops, the problem does not occur on the current Intel laptops, and perhaps no efforts of mine could improve the situation. I have decided to document the issue but not try to correct it.
SeisMac works well, but it is about as bare bones as can be. I'm considering a number of enhancements, many suggested by users, that would make it much more enjoyable and educational to use. Many of them will be completed by the time this article is published. The possibilities include:
A control for adjusting the vertical scale, both to zoom in on gentle motions and to completely display vigorous motions
A control for adjusting the horizontal scale, both to show quick events in detail and to view long-term activity
Better default values for accelerometer offset and gain on different models of PowerBooks and iBooks
The capability of smoothing the data to remove noise
Providing access to older data for display and printing
Release of the underlying SMS access library as open source under the GNU Lesser General Public License; this would allow anyone to use it for any purpose as long as credit is given
These features would be fairly straightforward to implement and would probably yield considerable benefit.
More complex features also have been suggested:
Integrating the acceleration data to produce velocity data (as is shown by a true seismometer) or even twice to provide position data. This could be problematic because of sampling errors in the accelerometers. Integrating a fixed acceleration error leads to a steadily increasing velocity error. Integrating again leads to a geometrically increasing position error. Even with a MacBook Pro's higher-quality accelerometers, a one-count acceleration error could yield a laptop-sized position error in a few seconds.
Adding the ability to write collected data to standard seismic file formats. Unfortunately, there is no single standard for seismic files, and the existing formats include many data fields that are incompatible with SeisMac.
Adding support for external sensors (e.g., an external seismophone connected to a third-party digitizer). The APIs for these digitizers are often proprietary, and this would conflict with the goal of making the SMS access library open-source.
Converting the time-oriented seismic data to frequency-oriented data using a fast Fourier transform. The data could then be observed for resonances in the computer, the table, the building, and perhaps even the surrounding terrain.
Adding the ability to show data as a rendered three-dimensional image. For example, the three axes of acceleration could be summed and shown as a single three-dimensional arrow pointing in the direction of the acceleration, with the length of the arrow proportional to the magnitude.
One last feature would be very complex to implement but could be scientifically quite useful. SeisMac could include an always-on background process, combining its acceleration data with GPS-derived location and time data and reporting the location- and time-stamped data to a central server for processing. The server would take data from all participating SeisMac users, correlate between stations, filter out station-specific events (which would include any nonseismic noise), and yield a detailed seismic propagation map. If there were enough participants the data might be good enough to supplement the network of formal seismometers.
SeisMac is a simple tool that takes advantage of Apple's hardware for a new purpose. While not yet scientifically useful, it is a good classroom and outreach tool. It was a lot of fun to write and is a lot of fun to use.
Thanks to Amit Singh, Pall Thayer, and Randy Green for their insight on techniques for accessing the SMS; to all those who wrote with suggestions, plaudits, and, yes, bug reports; and to Dr. N. Thorne Griscom for all his suggestions and help.