soledad penadés

The capturer

My Tracks was OK-ish to start with, but I wanted something which recorded all events--My Tracks only records a segmented, simplified approximation, which is useless for replicating/simulating real tracks at home with the emulator. So I wrote a simple Android application that dumps all captured GPS events into an XML file in the phone's SD card for later analysis.

So far I have only stress-tested it with the track shown in the video, which is ~500 points long, so I'm not sure how much memory or battery it uses if running for a long time. It seemed to be generating an event every second or so.

The funny thing I've observed is that because I'm listening to both Network and GPS location events, whenever the phone cannot obtain a GPS position, it reverts to the closest tower cell position. It is shown in the video as sudden jumps (mostly when I pass through covered places such as trees or... whatever the GPS receiver deems to be too difficult), but when all the points are plotted and joined together with a line, it gets really evident where the tower cells are. Here's an example of the map in the video, generated with the next version of my online kml to ddms tool (which I haven't uploaded yet :P)

Next time I'm around that zone, I'm going to have a look and see if there's really a tower there!

It might be interesting to record the same track with the different phones we've got here (HTC Magic, Nexus One and HTC Evo 4G) and compare the results in order to find out if there's any noticeable difference between quality of GPS reception between them...

The replayer

I was finding increasingly cumbersome the process of manually loading a track in Eclipse whenever I wanted to play a captured track, and I finally decided to build my own "replayer".

It connects via telnet to the emulator, and sequentially sends it the coordinates loaded from the specified input file.

Yes, it essentially replicates the behaviour of the existing Android Eclipse plug-in, but since it can be launched from the command line and also all parameters are specified there as well, it's easier to launch these simulations than it is opening the DDMS perspective, loading the track, and so on--apart from the fact that the DDMS perspective never remembers which was the last directory it used, and it also seems to stop working after a couple of coordinates have been sent (!!).

In the video, you can see a replay of a walk around St. James's Park Duck Island, performed by yours truly. And although it took me around 9 minutes, the video lasts only 0:55 because I have set the interval between points to 0.2 seconds.

I initially wrote my own input arguments parsing code, but the next day I discovered argparse and immediately fell in love with it. You probably know about getopt if you have done any sort of argument parsing in C/C++; Argparse feels like the sane version of getopt. It's very easy to 'get', and it allowed me to simplify considerably my code, plus it can even generate an automatic Help message if there's a syntax error in the arguments entered by the user, according to the metadata it already has about the syntax. Totally recommended. An example:

parser.add_argument('--port', type=int, help='Telnet port where the emulator is listening to', default=5554)

The telnet library is also very simple and doesn't get in your way.

I love that once I replaced my messy argument parsing code with the one which uses argparse, the script started to look pleasant. And at ~60 lines, it's not bad for the amount of work it does (and the amount of time it saves too).

Have a look at the script!

It can obviously be improved. I was thinking about pausing/resuming... but since I don't need those features right now, I didn't implement them. It's so basic now that the only way to stop a replay is to press Control+C in the terminal window! And to restart, UP arrow and enter again! :-D