Introduction to the project

The idea

Our project involved the design and creation of a zoological animal tracking system. Using a speculative architecture, a system was designed in which the conditions (including temperature, proximity to each other and kinetic energy) could be observed, recorded, moved around, downloaded, transferred and displayed for human or computational analysis.
Using the ProSpeckz II architecture[1] which utilises a programmable system on chip[2] two different varieties of 'speck' were produced. The first of these is referred to as an 'animal speck' whose purpose was to take readings of the animal as required (approximately every minute). This speck would then be capable of communicating with other specks to transfer the data around until it comes to a 'basestation speck'. These specks are created with longetivity in mind and one can easily imagine them as having hard connections to each other (rather than relying upon the radio communications system of the ProSpeckz). It would then be a matter of uploading the received data to a PC, where upon it can be recorded and analysed or viewed upon request locally or even across the world wide web.
This project has similarities to the ZebraNET project[3] being run at Princeton University. However, the project that we are undertaking is a great deal smaller. It attempts to compensate for this lack of complex/expensive technology by using algorithmic solutions (for example, we have a smaller battery and must compensate by powercycling whenever we wish to take a reading).

The aims

Obviously the aim of the project is to gather as much data on the animals being observed as is possible. The entire process should be as lossless as possible, to improve the possibility of meaningful connections or relationships being established between the pieces of data. However, it should also be able to keep the data as compact as possible (which performing a minimal amount of processing) so as to elongate storage space and also battery life[4]

The significance

Zoological research is extremely widespread. However, there is at least one journal[5] which specialises in publications on environmental adaptations and behaviour of animals. This project would allow a team of zoologists to monitor the interactions of animals (since their proximity with each other is recorded) as well as their adaptation to the environment itself (eg: where the animal goes when the temperature is hot, where it goes to drink and how often, does it travel with other animals, etc.).

How we split the project up

The project was split up by writing a set of requirements and aims for the system. We were then able to determine a set of use cases that were required to produce the system. Once this had been done, we used the process of noun identication to work out the classes of our system.
It was then a simple case of dividing the various parts of the system up. Those of us with electrical expertise focused on the hardware aspect of things (obviously) and the rest of the tasks were divided equally among the team, trying to ensure that everyone did some work with the specks and that people did work in the areas that they were particularly good at.
Integration (putting the parts together) was considered to be the job of everyone in the team.

Introduction to the report

What I will discuss

My report gives an extended explanation to the parts of the system that I contributed. Including why they were necessary, what they achieved, what the alternatives were and why I made the decisions I made. To understand the context that these contributions were used in, I have provided a summary of the way in which other aspects of the system interacted with these contributions. In these parts of the report, a link is provided (where possible) to a section of the contributor's report where more information can be found.

My contribution

My contributions to the project were as follows:

• PC Hookup and data analysis: I produced a system in which the transfer of data could take place from the speck to a PC. This system then inputs the data in to a database and offers the user the ability to produce any number of graphs based on what data they wish to view.
• Code optimisation: The compiler used in development was somewhat substandard, and a number of possible optimisation tricks in the production of the assembly code were missed. I produced an analysis of the compiler's standard efficiency as well as an optimiser in Java to attempt to improve this.
• Time synchronisation prototype: I have produced a prototype of a time synchronisation system. This would allow a number of specks in a network to synchronise themselves to a real time (as transmitted through the network) and to help determine which real time value to use, given multiple choices.

Analysis of results

Analysis of hookup and data analysis

The PC hookup and data analysis system went particularly well. I successfully managed to produce a system which is reusable. Despite any technical knowledge in the field of zoology, the system will also allow a real zoologist to produce graphs or data to a sufficient degree that the data can be analysed and relationships or correlations determined. Since this was the real aim of our project, I can only conclude that this was a great success.

Analysis of optimiser

The optimiser worked well, especially given that its requirement was not realised at the offset of the project. There are some areas in which a better (but longer and more complex approach) would have been more successful, but given the short predicted lifespan of such a tool (as well as our own time restrictions) this was deemed an inefficient use of time. It is impossible to determine how useful the optimiser has been, since old versions of the code that was improved no longer exist. As people got used to the coding styles that were deemed inefficient, it also had less and less of an impact. Still, it managed to save some resources and at the very least helped us to avoid going over the RAM restrictions of the architecture (which was nearly done on many occasions).

Analysis of time synchronisation

Simultations of the time synchronisation system, have demonstrated that the system does indeed manage to keep its accuracy across a long period of time (certainly longer than the batteries for the specks would last). There is little further work that can be done in this area, besides possibly building some sort of system to minimise on the exchanging of data between the specks or more accurately calculating the worst case transmission time between them.

Evaluation of project as a whole

Our project was a resounding success at the demonstration to the SpeckNET consortium and also the SLIP group as a whole. Every aspect of our system worked, and there is no reason (given production time) that this could not be expanded in to a fully operational and working system.

Bibliography

[1] ProSpeckz III - Steven Wong and Martin Ling in the 2nd workshop of the SpeckNET consortium (2nd-3rd September, 2004).
[2] http://www.embeddedstar.com/press/content/2003/10/embedded10838.html
[3] The Princeton ZebraNET Project - Professor Margaret Martonosi at the Delay Tolerant Networking workshop (8th May, 2003).
[4] Energy issues in SpeckNETs - High Leather in the 2nd workshop of the SpeckNET consortium (2nd-3rd September, 2004).
[5] http://link.springer.de/link/service/journals/00435/index.htm