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.
This makes me feel very happy:
Breakpoint 1, sd_state_run (in_byte=201 '', ob=0x272 "z\002\223")
at sd.c:366
366 r_received = FALSE;
(gdb) print r_err
$1 = FALSE
(gdb) print/x csd
$3 = {0xaa, 0x55, 0x0, 0x0, 0x0}
(gdb)
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.
This work is licensed under a
Creative Commons Attribution-Share Alike 3.0 License.
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:
Horizontal axis is seconds. Vertical axis is reading – in ADC counts (out of 4096).
Hmmm. Two identical situations, and no idea about why one’s different to the other… I know, I’ll take a dump of SFRs in both and then diff the result…
I just changed the buffer that the Gumsense firmware uses to store data to be circular. This means that it can continue sampling whilst data is being read out of it. So, no “lost” data.
When the Gumstix requests that the Gumsense clears all the current readings, it now clears only the ones that the Gumstix has read out.
I know I said that I’d finished. I found a bug in the code for reading data out of the Gumsense. I’ve fixed that now. I thought whilst I was at it I’d scratch this itch.
I wrote most of this blog entry about a week ago.
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…
I’ve reached a point where I’m reasonably happy with the current Gumsense situation. However, there are still improvements I’d like to make…
I’ve finished writing and debugging the Tcl library for the gumsense! w00t.
I had to tweak the Tcl buildroot scripts so that it got installed correctly (now in git repository), and now one can type package require gumsense and it works (if you modify the load path correctly).
I spent the first half of today learning Tcl. Then I started writing a gumsense extension for it:
load ./libgumsense.so gumsense::open puts "The time is [gumsense::read_time]" gumsense::set_time 3 puts "The time is [gumsense::read_time]"
(NB: I’m experiencing problems with making it a package at the moment because the gumstix buildroot doesn’t install everything (I think) it should – wasn’t a priority.)
Output:
# ./test.tcl The time is 1176423144 The time is 3 #
So now I just have to spend a few hours wrapping Tcl around the C library, and I’ll have got somewhere…
| Older Posts >> |
Site by Rob Gilton. © 2008 - 2019