| Introduction Let us introduce the Breath-o-Matic alcohol sensor. The Breath-o-Matic is an electronic, non-invasive method of measuring a human’s blood alcohol content (BAC). Its elegant, yet discombobulated design embodies a cheerful mix of mechanical and semiconductural components. Simply blowing into the mouthpiece causes the Breath-o-Matic to automatically begin taking a sample of your own foul morning breath. If you’ve partied sufficiently hardy, then you may also have a chance of making the high score list. You’ll then have the pleasure of seeing your name up on the wall of shame, along with up to nine other drunken slobs. Of course, if you don’t make the high score list on your first try, don’t despair! At college, the night is always young!  Please note that the designers and manufacturers of the Breath-o-Matic do notadvocate excessive alcohol ingestion, and the Breath-o-Matic should not be viewed as an excuse, nor as a motivation for binge drinking. Additionally, the designers and manufacturers of the Breath-o-Matic make no claims about the Breath-o-Matic’s ability to detect “legal BAC limits” for the purposes of driving, operating heavy machinery, or attempting to engage in stimulating conversation with members of the opposite sex. |
Inspiration
(Or: Inspiration besides the obvious)
Our inspiration for this project came from a very simple illustration of how a Breathalyzer works in the book, The Way Things Work, by David Macaulay. We'd also often found ourselves in situations where we would have liked to know our current BAC, but we had no methods of determining it, beyond crude estimation using the "attempt to touch your nose with your finger with your eyes closed while standing on one leg" method, which often resulted in injuries. Thus was born the Breath-o-Matic.
Interface Description
(Or: What to look for when your vision gets blurry and your brain stops functioning, and you’re not entirely sure whether you just blew into the Breath-o-Matic’s mouthpiece or the dog’s nose)
When the Breath-o-Matic is first turned on, the Main Menu appears on the screen with three choices: press the Green Button to access the High Score List, press the Blue Button the force sample acquisition, or start blowin’!
Pressing the Green Button brings the user to the Breath-o-Matic’s high score list, which cycles through all of the current high scores. If there are no high scores yet, a message to that effect is displayed. At this point, the Blue Button will delete high scores, and the Green Button brings the user back to the Main Menu.
If the user elects at the Main Menu to huff and/or puff into the mouthpiece, the pressure sensor will detect a pressure differential and the Breath-o-Matic will begin taking samples. Pressing the Blue Button will accomplish the same thing. Approximately every half-second, a sample is taken, an LED flashes and the speaker beeps. These actions provide the user with breathtaking (har!) visual and audible feedback.
After about five seconds (10 samples), the user stops blowing, and the MCU waits six seconds, or until the sample has stabilized, whichever comes first. If the sample has not stabilized after six seconds, the speaker makes an angry noise, and the user is ejected back to the main menu to try again, or, if they are feeling belligerent, chuck the device across the room. If the sample has stabilized, the speaker plays a happy tune and the user is presented with their reading, which, for good little girls and boys, may well be zero. We use six LEDs to indicate six different levels of intoxication. These levels include “Sober” (BAC<0.04), “Happy” (0.04≤BAC<0.06), “Tipsy” (0.06≤BAC<0.09), “Confused” (0.09≤BAC<0.12) “Incomprehensible” (0.12≤BAC<0.15) and “Boris Yeltsin” (BAC ≥0.15).
If the user has achieved a high score, by either having a higher BAC than any of the ten current high scores, or by there being fewer than ten high scores on record, then they are notified of their disgraceful achievement and prompted to enter their name via a standard computer keyboard (not included). After name entry, the user is shuffled over to the high score list, where they may see how they stand compared to the ten other lowliest degenerates to have used the Breath-o-Matic. High scorers may wish to celebrate their success with a glass of water, a long nap, and a brain shattering hangover (also not included).
Formulae
The TGS 2620 alcohol sensor functions as a variable resistor, whose resistance has a logarithmic response to ethanol, as shown in the following plot, lifted with no shame from the TGS 2620 datasheet.
Using the Golden Rule of log-log equation determination (i.e., estimating values based on the fact that lines look “pretty close together”), we extracted the following equations for determining the PPM of ethanol in air from the sensor’s resistance:
Region 1 (2 ≤ Rs/R0 < 4): PPM = 244.8(R0/Rs)1.304
Region 2 (Rs/R0 < 2): PPM = 248(R0/Rs)1.323
R0 is a constant that depends on the individual sensor, and Rs is the sensor’s resistance in ohms. We calculated R0 of our sensor to be 6584 ohms. Values of Rs/R0 above 4 correspond to BACs of less than 0.015, and therefore are reported as a BAC of 0.
Parts per million is defined as grams of solute per grams of solvent. BAC, however, is defined as grams of ethanol per 100mL of blood. Because the intention of our project was to be noninvasive, we ruled out our first design, which would use a mechanized needle to puncture the user’s vein, suck out the user’s blood using a 12V pump, and determine the BAC from the blood sample. Instead, we sample the user’s breath, which is less invasive, but slightly more harmful to bystanders and the environment in a halitosital sense. Alveoli (deep lung) air has one twenty-six hundredth of the ethanol (by mass) that blood does. Thus, we can convert to BAC from the sensor’s output of parts per million as follows:
PPM ETOH = (g ETOH / 106g Blood)
BAC = (1g ETOH / 106g blood)(129g air / 1L air)(210)(10-6) = (g ETOH / 210L air) = (g ETOH / 100mL blood)
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 ...
switch(MainState)
{
case TakingSample:
TestBreathStateMachine();
break;
}
// ... et cetera et cetera
}
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 notintoxicated, 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!
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.
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.
Results
(Or: We’re pretty sure that we performed extensive testing of the alcohol sensor, but, for some reason, we just can’t remember)
As we have already mentioned several times in this report, the pressure sensor stopped working early on, which was a serious setback. We thought at first that its response became unpredictable, but after reversing the vacuum and pressure sides of the sensor (turning it around so that the side that was initially inside the balloon was instead outside and vice versa), we found that the response was mildly consistent. Using a set of simple heuristics which detect when the pressure response rises by a certain voltage, instead of detecting when it goes above a preset voltage, we were able to detect breathing most of the time. Because it isn’t always possible to initiate sample acquisition by breathing, we allow the user to press the Blue Button to force sample acquisition.
Testing of the ETOH sensor was performed by sippin’ on gin and juice, and then huffing and puffing like the big bad wolf into the mouthpiece. We compared our results to charts from Health.org (see the appendix), and adjusted the sensor’s fundamental constant (R0) accordingly. We were determined to test the Breath-o-Matic to the limit of its abilities, and we soon found ourselves lying naked on the Arts Quad, covered in multicolored body paint, with no memory of the last 32 hours’ events*. Unfortunately, this calibration method is unlikely to be very precise, so we're not entirely sure how accurate the Breath-o-Matic is. Assuming that our equations to convert from PPM to BAC are correct, and the ETOH sensor performs as advertised, we figure that the Breath-o-Matic is probably accurate to about 0.02 up to a BAC of 0.3 or so. After that point, we are limited by the resolution of the ADC and the quality of the sample.
* JUST KIDDING
We set the upper limit on the six LEDs at a BAC of 0.13, which is relatively conservative (approximately four drinks for a 140 pound male). We set this limit to be low, because we knew that a higher limit would encourage some harebrained frat boy to attempt to achieve it, regardless of what the limit actually was, be it a BAC of 0.35 (unconsciousness) or 0.5 (death). We feel that giving no relevant feedback beyond a BAC of 0.13 discourages this sort of irresponsible (and, presumably, puketastic) behavior. Our high score list is also limited to a BAC of 0.20.
Our high score list was tested by infusing the Breath-o-Matic with different quantities of alcohol, and seeing whether a higher BAC beat a lower one. After remembering that to convert from PPM to BAC we needed to divide by a million somewhere along the lines, the results started making sense, and the high score list proved its worth quite admirably.
We noted that the TGS 2620 takes a very long time to settle after each sample (on the order of five minutes), and it only does settle if it is well ventilated. Therefore, we flash a message on the LCD if the sensor has not yet settled (though we still allow a sample to be taken), and we have to manually ventilate the sensor after each reading (either by removing it from the pressure chamber, or by pumping air into the pressure chamber).
Overall, we think that the Breath-o-Matic works well. We had initially planned on measuring temperature and humidity at the alcohol sensor, because the TGS 2620's response depends on these factors. However, we decided that the parts were too expensive, and everybody's breath is about the same temperature and humidity.
We also ditched the spec’d power button in favor of a switch. Originally, we were going to have the button put the MCU to sleep and turn off all of the external circuitry; however, this idea was fraught with problems, including weird coding bugs and the external circuit not fully shutting down. So, like any good designer, we gave up. In the same vein, we eliminated the option of saving high scores to EEPROM, because we were unable to get the the scores to save correctly. So high scores are saved in SRAM.
In addition, we used a different sensor than what we had originally planned on (we’d planned on using a fuel cell, which by itself, would have exceeded our budget). Our choice of sensor, the TGS 2620, sells for only $5 in quantity, and we got a free sample.
Finally, we had originally implemented a Warming Up state for the Breath-o-Matic's Main State Machine. Because the TGS 2620's resistance spikes initially after it is charged (after the Breath-o-Matic is turned on), we originally used this state to halt operation until the voltage had settled. However, because the TGS 2620's resistance also settled so slowly after each sample, the Warming Up state was being entered erroneously. Instead, we now just have a warning when the TGS 2620's resistance is below its zero-PPM value.
We’re satisfied by the final Breath-o-Matic, but, of course, given more time, money, mechanical competence, and force of will, we certainly could have made it even more awesome. See the “In Retrospect…” section for details.
Usability
(Or: LimBAC→∞(usability)=0)
Using the Breath-o-Matic is, in principle, quite simple: drink your fill, wait 15 minutes (so that alcohol in the mouth is not erroneously detected), take a deep breath and blow into the mouthpiece for five seconds. On the (not so) rare occasion that sample acquisition does not begin automatically, press the Blue Button as you start blowing to force a sample to be taken. All other actions are accomplished by pressing one of two hardware buttons, except for entering a name for the high score list, which uses only the alphanumeric characters, including space and Enter on a computer keyboard.
Menus on the Breath-o-Matic are clear and uncluttered, and the two non-keyboard buttons that we use are large and differently-colored (Blue and Green). Sample acquisition has audible and visual feedback to assure the user that the Breath-o-Matic is performing an action; while taking and analyzing a sample, the Breath-o-Matic beeps and blinks the red LED. Additionally, when the BAC is calculated, the Breath-o-Matic plays tunes and lights LEDs in a jovial fashion to indicate the user’s BAC range.
High score list entry is simple; when prompted to enter their name, the user simply types their name on the keyboard, up to 12 characters. If they make a mistake, the user can use the backspace key, and when they are finished, the Enter key saves the name. The advantage of a computer keyboard is that it has all of the letters right on it, so we don’t have to deal with horrible interfaces where you have to select each individual letter from a list. Also, everyone has a computer keyboard; if you need one, you can just hop over to your computer and use your own. The disadvantage is that you have to lug a freakin’ keyboard around, which could be a problem on festive outdoor events, such as Slope Day. Fortunately, the user can elect to skip name entry by pressing the Green Button, so the keyboard (and, by extension, high score entry) is not a required feature.
Some factors, such as inebriation, may reduce the usability of our interface. Though it’s difficult to compensate for such an effect, our large buttons and simple menus will probably make it through the vodka-thickened skulls of most users. If not, they may at least be amused by our spirited sounds and blinky lights. And honestly, if the Breath-o-Matic elicits even one drooling, unfocused grin from a satisfied user, then truly, we have succeeded.
Safety
(Or: We make no guarantees as to the stability of the user's life insurance policy premiums during or after the use of this device)
There are two main safety considerations regarding the Breath-o-Matic, which we will address in ascending order, where ascending is defined as “the order in which we will list these safety considerations.”
The first concern is perhaps the most obvious: the Breath-o-Matic may inspire the users to attempt to achieve the “ultimate high score,” which is probably better known as “an ambulance ride.” One of us (Dan) is a volunteer firefighter, who often must go on EMS calls at 2:30am where some goon has had four shots of whiskey, four shots of vodka, four shots of mouthwash, and four shots of NyQuil and is feeling very confused indeed, and must to be taken to the hospital. The annoyance level of this sort of call cannot be summarized in words that are fit to print. For this reason and others (“morality”, for example), we do not wish that the Breath-o-Matic be used as a vehicle or excuse for excessive drinking. Thus, no additional LEDs light beyond a BAC of 0.13, and our high score list is capped at a BAC of 0.2. Neither level is dangerous.
The second concern is one of hygiene, in the form of the saliva deposits on and in the Breath-o-Matic. Saliva can transmit a very large variety of diseases, from the innocuous (common cold) to the life-threatening (Hepatitis B). To combat saliva sharing, we recommend different mouthpieces and filters for each person. Thus, saliva ceases to be a concern unless the user accidentally inhales instead of exhales, which we don’t think is very likely.
We use a standard 104-key PS/2 keyboard for high score entry, which conforms to the IBM PS/2 standard. Serial communication through a PS/2 keyboard works as follows: when a key is pressed on the keyboard, the keyboard sends the scancode for the key; if the key is held down, the scancode is sent repeatedly. The keyboard's internal clock is only running when the keyboard is sending data. When the key is released, the scancode "F0" is sent, followed by the key's original scancode. This sort of communication is easy to read with the Mega32's USART, but it's a downright pain in our gluteal muscles that the scancodes don't correspond to ACSII. So we have to parse them.
The design of the Breath-o-Matic was completely original, and thus does not infringe on any existing copyrights, patents, trademarks, watermarks, birthmarks, skidmarks, signatures, likenesses, territorial urinations or acts of congress. To our knowledge.
In Retrospect…
(Or: What we wish we had done differently, assuming that it took no additional time, money, mechanical competence or effort)
The first thing that really boiled our asparagus was our mechanical design. Our design needs two main things: a chamber in which the user’s breath sample can stabilize, and a method of preventing saliva from accumulating within said chamber. As lowly aspiring electrical engineers, we didn’t know jack shoot about mechanical design, so we only semi-succeeded on both counts.
Our pressure chamber, which consists of a largish party balloon, mostly holds the breath sample pretty well, but there’s some inevitable leakage at all straw joints and the holes through which the sensors’ leads poke. There are three straw joints (mouthpiece to pressure balloon, and two between the pressure balloon and the ETOH balloon), and eight holes through which leads poke (four for the pressure sensor and four for the ETOH sensor). Of course, we need some pressure leakage (we don’t want the user to actually blow up the balloon and stress all of our flimsy mechanical parts), but we’d prefer if it were under our exclusive control; breath leaking out through sensor holes may throw off the sensors’ readings.
We didn’t realize that it was necessary to prevent saliva accumulation until very late in the game, after we noticed that (WARNING: the rest of this sentence contains a graphic description of bodily fluids) spit was bubbling out the sensor lead holes and contaminating the leads. We elected to use a ripped up shirt as our Saliva Shield, which seems to work as measured by the reduced volume of spit leaking out of the balloons. But we were unable to eliminate the saliva factor entirely, which means we have to periodically clean the ETOH sensor. Of course, had we more time, etc., we would implement a magical Super Saliva Shield that would block all saliva from entering the Breath-o-Matic.
Another thing that we found somewhat lacking in our design was the method in which code was written and the circuit built. Our design process consisted of testing each component on a white board with a snippet of code to ensure that it worked; after testing the component, we added giant, vaguely related blocks of code to our final C file. We had written most of the code (~700 lines worth) without testing it, and we also built the complete circuit on a solderboard without testing it. Then we crammed the two together, and as is predictable, they didn’t work. Debugging took nearly a week. We could have saved ourselves a lot of pain, frustration, stomach churning and nose running if we had built and tested discrete portions of the circuit on the solderboard, eventually building up to the completed thing. “Oops,” is our feeling on this particular topic.
We sampled the TGS 2620 from Figaro Electronics, and we sampled two Mega32s from Atmel distributors for our project. One Mega32 fell out of our solderboard somewhere, never to be seen again. We killed another one with static death discharge. Finally, we got a working processor from the lab, which is the one that is currently in the Breath-o-Matic. In the spirit of this “In Retrospect” section, we kinda wish that we were able to use at least one of our original samples, which would have allowed this report to paint us as being somewhat more competent.
We also, given the opportunity, wouldn’t have broken our pressure sensor.
Ethical Considerations
(Or: Ethics? We don’t need no steenkin’ ethics)
As regarding the IEEE code of ethics…
1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.
As we discuss in this section, there are two concerns with our project that may, under the right circumstances, prove to be a danger to the public. We have disclosed these concerns fully, and we accept responsibility for any injuries incurred from our device as long as the device is used in a safe and responsible fashion, in accordance to all manufacturer’s guidelines, which include, but are not limited to:
• Use separate mouthpieces for each person
• Only blow into the mouthpiece of the Breath-o-Matic; under NO circumstances inhale through the mouthpiece
• Do not use the Breath-o-Matic while excessively intoxicated
• Do not subject oneself to excessive intoxication for any reason whatsoever relating to the Breath-o-Matic
• Do not open the Breath-o-Matic’s container, except to replace the battery
• Do not modify the Breath-o-Matic
• Do not use the Breath-o-Matic with any other devices or appliances
• Do not subject the Breath-o-Matic to excessive liquid, heat, vibration or pressure
2. to be honest and realistic in stating claims or estimates based on available data
Although we have attempted to calibrate the Breath-o-Matic to the reasonable extent of our abilities, our methods are intrinsically imperfect. As we mention in the introduction of this report, we, the designers and manufacturers of the Breath-o-Matic, make no claims about the Breath-o-Matic’s ability to detect “legal BAC limits” for the purposes of driving, operating heavy machinery, or any other potentially dangerous operation. The Breath-o-Matic shouldabsolutely not be used for this purpose. In addition, we believe that a BAC of 0.00 is the only safe level for driving, and related actions.
6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations
Although we do not claim to be experts at measuring blood alcohol content we do admit this fact openly. We are, however, familiar with alcohol’s effects and, as such, feel that we have sufficient perspective to design this breath alcohol tester. We acknowledge the fact that we do not have a rigorous or definite method of calibrating the Breath-o-Matic, and to that end, we do not consider it to be a precision instrument. However, we were willing to learn quite a few things about BAC levels and their effects, in addition to a variety of circuit design considerations while designing and manufacturing the Breath-o-Matic. In this manner, we have improved our technical competence.
7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others
We were very happy to accept criticism during the course of our project design, and we were constantly correcting errors during testing (the “forgetting to divide by a million” bug comes to mind). We’d like to thank Professor Land for all of his help, guidance, and concerned looks when we knocked things over. We’d also like to thank John Lee for helping us decide on speaker noises, and Dave for constantly coming around with a glazed look in his eyes, asking if we needed a test subject, and all the other TA’s and consultants and colleagues and yak yak yak, etc.. We also thank Figaro Engineering and Atmel for sampling us the TGS 2620 ethanol sensor and Mega32s, respectively.
8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin
BAC measurements are universal across race, religion, gender, disability, age and national origin. Additionally, our multiple feedback methods, including auditory and visual, allow persons with various sensory disabilities to enjoy our product (note that said disabilities may be the result of alcohol ingestion). Unfortunately, people who don’t have any lung capacity are out of luck in terms of using our product; we cannot compute a BAC if we do not have a sufficient breath sample.
Alex tested and and soldered components onto the final solderboard, wrote the keyboard code, helped to test the ETOH sensor and designed the web site. Dan did preliminary design, spoke to parts distributors to get samples, tested and soldered components, built the mechanical structure, performed final ETOH testing, wrote the rest of the code and wrote the writeup.
The Breath-o-Matic is an easy to use, semi-accurate, enjoyable little device, contained in a small (relative to Michigan) little package for Your Convenience. We find it to be informative and fun, and we plan on taking it everywhere we go - just in case. If we had a million trillion dollars, we would buy the world a Breath-o-Matic. Because Lord Knows - it needs it.
A: References
Chapweske, Adam. “PS/2 Mouse/Keyboard Protocol.” http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm
Health.org. “Alcohol Impairment Chart.” http://www.health.org/nongovpubs/bac-chart
Click figures for larger versions.
Figure 1. MainStateMachine
Figure 2. TakingSampleState
Figure 3. EnterHighScoreState
Figure 4. Circuit diagram
Click each picture to see a full-sized 1760x1168 version.
Alex examines the ill-fated power button
Alex during a bout of intense coding
Dan demonstrates the proper use of the mouthpiece
Dan soberly tests the response of the alcohol sensor
The naked solderboard
A peachy shot of the Breath-o-Matic's pressure chambers
The Breath-o-Matic is Microwave Safe
Welcome to the Breath-o-Matic!
The rewards of depravity
0 comments:
Post a Comment