So, I've been wanting to make a Time Dilation app for the smart phone for a little while now, and I'm about to the point where I've convinced myself that it is entirely possible.
So, the main idea is that one could use the accerometer / compass / GPS on a smart phone to compute a trajectory, and then apply the proper time dilation, where you could hand pick the value of c in order to turn the effect up to 11.
The Physics
So, a nice way to summarize the effects of both SR and GR on a clock near the earth is given by [from
Wiki]
where
![\tau [;\tau;]](https://ci3.googleusercontent.com/proxy/x4mpZh8KQY06T-R7t82gnSsGl4mkz6YY6DY63JJd5IlvAGlidSW_N_3F0zLhZ9EVQa1myyTer7Sqyjw=s0-d-e1-ft#http://www.codecogs.com/gif.latex?%5Ctau)
is proper time,
![t [;t;]](https://ci5.googleusercontent.com/proxy/Nszi75P3_61rm3huAthCaGFS33LA4bLE69eY5gQFKMNX2Dg5KlBf6dYNiPigFzCeOUd1lZtk=s0-d-e1-ft#http://www.codecogs.com/gif.latex?t)
is coordinate time,
![g [;g;]](https://ci4.googleusercontent.com/proxy/hi6Ji34ftMJPx0GuDlcq2xEbRIN1QyIpA2Y81G4kBiJ2iXC3e_waelP7E66BGwALrpM4u10U=s0-d-e1-ft#http://www.codecogs.com/gif.latex?g)
is the local gravitational acceleration,
![R [;R;]](https://ci4.googleusercontent.com/proxy/UxFP5WeHV9Erg7UztD_qLp_3gYXdA1YBJWGVzoTsVxso6uUJKzYnNQCmlGPZmkvl-N54J12F=s0-d-e1-ft#http://www.codecogs.com/gif.latex?R)
is the distance from the center of the earth,
![c [;c;]](https://ci5.googleusercontent.com/proxy/qsR8OXTMpZbS_y2XiYU9MFHXbNDdxdLaRL5h65XrY66NVWGaBGPR3DF1fvpjB6GfTxRSOaQG=s0-d-e1-ft#http://www.codecogs.com/gif.latex?c)
is of course light speed, and
![v_{\parallel} [;v_{\parallel};]](https://ci3.googleusercontent.com/proxy/lQ8AtLvnbl52xvritwFnxlKXEsYNDlFqBL6DBBmvTHLW8ADdCbYh7k2R4-r-NyCYHzaCGJYDqUcoP2OcckOp-UYrTn-dIb-Y=s0-d-e1-ft#http://www.codecogs.com/gif.latex?v_%7B%5Cparallel%7D)
is your radial velocity.
All of these should be obtainable from the accelerometer / compass of the phone, albeit with some fancy numerical integration techniques to ensure that there is not too much error. Couple this will corrections from the GPS and you should have a somewhat accurate path computer. That path computation could be turned into a time dilation, which the app would register.
The Obstacles
The obstacles to making this happen are (1) Android programming is natively Java, which I don't really know. This should just mean that we gotta spend some more time on it. Not necessarily serious (2) A more real issue is how do you take very noisy accelerometer and compass / orientation data and integrate it to get a velocity in a way that is immune to noise. I thought about
Kalman filters, but these seem to rely pretty crucially on one having a fairly good model for how the object moves, where in this case, since people are just going to be waving their hands around, we would lack that kind of model. More generally, I think we would have to program some kind of Bayesian network that samples the noisy sensors we have and turns it into a reasonable velocity estimate. Couple this with the fact that we have at least two independent sources of information, the GPS (which gives coordinate and velocity information, albeit with large error, but is sort of what we want, but lacks some radial information), with the accelerometer and orientation stuff which is one time derivative up from what we want, samples a lot quicker, but is pretty darn noisy. We need to intelligently combine these two sources of information. This is the major open problem in the way.
Some Resources
I found this neat video, talking about some of the sensor fusion work that has been done on the Android platform:
http://www.youtube.com/watch?v=C7JQ7Rpwn2k talks a bit about the kinds of issues I pointed out above.
Game Plan
I think a reasonable first step would be to use an existing program to log all of the data sources we want from the Android device, and test our our integration techniques to see if we can get what looks to be a reasonable path prediction out of it. I tried to do a bit of this, using the program:
Sensor and GPS Monitor, but it isn't exactly explicit in its logging capability, though the author's website has a utility to take the binary log files to ascii:
http://www.instk.org/
I'll try to post some log files a little later.