The Klog: Walk Logging, Linux Style

If a Blog is a “Web Log” then a “Walk Log” must be a Klog…

The Long Walk this year will run from Bude to Lands End. A distance of around 130 miles up and down one of the most rugged coastlines in Britain. Ten of us, assisted by our trusty support team, hope to walk it in only eight days.

That’s no mean feat, and I want conclusive evidence that we did it: Every mile we walk, our route, the photos we take and the videos we make along the way, I want all these details available to the world on Logical Genetics. Forever. I want to bore my Grandkids with tedious Google Earth slideshows of my epic journey every Christmas afternoon.

Anyway, this was clearly a job for a GPS module and the trusty Gumstix embedded Linux platform I ordered way back in 2005. Development wise, the project has tested my knowledge of every level of software (and hardware) development: Soldering parts together, debugging them with Richard’s oscilloscope, writing Linux device drivers, writing C++ applications to read GPS data and log it to anSqlite relational database on the Gumstix, writing code to transform the logged data to KML (Google Earth’s XML map format), writing Javascript applications to display the data in Google Maps and a whole load more.

This article gives a brief introduction to the project. I hope you like it. If you have any comments or questions then feel free to mail me: dan@logicalgenetics.com.

Components of a Klog

The basic components of the Klog are the Gumstix, GPS Module and a flashy customer reassurance LED which lets the user know everything’s working as it should. I’ve played around with a tiny mobile phone screen and jogwheel/pushbutton interface too, but since they don’t work at the moment I’m not going to talk any more about them.

Klog hardware
Figure 1: Klog hardware

The Gumstix is a Linux computer the size of a stick of chewing gum (see photo). The development environment is 100% free and support is readily available on the website and via an extremely active mailing list. I have a Gumstix Basix 400MHz with a 128Mb MMC card and a Waysmall breakout board. Pretty basic hardware which costs less than £100 to buy.

The Gumstix
Figure 2: The Gumstix

A Lassen IQ GPS module from Sparkfun Electronics is linked to the gumstix via a two wire (i.e. no handshaking) serial port. It uses the same Vcc voltage as the Gumstix, so integration is as simple as soldering 4 wires (Vcc, GND, RX and TX). The only hard part was mounting the tiny surface mount connector on a suitable PCB. I press ganged my good friend Richard into soldering the connector to a scrap board from work (he’s better at it than me) and ran wires off that to the Gumstix.

Note that a 10p coin is roughly the size of a US quarter.  The Lassen IQ is small!
Figure 3: Note that a 10p coin is roughly the size of a US quarter. The Lassen IQ is small!

Once I was happy that all the hardware worked I shoved everything into a project box I found in the cupboard. Things to note in the picture include: Larger voltage regulator and heatsink installed (the backlight in the little screen I’ve been playing with made the old regulator far too hot), rechargeable AA batteries (last about 12 hours), GPS unit, Gumstix, miles of annoying ribbon cable and tonnes of wasted space.

If I could have made a PCB for the project it’d have fit in a much smaller box but time and money constraints prevented anything that professional.

The Klog laid out on the bench during development
Figure 4: The Klog laid out on the bench during development

In a box, screen and jogwheel removed for the long walk
Figure 5: In a box, screen and jogwheel removed for the long walk

Closeup of the three colour LED, for which I wrote a very noddy driver
Figure 6: Closeup of the three colour LED, for which I wrote a very noddy driver

An external GPS antenna is plugged into the Klog so it can be used in a car, on my bike or in my backpack when I go walking. Holes are drilled in the box for the USB connector and external power supply. I generally cover the holes with tape when out-and-about in case it rains.

I’ve given enough detail of the hardware on this page, so on the next page I’ll give some details of how all the software works and show some screenshots of the various interfaces.

Software in a Klog

Figure 1 shows how the various software components interact within the Klog. Each component is explained in more detail below.

Software interaction within the Klog
Figure 1: Software interaction within the Klog

gpsd

gpsd is a third party application which reads NMEA data from a GPS unit, via a serial port, and makes that data available to any number of client applications via TCP/IP connections. This means that more than one application can monitor GPS information without any contention over serial port access. gpsd has been integrated into the Gumstix buildroot, so it’s very easy to install.

gpslogger

The GPS logging application is one of two main applications written as part of this project. The logger connects to gpsd, using the handy gpsd C libraries, and stores position data to an SQLite database. The logger is also responsible for updating the system clock using time information from the GPS module.

SQLite 3 Database

SQLite is a very nice relational database engine for embedded platforms which provides many of the most important features of a fully fledged database management system with only a fraction of the overhead. Connections to an SQLite database can only be made from the local machine (i.e. no network protocol exists). This is fine for the Klog project, where the key features I’m looking for are safe concurrent access and simple sorting and searching of data.

The gpslogger application connects to the database file and stores data on position, heading, speed and satellite usage. This data is then read by various output applications for translation to KML and suchlike. SQLite provides a mechanism for safe concurrent access for these programs.

CGI Applications

Data is output from the Klog via a USB network and embedded boa webserver. A simple CGI program have been developed to translate database data to KML. The CGI also partitions the data into ten minute long “chunks” to make it easier to browse in Google Earth (see below).

Watchdog

The PXA255 processor used in the Gumstix has a built in watchdog timer which forces a hard reset should the operating system crash. A simple linux driver exists which exposes the watchdog functionality to userspace programs. Once the module is installed the /dev/watchdog file must be written to at least once a minute. If nothing is written to /dev/watchdog then the Gumstix will reset.

I wrote a very simple shell script to “tickle” the watchdog every 30 seconds, provided the gpslogger application is still running. So if the gpslogger crashes the Klog will reset and hopefully everything will run OK after it boots up again.

#!/bin/sh

while [ 1 ]
do
if [ -d /proc/`cat /var/run/gpslogger.pid` ]
then
echo
else
exit
fi

sleep 30
done

LED Driver

Since the Klog is a passive logging device in a black box, I thought it’d be handy to have some indication that everything is working, that nothing’s crashed and that the batteries don’t need changing.

To provide a limited amount of feedback I attached a three colour LED to three of the Gumstix’s GPIO lines and wrote a very simple device driver. The LED flashes in various colours every second or so.

In future I’d like to extend the device driver to encode system information, so a green flash implies power is present, a red flash implies that the GPS unit has a fix, a blue flash implies that the USB cable is connected and so on.

Google Earth and KML

KML is an XML format which is used for presenting data in Google Earth. GE supports two types of KML, standard KML which is text based and KMZ which is simply zipped KML. The following code snippet shows a very simple KML file with one folder named “Chequers Walk”, containing two placemarks. The first placemark is a simple “pin in the map” and the second contains route data recorded using the Klog. Click here to view this KML file in Google Earth.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.0">
<Folder>
<name>Chequers Walk</name>

<Placemark>
<name>Chequers</name>
<description>The PM's House</description>
<LookAt>
<longitude>-0.7816837753264748</longitude>
<latitude>51.74451081245437</latitude>
<range>1300</range>
<tilt>45</tilt>
<heading>0</heading>
</LookAt>
<Point>
<coordinates>-0.782170516814631,51.74329567582883,0</coordinates>
</Point>
</Placemark>

<Placemark>
<name>Route</name>
<description>Our route</description>
<LookAt>
<longitude>-0.7821428775787354</longitude>
<latitude>51.74325364082546</latitude>
<range>3000</range>
<tilt>45</tilt>
<heading>0</heading>
</LookAt>
<Style>
<LineStyle>
<color>ff00ffff</color>
<width>2</width>
</LineStyle>
<PolyStyle>
<color>7f00ff00</color>
</PolyStyle>
</Style>
<LineString>
<altitudeMode>clampedToGround</altitudeMode>
<coordinates>
-0.7898370000000001,51.75267300000001,0

...snip...

-0.8204900000000001,51.44644200000001,0
</coordinates>
</LineString>
</Placemark>

</Folder>
</kml>

KML is an open standard, details of which can be found here. So it’s very simple to create applications which output KML which can be displayed in Google Earth.

A CGI application on the Klog reads route data from the sqlite database and outputs it as KML, chopping the route into ten minute sections which are organised into daily and hourly folders. A network link to the CGI can be set up in Google Earth, so each time the Klog is plugged into a computer the route data is automatically updated.

It’s possible to do all kinds of interesting things with KML. One that I like quite a lot is to plot the route as a wall, using speed to determine the height of the wall. Figure 2 shows the results (a full size screenshot can be seen here).

Route data plotted as a wall, where height is proportional to speed
Figure 2: Route data plotted as a wall, where height is proportional to speed

On the walk we won’t have access to a fast internet connection so it’s lucky that Google Earth is able to function without access to the net. By setting the maximum size of GE’s cache to 2Gb it’s possible to save a heck of a lot of data for use offline. The only annoying thing is that you need to know where you’re going, so you can scroll round the area at various zoom levels before you set off.

Google Maps and Javascript

Google Maps is another mapping application from Google. The API for Google maps is free, so it’s another handy tool for displaying route information, especially on a webpage.

Google Earth and KML were not developed from scratch by Google, it was first developed by another company who were bought by Google. The upshot of this is that Google Maps does not support KML. This is incredibly annoying and lead to many hard days of Javascript work to read KML files and display them on Google Maps. I managed it in the end though; figure 3 (a full size version of which can be found here) shows my route to Green Park on my bike.

Klog route data displayed using Google Maps
Figure 3: Klog route data displayed using Google Maps

Output in Google Maps isn’t as impressive looking as output in Google earth, but it does allow better integration into websites, so I’ll be extending my Google Maps code to link pictures, sound recordings and video from the walk to a map on this website. Of course, I can’t do that until the walk’s over, so I can’t say much more about it in this article.

GPSD Client

Since GPSD allows multiple connections via TCP/IP I thought it’d be fun to write a windows application to display live GPS data via the USB network. While we drive to Cornwall in the minibus it might be fun to watch the movements of the satellites overhead and our changes in heading, speed and altitude as they happen.

The application is written in Delphi. I’ve used Delphi professionally for many years, so I’m able use it to create Windows applications very quickly, especially where there’s lots of graphical output to do. At the moment I’m trying to get a grip of C# and Visual Studio, so were I to start the project again today I might not have used Delphi.

Anyway, figure 4 (click here for full size version) shows the GPSD Client GUI. Note the cool heading and satellite display components (written as part of this project) which spin as heading changes and the speedometer and altitude graph. There’s also a simple map of the UK, which uses the Proj library and vmap0 data.

Windows GPSD Client shows heading, speed, position and active satellites
Figure 4: Windows GPSD Client shows heading, speed, position and active satellites

There are a few more bugs to fix and features to add to the GPSD client. When those are done I’ll hopefully be able to release it here for others to have a play with.

The End?

Less than two weeks to go before the walk now. Hopefully the Klog will cope with eight days of field testing. Once the walk is over I’m sure there’ll be loads of features I’ll want to add to the Klog. Hopefully I’ll also have time to finish my work with the jogwheel and LCD screen.

One things for sure, I’ll be putting all the data I record on the website and writing about the experiences I have on the forums.

More details of my adventures with the Gumstix can be found in the Gumstix Snippets section of the forums.

Leave a Reply

Your email address will not be published. Required fields are marked *