Software details Hardware details


High Level Design

Program/Hardware Design


Software Design
(Or: States of Confusion)

The bulk of our software design is centered around several state machines. Chief among these is, appropriately, the Main State Machine. The main state machine decides, using the primitive ones and zeros that pass for its consciousness, what part of the system to run. Choices include the Main Menu, Taking Sample, Entering High Score, and the High Scores List. Except for the main menu, these states each have their own state machines, and they are handled by the Main State Machine in the following goony manner:

void MainStateMachine(void)
// et cetera et cetera ...
case TakingSample:
// ... et cetera et cetera

Main State Machine Diagram

If the user starts blowing into the mouthpiece at the Main Menu, then the Taking Sample state machine comes into effect. The Taking Sample state machine does a variety of things, including measuring the alcohol content of the user’s breath at 512 millisecond intervals for 5.1 seconds (at which point the user has probably been out of breath for at least one second), determining the validity of the sample, and playing cheesy tunes and lighting LEDs. Unfortunately, we must require such a lengthy breath sample, because the TGS 2620’s response is very slow. As such it’s occasionally necessary to take more than one sample to get a good reading. By that time though, the ADD-plagued intoxee has probably wandered off to stare at something else, so we figure it’s not too big a deal.

The Taking Sample state machine also determines the stability of the sample. If the sample fails to stabilize after six seconds, it is declared to be bad, and the user’s readings are rejected. Bad readings are possible if the user has a high BAC and the sensor takes too long to reach its maximum value, or if the user does not blow consistently into the mouthpiece (such as if they asphyxiate in the middle of the sample taking process). Note that, even if the user is not intoxicated, the amount of breathing effort required to get a good sample with the Breath-o-Matic can sufficiently deprive the user’s brain of oxygen such that the user feels intoxicated anyway! Party on!

Taking Sample State Machine Diagram

If the user’s average BAC is sufficiently high to make the high score list (or else there are fewer than 10 high scores on record), the processor heaves itself into the Enter High Score state machine. This state machine takes keyboard input with the aid of the Mega32’s USART. We didn’t really feel like doing weird mathematics and register assignments and nonsense like that to synchronize with the keyboard’s internal clock, so we just jammed the keyboard’s clock wire onto the Mega32’s XCK pin. In this way, the USART can synchronize itself with the keyboard clock, and we’re left in blissful ignorance of such trivialities as the clock’s period (which happens to be around 80 microseconds). We did however have to decode the keyboard’s character codes, which, fiendishly, bear no resemblance to ASCII. We did this with the help of Adam Chapweske’s splendertastic web site, “PS/2 Mouse/Keyboard Protocol” (see the appendix for details).

The High Score List state machine isn’t really a state machine, but we call it one for consistency’s sake. It cycles through the current high scores, and its “state” is really just the high score number that it’s currently showing. That is, if high score #6 is currently showing on the LCD, then High Score List’s state number will be 6. If you were hoping for some sort of cryptic elegance, then I am afraid that this state machine will only disappoint.

Enter High Score State Machine Diagram

All of these states blend together in the final produce to form a delicious, frothy, nourishing product, blended with only the finest Columbian coffee beans, spiced to perfection, and topped with a generous helping of whipped cream. $4.78 plus tax. Thank you, and have a nice day.

Hardware Design
(Or: What went into the Breath-o-Matic, besides your tuna breath)

The heart of our design is the TGS 2620 Solvent Vapor detector from Figaro Electronics, Inc. The TGS 2620 is capable of detecting ethanol gas, and thus makes an ideal sensor for breath-alcohol detection. The TGS 2620 also responds to several other gases, including methane and carbon monoxide, but we’re banking on the fact that these chemicals are not often found in living humans’ breath. The brain of the Breath-o-Matic is an Atmel Mega32 microprocessor, which has more than enough processing power, and barely enough ports to handle all of the junk that we crammed into the project. Sadly, despite the presence of a heart and brain, our limited budget meant that we were unable to afford a soul. As a result, the Breath-o-Matic is intrinsically evil. Luckily for consumers, it’s also inanimate!

We use a Motorola MPX 2052D differential pressure sensor to detect when the user is breathing into the Breath-o-Matic. This sensor was working very well until it broke (probably due to an overload of saliva), and now it’s fairly unpredictable. It tends to change its output voltage when the pressure across its face changes, but it doesn’t always. It also occasionally changes its voltage for no reason, resulting in samples being taken when nobody is even touching the device. Had we the time and money to replace the pressure sensor before demo time, we would have. In it current state, the sensor usually does what we want it to.

Our pressure sensor’s output is on the order of ones of millivolts, so we needed to amplify its signal. Unfortunately, hoity toity Morotola decided that, since the pressure sensor is differential, users must want two outputs as well, one for each side of the sensor. Of course, we users do not want this configuration. Two outputs that differ by only a couple of millivolts are very difficult to work with for the typical unassuming ECE 476 student. After spending many futile hours trying to get an amplifying voltage subtractor circuit to work, we finally got a super secret INA121 differential amplifier from Professor Land. This amplifier has a differential input and variable gain, and it works beautifully. However, by the time we got it, the pressure sensor didn’t work any more. Oh well!

Both the pressure and alcohol sensors are mounted inside a series of sophisticated pressure chambers (party balloons), with reinforced interconnects (drinking straws), and sealed with advanced sealants (twisty ties). By “mounted,” of course, we mean “dangling inside the balloons with their leads poking out through the rubber.” The pressure sensor has one of its faces (the pressure side) inside the pressure chamber, and one side (the vacuum side) exposed to the air. This design offers a compromise between functionality, and a mechanical setup so simple, even an ECE can understand it. Note that, initially (i.e., for the first four weeks), we didn’t understand it, and as such, spit a lot into both sensors. Eventually, we fixed this problem by using a filter (old gym shirt) when blowing into the Breath-o-Matic.

We also use a standard 104-key PS/2 computer keyboard for high score entry.

Circuit Diagram