Our project can be divided up
into four separate segments: first receive two simultaneous analog inputs
from the user, convert the input into a transmission byte containing the
speed and magnitude for both the left and right motors and send wirelessly,
receive and parse the transmission byte, and finally produce the signals
necessary for the motors to operate properly. There were many places to
introduce one or more errors into our project, so we set about working on
our hovercraft in a very systematic way.
Our first goal was to get the MEGA 163 microcontrollers to communicate with
each other. To accomplish this goal we placed each MEGA 163 in its own Atmel
STK 500 development board and hooked each one together using a null modem.
We were able to tell what was being sent and received via the LEDs on each
development board. We used the MEGA 163’s UART protocol with built-in error
checking to send and receive the data.
The UART protocol sends and receives a 10-bit packet, of which only 8-bits
can be used for the actual data. The first and the last bits are the start
and stop bits, respectively. After a 10-bit packet is sent, the receiving
MCU samples the receiving pin at a frequency of 16 times the baud rate,
which for our null modem connection was 2400. While the receive line is
idle, one single sample of logic “0” will be interpreted as the falling edge
of a start bit and a start bit detection sequence is initiated. When the
1-to-0 transmission possibly indicating the start bit is received, 10
separate samples of this bit are taken. The receiver compares samples 1, 8,
9, and 10 to one another. If sample 1 is 0 (since this is what indicates the
start of a sequence) and if any two out of the last three samples are also
0, it is determined to be a valid start bit, and the same sampling procedure
is performed for the next 9-bits in the transmission packet. However, if any
two out of the last three samples are not the same as sample 1, which for
the start bit is 0, the start bit is rejected as noise and the receiver
begins searching for the next 1-to-0 transmission. This error checking
turned out to provide very accurate signals once our wireless communication,
along with subsequent noise, was established.
Once our group had the MEGA 163’s communicating with each other, our next
goal was to move to wireless communication. Our group realized this goal by
the use of a transmitter and receiver obtained from Abacom Technologies. The
transmitter and receiver operated at 433 Mhz and provided a very effective
wireless communication solution. The transition to wireless was relatively
straightforward, as the transmitter and receiver, in effect, act like a
normal wire. We did have one problem however: when our group first hooked up
the transmitter and receiver, we were transmitting the data without any
problem, yet we were receiving complete garbage.
Originally our group sent a data packet once every 40 ms. This is well below
the maximum transmission and reception abilities of the MEGA 163. Therefore,
there was quite a bit of “idle time” for the MEGA 163 in which it would
output a logic low signal. As mentioned above, the transmitter and receiver
act like a virtual wire and are constantly transmitting and receiving.
Subsequently, the transmitter and receiver were receiving the logic low
signal while the MEGA 163 was waiting to send the next transmission packet,
which was the majority of the time. This in itself would not be a problem,
except that the MEGA 163 turns out to be an active low MCU. Hence, the logic
low signal was actually a “1.” The receiver was not capable of receiving
this high signal for so long, and would sooner or later, drop the signal and
reestablish itself. This was the source of noise. We remedied this situation
by simply cutting the transmission waiting time in half to 20 ms. We have
had good results with this time period.
Now the wireless communication was working, our group shifted our focus to
generating the correct signals to the motors. Because our group wanted our
hovercraft to be analog controlled, we needed a way to vary the speed of
each dc motor. Our original idea was vary the voltages into each motor using
a series of 4-bit digital-to-analog converter built around 10 and 20 K
resisters. However, upon testing, it turns out that our DACs have too high
an impedance level which ultimately led to a very low voltage and current
into each motor. It was obvious that there was no way around this subtle
problem except to try a totally different approach.
We decided to use the MEGA 163’s built-in pulse width modulation (PWM)
ability to turn the motors on and off at very high, varying frequencies to,
in effect, change the speed of the motors. Because we had two motors that we
had to update simultaneously, we had to use both Output Compare Registers A
and B to keep a separate wave for each motor.
Next, our group worked on how receive an analog input from the user. We
needed a pair of potentiometers to receive the analog input, which we found
in a Playstation2 controller. We measured the voltages outputted by the
potentiometers and used the MEGA 163’s built-in analog-to-digital converter
to convert inputted signal into a binary value.
When this was complete, our group had to determine how to format the input
so that we could send out a one-byte data packet. We decided on the
Our format allows for seven separate speeds for going forward, seven
separate speeds for going reverse, and an off speed, for each engine. Upon
agreeing on the format, our group wrote the corresponding code to construct
and parse the byte as necessary. Also, a debounced pushbutton was added on
the transmitter to turn on and off the hovercraft.
Finally, our group carefully removed all the circuitry in the original
hovercraft and transmitter, measured the voltages and currents to the
motors, and replaced it with our own. The result is an analog-enabled,
remote-controlled hovercraft that supposedly has all of the functions of the original,
plus analog control.