Meta

The main project that I’m working on this summer is Glacsweb. Glacsweb is run by Kirk Martinez in the Intelligent Agents and Multimedia (IAM) group of the Electronics and Computer Science (ECS) department at the University of Southampton. The Glacsweb project has been running for a few years now, and has previously successfully installed a wireless sensor network into a Norwegian glacier to collect data that’s useful to geographers in helping them understand how glaciers behave. There are a few other people involved; one of whom is the mighty Jeff.

This time around, the Glacsweb team is installing a sensor network in an Icelandic glacier (which I believe is the largest glacier in Europe), and Kirk invited me to be part of the team. This means that I get to spend two weeks of my summer on an Icelandic glacier, and the weeks running up to this developing the hardware for the base station that sits on the surface.

The installation on the glacier consists of two main parts: the base station and the probes. The probes contain the wireless sensors and can detect a number of variables like temperature, pressure, resistivity of the surrounding ice, the orientation of the probe with respect to gravity and the light level. I like to describe the probes as “large tic-tacs”, as they’re white plastic cylinders with rounded ends. These probes are installed close to the rock that the glacier sits on by dropping them down holes that we’ll be drilling with hot water. The probes will be in a relatively high pressure environment (initially, the probes will be under about 30 metres of water) so the probe casing needs to be strong enough to withstand these forces. Previous incarnations of the probes have been tested in the high-pressure chamber at the University of Southampton
Oceanography centre, and the casing hasn’t changed since then – so we should be safe without this test this time around.

The probes communicate over an FM radio system at 170 MHz with the base station that will be fixed on top of the glacier. The base station’s brain is a Gumstix, and this co-ordinates the data acquisition, storage and remote access. The station communicates with servers in Southampton via a GPRS connection and records its position on the glacier using a differential GPS system.

Perhaps the most exciting bit of the project for me is that the Gumstix is plugged into the result of my third year project, the Gumsense. The Gumsense provides facilities for the Gumstix to be powered up at times that an be configured from the Gumstix (unfortunately, there’s no record of anyone successfully getting a Gumstix in and out of sleep – and even if this was possible, the power required by the Gumstix RAM to self-refresh is fairly high at something like 25mW).

For the past few weeks, I’ve been bringing the Gumsense software up to date – both updating it based on the experiences I’ve had over the last year (since my third year project ended) and also introducing the new features that we need for the project.

The part that’s been the most interesting so far is migrating from Buildroot to OpenEmbedded. Gumstix started using OpenEmbedded sometime over the last year. My initial experiences of it have been very good. So good in fact, that I’m now on a quest to move the Student Robotics slugs (a.k.a. nslu2) over to OpenEmbedded — but more on that later.

r_err is a variable which states whether the SD card reported an error in its response to the read command. The csd array stores 5 of the bytes read from the SD card. The byte ordering is the wrong way around, but other than that it’s all fine.

After spending several millennia attempting to discover what was causing my MSP430 to reset randomly, I realised that it was because I hadn’t got any RAM left. I think that the bss/text sections began to overlap with the stack – which wasn’t pretty! I had previously been attempting to store 64 bytes of data read from the SD card in an array. This meant that there were 114 bytes of the 128 bytes of memory in use, leaving only 14 bytes for the stack.

Reducing this array to 5 bytes (I’m not that interested in buffering more than 1 byte from the SD card) solved all problems. Now I can read data! w00t.

Jeff and Steve suggested that I put my third year project report up. Get it here. I’ve also put up the contents of the accompanying CD.

I’m now doing a summer internship at Uni working with Klaus as my supervisor (he supervised my project). My internship is highly related to my third year project – it’s a sort of continuation of my project, but without the absolute necessity of getting it all done!

The abstract:

Developments in wireless sensor networks (WSNs) are strongly focused on minimizing the power requirements of sensor nodes. As sensors with significantly large resource requirements are introduced into WSN systems, algorithms must be developed to maximise the information returned per sensor reading. The integration of “lab on a chip” sensors into WSNs widens the focus from power reduction to the reduction of sensor usage, since the limited reagent resources available to such nodes will limit node lifetime.

This project builds upon the prototype Gumsense sensor node to create a platform that is suitable for the development and deployment of WSNs that incorporate “autonomous experimentation” algorithms. Substantial changes are made to the architecture of the Gumsense hardware platform in pursuit of this new philosophy. The platform is upgraded so that data can be sampled whilst remaining in a low power sleep state to minimise resource usage. C and Tcl libraries are developed to enable the rapid development of algorithms for the new Gumsense.

For my project viva I need to do a demo of the Gumsense. I’ve set it up to log readings at 1 second intervals from a potentiometer which I shall twiddle around. It sends them over wireless to my laptop, which sticks them in a mysql database using a php script. A mod_python script then uses matplotlib to plot them:

When something on the Gumstix starts the sequence of events that should eventually lead to the gumstix being turned off, the Gumstix needs to send a message to the Gumsense telling it to terminate its power. Investigation follows…