<pre>
Brian Sardo    Vikas Mundada

HOVERCRAFT SUMMARY
</pre>

<p>
To start the project, we needed to find lightweight materials to construct the hull and skirt of the hovercraft.  Researching other models created, we decided to use foamboard/coreboard for the hull.  Mulling over different materials for the skirt (pre-made or not), we settled on the novel idea of using a shower curtain cut into a strip and wrapped around the hull, weighted down by rope so the bottom would not flare out when high pressure air would push it out.
After testing our own fans with different motors, we decided to purchase five fans from Eric at Goldstein Hovercrafts (http://www.gohover.com) at a student-discounted rate.  We embedded three of the fans into the hull to provide lift for the system, and the other two are used as drive fans.  The lift fans are intended to be either fully on or fully off � determined by code.  Instead of being concerned with the mechanics of rudder control turning, we use the drive fans with variable speed controls to handle turns.  To power the system 9.6V rated at 800mAh and 7.2V NiCd rated at 1600mAh batteries were used.  At the end of the project, we found that these batteries only provide sufficient current for a short, five minutes, time.  Each fan, when fully running, need 3A, thus draining the batteries quickly.
Once the base of the hovercraft was constructed, we focused on the controls.  Originally, we planned to control the craft via an RF module; however, since RF has become outdated, we decided to make it computer-controlled.  After substantial research, we decided that we would control the hovercraft through a desktop application that sends data wirelessly to a M68HC12 microprocessor running standalone on the hovercraft. 
<p>	The first step in developing the hovercraft controls was to determine how our PC would send data to the microprocessor.  We found a transceiver product by Abacom Technologies in Ontario, Canada that connected to both our PC and 6812 through an RS-232 interface.  We then found a 60-day trial version of an RS-232 Windows API by MarshallSoft Computing, Inc. that we could use to send bytes to the 6812, specifying which fans to turn on and at what duty cycle.  The desktop application we developed was written in C.  This application allowed the user to turn the lift fans on and off by pressing the "S" and "E" key respectively.  It also allowed the user to control the duty cycle of each of the drive fans by pressing "I", "J", "K", or "L".  Pressing "I" increased the duty cycle of both fans by 20%, thus making the craft move forward at a faster speed, while pressing "K" decreased the duty cycle of both fans by 20%, resulting in the craft moving at a slower speed.  The "J" and "L" keys either increased or decreased the duty cycle of one of the drive fans by 20% in order to control the speed and sharpness of a turn.<br>
<p>	The desktop application sends bytes of data to the 6812 by communicating with the transmitter module connected to the PC�s RS-232 port.  Each byte sent to the transmitter is then wirelessly transmitted to the receiver module attached to the 6812�s RS-232 port.  These bytes are then processed by the 6812 so it can determine which fans to turn on or off and at what duty cycle.  The 6812 program was based around two interrupt subroutines, each of which was used to control the pulse-width of a drive fan.  Since we have a total of 5 fans, 3 for lift and 2 for drive, we have 5 output ports.  We used port T because it is typically associated with the 6812 standard clock module.  Ports PT0, PT2, and PT4 are the output ports for the lift fans, while PT1 and PT3 are the output ports for the right and left drive fans respectively.