Hoot (Wolf Box).

A hardware / software solution for broadcasting and recording sounds in adverse climates.

Spring 2010:
CS 442 - Advanced Programming II - Dr. Joel Henry

A familiar sound for anyone who worked on this project.

What was the project assignment?

For the entirety of the semester in both classes, we worked on a project for the Biology department.Dave Ausband from the Biology department approached Dr. Henry about a piece of hardware with some software that had been designed for his department. The "Wolf Box", as he called it, was meant to broadcast a wolf cry and then record the return sounds of wolves for later analysis by Dave's team. Our goal was either to upgrade the current software and possibly hardware or to completely rewrite the system and upgrade the hardware. We ultimately decided to scrap the existing software and design our own solution from scratch.

One of my responsibilities was to find out what the user didn't like about the old system and how we could improve the system with new requirements and perhaps a whole new solution.

The main problems with the current system were:

Client (Dave) had to bring his laptop out to the field, which could possibly harm his laptop and is heavy to trek very far with.
System had to be powered down before changing out a new mic or speaker.
Speakers were only 35-70 dB and were not nearly loud enough. Client needed more than 90 dB to be able to produce the output he desired.
Data files would sometimes get corrupted. There was no way for the client to know whether the file transfer had completed or was successful and therefore no way to troubleshoot if something goes awry.

The new requirements the client requested:

User doesn't want to carry laptop into field.
The system needs louder speakers and a better mic.
The system should be easy to troubleshoot on or off the field.
The system needs better power consumption. User would like to get 7 days (2 broadcasts and records per day) from 1 battery charge.
User would like system to be as portable and lightweight as possible for placement in the field.
The system needs to be reliable enough to leave in field for a week at a time.
The system needs to be able to broadcast sounds greater than 1 time a day. Ideally, the system could broadcast in 360 degrees at 90-100 dB within 3-5 ft.
The system needs to record for a user specified time immediately after broadcast (default at 2 minutes).
The system should hibernate between broadcast/record sessions.

What did you learn from the project?

Before this class, I had no experience in completing a reasonably large-scale project with a full team. Most of my previous projects had been single person or 2-3 person teams where everyone had a part in design, implementation, and testing. It was very eye-opening to see a product go from the initial vision of the user to a fully implemented, tested, and shipped product. To the best of my knowledge, the Biology department is still using this product and is very pleased with the success of the unit. Dave said that he plans to buy a few more units to use as well, since they are fairly cost effective. We also laid out plans to lower the cost even more by using netbooks rather than the current Linux hardware.

What are you most proud of?

I was amazed that we were able to design, test, and implement this project within the bounds of a semester and still have a highly functioning product before the end of finals week. I'm used to finishing projects in a semester, but having a rather rudimentary prototype as my "final product". Developing a product that not only "meets expectations of functionality", but also considerably "beats" the previous competing solution in such a short time was inspiring. First of all, it showed me how easy it is to use rapid application development design principles with C# in Visual Studio to create a nice "working" prototype to show the user right away. Instantly upon viewing this prototype, the client was confident that we could create this product in the time allotted and that the final deliverable would be clean and user friendly, while providing quality functionality.

What was your role in completing the project?

I was part of the customer requirements team. My job was to gather the requirements from the client, as well as schedule regular meetings with him to approve our progress. Everyone on the development team was required to hand in weekly status updates andhour tracking reports to the project manager (Dr. Henry). As our final deliverable, we were also required to create a professional-gradeUser Manual out of the documents we gathered from the development teams. We also created a medium-fidelity prototype to demonstrate functionality to the client.

Medium-Fidelity Prototype:

What would you do differently next time?

I actually don't have a lot of qualms about this project. Usually, I come to the end of a semester and wish I had spent more time on design, implementation, or testing. However, what our team delivered felt like a finished product that would need very little maintenance in the future. We developed a product that was satisfactory to the user's requirements by performing rigorous testing and design procedures and holding ourselves to a high standard of azero defects methodology. While it is rare to have zero defects in any project, our testing department and developers worked hand in hand to keep our bug list to an absolute minimum throughout the implementation stages.