By using the built in hardware UART to communicate with Hyperterm on a PC we have tested our project to transmit text at up to 38.4 kbps. At this rate it is entirely error free. The system can likely transmit much faster, but for text applications anything faster is overkill.
We can send arbitrary data at a rate of up to 27.7 kbps. Although we could not pin point the exact reason why the reliability of our audio transmission fell drastically at bauds higher than 27.7 kbps, we do suspect that is has something to do with a timing problem involving the time required by the ADC to complete a conversion since the biggest difference between the audio code and the text code is that the audio utilizes the ADC and transmits continuously. We did not have sufficient time to test this hypothesis, but as we did have the ADC clock turned up as fast as it could go (125 kHz) we do not believe there would have been much we could do about this problem anyway. In the end, 27.7 kbps is plenty fast enough to transmit our voltage values if the sampling rate is 3 kHz. So ultimately the baud limitation did not degrade the quality of the transmitted audio.
On the other hand we were somewhat surprised by exactly just how poor the 8-bit audio sampled at 3 kHz sounded (even though we knew it would not be great). Even after some liberal low pass filtering the audio was still of poor quality. One definitely would not be able to hear a pin drop over this line.
The Next Go Round
Another thing we would have done differently would be to implement a full duplex software UART in order to establish a 2-way link. This would require the UART to both receive and transmit simultaneously and would likely involve some clever use of interrupts. Because our budget and the availability of only one collimating lens only allowed us to build a 1-way link in the first place we did not pursue the full duplex software UART idea. (Note that we could have implemented a 2-way link using the Mega32 hardware UART which is full duplex, so the decision to make a 1-way link was purely because of a budget and supply limitation.)
One wish we have that would not require new hardware would be to spend more time optimizing the use of the 8 bits of information we do have. As of now only about 4 or 5 bits are effectively being used with the microphone gain settings as they are. If we were to use closer to 8 bits the audio quality would improve noticeably (for a while we were only using 3 or 4 bits and were able to improve it slightly by fiddling with the gain resistors in the microphone circuit). This is a problem which just involves time spent fiddling around with values to get the bit usage just right and would be especially important to do in order to gain anything if 10 bits were used instead of 8.
Interference, Safety and Usability
Having people walk through the beam brings up another point: safety. We did our best to emphasize the dangers to everyone in the room at the time (with the help of Prof. Land) to be sure no one accidentally looked into the laser beam of any of its reflections. Laser light can be very harmful to the eye if shined directly into it and so we had to be very careful with this aspect of our system.
The most difficult thing to master about the usability of our system was aiming the laser diode at the photodiode on the receiver. Once the laser was aimed and appropriately focused the use of our system was fairly straightforward: talk into the microphone and listen at the other end.
Intellectual Property Considerations