Altitude, From Math to Reality

Raw info from Android's GPS API is good for determining position. Not so good for determining altitude!

Why not? Well, there is a difference between a perfect mathematical model of earth which GPS service uses to calculate altitude and the real shape of the earth. First one uses a Geoid which represents Earth as a perfect, slightly squished sphere to calculate altitude based on GPS time signals. As for us, we measure altitude from mean sea level. But this changes from point to point on earth, dues to gravitational differences (e.g. Earth is thicker on equator then it would be in Europe) and is represented by an Eclipsoid.

The first part is to eliminate the difference between this two to get ab accurate reading (not yet counting satellite time signal margin of error, but that is a problem for another time).

Now, after some searching, this is the most helpful project (GeoidEval) with an online utility (or data and code to process the information offline) which takes Earth's gravity model EGM84, extrapolates it for a provided coordinate and calculates the hight of Eclipsoid above the WGS84 Geoid, used in the GPS measurements, allowing us to correct the data accordingly:

The first image was render using raw data, where the second one was render using data corrected with the Geoid-Eclipsoid difference.

You might also notice that, while starting point is on the surface, there is a parth of path missing (looks like it's just under the surface) and the and point appears to be just over the surface! This is withing the (2-8 meters of error due to rapid movement and changing of satellites mid flight), but is still as such a much more accurate and usable representation of altitude.

Connecting Internet to the Droid

Connecting with Android to a service on the Internet over EDGE or 3G (or what ever) is no rocket science.

Now, connecting from the Internet to a service on an Android device is a whole other story!

This could depend on mobile providers, but it's safe to assume that most do not assign public IP addresses to your phones for them to access the Internet, but instead you get a private IP on mobile provider's local network, which is then routed to the Internet trough their routers.

What that means, there is no way to connect directly to your Android device if it's on mobile Internet. There are a couple of ways to go around that, but all require a third party component.

The method chosen for this project is to link the Android device (acting as a server) and a computer (acting as a client) in to a Virtual Private Network.

Easiest way (with least components) to achieve that is to have a VPN support in a router which connects to the Internet with with a public IP address (DSL, Cable, ...). Hence the post below.

Once the VPN service is established (for now PPTP was used for being the simplest and widely supported with options for encryptions if needed), the connected devices can once again communicate between themselves as if they were on the same network, which means accessing opened ports on an Android device with a service from a client far far away.

Why would this be useful to go trough so much trouble? Tracking "real time" telemetry from the plane, like position, altitude, speed, status, images from the on board camera.

Saying "real time" since because all the routing there is a lag between information and reception of that information (once a connection is established latency way about 200ms to 700ms in this test, to infinity ms if reception is bad):

Driving in a car with HTC G1 running a tracking service and a laptop connected to mobile Internet running a client and displaying data on Google Earth.

The whole rout was: HTC G1 -> mobile provider -> broadband provider -> home router -> broadband provider -> mobile provider -> HP laptop.

Using Old Tech to improve New Tech

Now, before the next problem could be solved, some updated network capabilities were needed.

That turned out to be a project on it's own.

Suffice to say, a VPN was needed. And the easiest way to go about having a VPN is to have it implemented in your router. And one of better ways to achieve that is to install OpenWRT on it (if it's supported of course).

Now, entrusting that to a small box on top it's duties of being connected to the Internet and routing traffic trough the network, might take a toll on the already overheated CPU inside.

So additional cooling was installed:

Take one router with supported hardware, one decade old CPU with ceramic casing, one serving of thermal paste and a shot of super glue.

Apply the thermal paste on the router's CPU, with just a touch of super glue on the clean corners, align and press the upside down "museum item" on the paste and wait a few seconds.

Lesson learned: old AMD CPU's work very well as passive heat sinks!

Names

A note for future reference.

The name of the "autopilot" application will be Anemoi.

After a Greek group of wind gods, each responsible for their cardinal direction, which in this case will be replaced by a group of small deamons (no, it's not misspelled) controlling pitch, yaw, roll and speed.