Still curious about the dbus question a few posts up. Much obliged to anyone who can answer or point me in the right direction.

We are working on this (it will be more advanced, but API for accelerometer will be there also) for C++ It goes really nicely with Qt.

AFAIK official DBUS API/docs are not yet available

Does anyone know anything about the internal workings of the accelerometers used on the N900? My interest is professional - I know quite a lot about seismometers and full-size accelerometers.

I had assumed (perhaps foolishly) that it used piezo-electric accelerometers. These and all the other small motion sensors that I know about are only capable if giving an output in response to a change in position. They give no output at all if the device is not moving and so could not be used to determine the orientation of a static device.

The wiki page demonstrates that the N900 accelerometers do vary their output with orientation and so can be used to determine orientation.

For the life of me, I can't work out how they do it.

Pure Magic ®

Seriously, no idea. But I can confirm, that it is able to give you value of Earth g.

An accelerometer _must_ vary its output depending on orientation, as we're constantly under the force of gravity. Turn the device upside-down, and the reading should go from (0,0,-1) to (0,0,1).

If you want to know how these kinds of accelerometers are made, and work, I seem to remember that Freescale Semiconductor had some interesting application notes on their website which included electron micrographs of the innards - wonderful structures. Nokia don't use FSL accelerometers, it's just that I previously worked at FSL and am more familiar with their sensors than any others. The n900's is an ST device, in fact, and the specs are publically available.

Ditto the kernel source - it is all open, so just take a peek at the lis302dl driver. There are some features that aren't utilised, but all the bread-and-butter stuff's supported. There's a trivial sysfs interface for reading the current value, so even shell scripts can use it!

In fact, the running and jumping code in Oliver McFadden's quake3 arena demo just uses that sysfs accelerometer interface. I know that, as I wrote it '-)

Nokia has used ST's accelerometers in the past (at least my 5800 XM that I accidentally drowned in beer had a digital ST accelerometer, pretty much the only component that Google told anything interesting about but can't remember the exact number now), so I wouldn't be surprised to find an ST accelerometer in the N900 as well. ST has done it quite elegantly: they sniff out the capacitance variations between micromachined or etched beams of coated silicon placed perpendicular to each other. Movement causes the masses at the ends of the beams to follow more "slowly", causing a measurable variation in capacitance due to bending of the structures. The datasheet tells you more, just see ST's web pages.

Yup, they're beautiful (to a geek!). Accelerometers designed for different numbers of axes can have different designs, but they all rely on the sprung pendulum you describe . On the whole the 3 axes ones are the most intricate, so my favourites.

Hi,

I'm porting a medical application which measures activity levels of seniors using the N900 accelerometer. It requires accurately timed accelerometer samples. I've looked at the accelerometer driver and it uses an interrupt to read the accelerometer which is likely to result in precise sample times, but that precision in timing is lost when accessing the accelerometer data via the DBUS or via it's file device interface because DBUS calls can be delayed by system events, as can reads from the file device. I've tried both and the jitter is unacceptable (4 milliseconds variation at best when no other apps are running and 50 milliseconds with an audio app running with a 100Hz sample rate). Perhaps the accelerometer data should include a timestamp from the driver?
Or maybe I can just assume a precise interval between readings if I read faster than the default sample rate of 100Hz (if I read data at 200Hz each reading should repeat twice so I'd be able to tell individual readings apart as long as they were changing)?

Ron