Foreword: Every project and dissertation is unique and it was not without flaw that I carried out my project and dissertation. Therefore this post is not a comprehensive guide, but serves as something to compare against and highlights some difficulties that may occur. This post is currently incomplete: I will continue updating it until it is complete, but I have published what is reasonably finished so far as it may be of use to people currently studying Part II of the Computer Science Tripos.
It was about this time last year that I headed back to Cambridge early (term generally starts around the start of October) to come up with, and do some research on, ideas for what my dissertation should be on. It’s great fun being in, and having the resources of, Cambridge while being required to think without limits (though perhaps this is simply because of the nature of computer science: a discipline focused on rules more than creativity). Over the course of a few days I came up with about 4 specific areas of interest. For each area of interest I came up with one or more specific project ideas, each of which I thought could be reasonably stabbed at in the time frame (my director of studies later explained that, as lectures and supervisions go on as normal in parallel, we effectively had up to about 5 weeks to design, implement and evaluate the project before we needed to start our dissertations on it).
Next, still well before term started, I started contacting potential supervisors in my favourite area of interest with my potential ideas in that area. To find suitable supervisors I both searched online and sent emails to the most suitable supervisors I had already been supervised by. As I was trying to briefly summarise a number of similar ideas in a single email, I gave each idea a name.
The name I gave to the idea that I ended up pursuing also became the title for my dissertation: “Location-based messaging on phones”. It would have been nice to revise it a bit to include a reference to the audio networking technology involved, but there was never a huge need to change it as it describes the high-level application developed accurately. Indeed, I made the application loosely-coupled enough for other communication mechanisms to work and adhered to standard networking techniques and terminology (symbols, channels, etc.).
Email is relatively asynchronous so, in parallel, I started familiarising myself with the necessary APIs and libraries. This, for me, involved making a basic Android application, researching the algorithms needed to implement the ideas and investigating the complexity and availability of implementations of these algorithms. Once it was becoming clearer which idea had the most traction, I started writing my first serious code to investigate the feasibility of the different options within the idea (particularly how good mobile devices are at playing and recording near-ultrasound frequencies). This early work also gave me an idea of the range and accuracy possible, highlighted the heavy CPU load caused on the mobile devices by the signal processing and also highlighted the need to play to the strengths of the audio hardware (frequencies in the telephony voice band).
Term arrived. I bounced my full range of areas and ideas off my director of studies who was able to kill some off (problems included ideas too ambitious for the time available – a problem that most people seemed to suffer from). Lectures and supervisions had a significant impact on my progress but I fleshed out the details and timetable for the project, made sure my supervisor, director of studies and overseers were happy with them, and submitted the formal project proposal. At the same time I started designing the final application – this involved actually writing the code that interacts with the audio hardware of Android devices several times as the range of APIs are not particularly good (Android suffers from considerable latency between applications and the audio hardware, hence the lack of good audio-related applications compared to operating systems such as iOS), they are not brilliantly documented and their documentation is not particularly accurate or reliable.
The majority of the development will not particularly interesting to others, so it is omitted. The dissertation, which can be found in the University of Cambridge Computer Laboratory’s Library contains the gory details. Noteworthy problems encountered included the drowning out of the incoming signal by the outgoing signal during full duplex communication (and the computational intensity and imperfection of acoustic echo cancellation algorithms – especially on limited hardware), hiccups caused by the garbage collector on slower devices and more.
Throughout development I kept a log of what I did each day. This was advised by the department to make the dissertation writing process easier. In reality, I didn’t refer to the log too much when writing the dissertation as the word limit made it difficult to include too much detail. However, I did find the log useful during development as it helped me to keep track of what I was doing on several levels at once – it is easy to get caught up in little details for too long and forget other parts of the project.
To be continued with information on the evaluation process, presentations, supervisions and writing the dissertation itself…