EECS 373 Winter 2007 Project

voiceBot


Ultrasonic Controller

In this hardware device we implemented:

  • A clock divider with low duty cycle
  • An edge detector

The clock divider was able to be adjusted such that once started it would provide the regular init pulse we need to send to the sensor to request data. We figured this would generate a reliable pulse signal without lots of complicated hardware / software.

The edge detector was used to set an edge triggered interrupt whenever we hit a rising or falling edge of the return pulse signal. Additionally, information was latched in flip-flops on whether this was a rising or falling edge. This way the software could determine with a quick read of the flip-flops if the pulse was starting or ending.

LCD Bus Controller

In this hardware device we implemented:

  • A bi-directional data bus from the processor to the display microcontroller
  • The hardware to translate from MPC bus commands to something for the display's microcontroller

Based on whether or not we were doing a read or a write on the processors bus we were able to appropriately change the direction of the LCD's data bus to either accept or supply data. This was extremely useful for finding out if the micro controller was busy and couldn't accept our commands.

In order to meet the setup and hold times of the LCD micro controller we had to use a large shift register to make signals start and persist for the proper time. We also had to latch in a lot of the data from the processors bus as we found it minimized glitching – even when TA was being delayed the appropriate amount.

Parallel Port Controller

In this hardware device we implemented

  • A single directional data bus from the I/O board to the laptop's parallel port
  • Provided external circuitry that translated the high or low outputs into a signal that was either floating or grounded (safest way to communicate with the parallel port).

The actual data path here isn't very complicated. We decode the address and latch the data into the bus. One of the four bit lines is a dedicated command line that must be asserted high during a transaction, and asserted low in between transactions. The laptop then looks for this transition from the zero state to a data state and issues the appropriate command to festival – our text to speech application.


We considered implementing an error correction scheme on this bus, but couldn't justify the additional complication with the time we had remaining and the high level of accuracy we get without it.

The external circuitry is necessary to protect the laptop. The parallel port is not capable of sinking very much input current. Because of this, with one mistake it could be quite easy to damage the computers circuitry. Overall, it is better to sink the computer supplied current to ground, which we are doing through the transistor/resistor combination.

Analog Filtering Circuitry

As noted before, we used a series of analog filtering techniques to reduce the voice recognition data that the computer needed to process. The voice signal from the microphone went through a three-stage amplifier, and then through two different bandpass filters. These filters were designed to be centered around F1 and F2, two of the three dominate frequency ranges that human voice occurs in. Finally, the circuitry uses two comparator op-amps to generate a square wave of zero crossings for both F1 and F2.

Voice Recognition Controller

The hardware here is simply two memory-mapped 16-bit counters. The clock signal of each counter is driven by one of the square waves our analog filtering circuitry generates. This allows us a simple method of counting the zero crossings. A single read from the address here provides both values. We also implemented a method by which to clear the counters with a bus transaction.


Created by Terry Dolan & Gary Wong