Welp, JUST over a month, and I’ve got it pretty much completed. I have it all together, working, packaged up in it’s enclosure, and mobile. (I’ll do a proper video of it soon and post it)
Testing the accuracy of my device has been quite an interesting ride, and it has lead me to one conclusion: Breathalyzers are far from an ideal way of testing Blood Alcohol Content (BAC).
This must be why in real serious cases, Police Departments use blood or urine tests as they are directly measuring the concentration of alcohol in your blood.
Breathalyzers however, are a one-off test. Quite simply, they are measuring the amount of alcohol gas in your mouth. Thats an important distinction. There is the obvious factor that could throw off the test, that you could have liquid alcohol in your mouth. Some of this will be in gas form, and thus what you will be measuring is the concentration of that liquid. Which has absolutely ZERO to do with your BAC.
It’s obvious, but let me really drive this point home: you can take a mouth full of Vodka, spit it out, even rinse your mouth, and still blow a deadly level on a Breathalyzer, mean while your BAC is still zero.
Still waiting on Arduino to release their WiFi shield… So the drinking continues! Er… I mean the MQ3 project continues!
So I’ve put some time into looking for parts and methods for more making this handheld. Ordered some bits, and I’ll update more on that once those parts come in. But the more immediate and all important challenge, is continuing to iterate on the over all implementation of the circuits and software that turn this into a Breathalyzer.
Accuracy is important if this project is going to be successful. There are limitations to the MQ3 sensor, but I want to get the most out of it. So after increasing the accuracy 4.5x last week, we tested again. (All these tests occur when my friends come over to watch The Walking Dead on Friday’s). The first test we saw values ranging between 0 to 6. (Remember these values are just voltage readings from an Analog to Digital [A2D] converter provided on the Arduino). Now that wasn’t good, over 10 beers, the values only increased 6 points. That’s not nearly enough resolution in the signal to be useful. My second attempt after the 4.5x bump in resolution, produced values between 11 and 23. (Note the oddity there of nothing below 11. In my next post I’ll go into my testing procedures, and why there are oddities in these readings, as well as almost certainly in commercial breathalyzers used by authorities.) Continue reading
Still waiting on Arduino to release their official WiFi shield for my C3 project. So my mind began to wounder. And I started an Android app to help post articles to www.talentopoly.com. But got stalled due to waiting on 3rd party API support. So my mind began to wounder.
About two weeks ago I was browsing www.sparkfun.com checking out some of their Sensors and day dreaming about fun things to do with them, and came across this, the $4 MQ-3 Alcohol Gas Sensor. I immediately straightened up in my seat and all my synapses that had been on vacation began firing again.
You see, all my hardware projects so far get to a point of some sort of moderate success, and then get promptly torn down to produce another project. Mainly because their components are expensive and I don’t want to re-buy them all. But also because those projects weren’t something I could easily show someone. With the project now swirling around in my head, it was something I could put together, and keep together. And it would have obviously and meaningful applications to anyone I showed it to.
The project of course, is a Breathalyzer.
And after two nights of putzing around with it, I got it hooked up to a simple circuit, along with a 10 segment LED bar, and have it working.
This past weekend I put it to the test but came up short. Even after 3 beers it was still not able to detect anything. By the end of the night after 10 beers, the highest reading I got was 5 (out of 1023). The effective range of the device it turns out, is MUCH smaller than the absolute range I was reading it in. So the next day I adjusted the AREF (Analog Reference) value to greatly shrink the range I was reading. This boosted the sensitivity 4.5x. It can now readily detect just a single beer on your breath.
In addition to this I added in continuous sampling of the base line readings, and factor them out in order to get more constant and reliable values. My ultimate goal here is to make this as accurate as is possible with the MQ-3 sensor (there are certainly some very real limitations to this sensor), and to make it hand held. With a side goal of making it awesome 😉
This week I ordered a 16×2 character LCD display to display the calculated BAC, and more 10 segment LED bars to increase the resolution of the bar graph. Once that is all tested and working, I want to package this up in an enclosure and make it handheld.
So it’s been a bit since my last update, and that’s because things have stalled.
The bad news is I’ve hit a bit of a wall in terms of long term stability with my existing WiFi module. I’ve addressed issue after issue gradually improving stability of the WiFi stack and my own code. But in the end I just can’t get it to stay alive long enough. Even a few days of stability isn’t good enough for an Alarm Clock that I’d be relying on to get me to work on time. I could pursue the issues further into the WiFi stack, but it would take a fairly big time investment. Since the stack and hardware are no longer supported I’d be investing all of this time into what is essentially dead hardware. If I ever wanted to upgrade or make another one of these clocks, all of this time would be wasted since I couldn’t buy another one of these WiFi modules.
The good news however is there is a ray of hope! Truly excellent news out of Maker fair: Arduino (the company) announced several new Arduino’s (the micro-controller) which is great and all, but most excellently, they announced an official Arduino WiFi shield! The library and hardware will be officially supported going forward! They are due to release some time in October, so my project is stalled until I can get my hands on one of these, but this is truly great news for all of my projects which usually have wireless connectivity at their heart 🙂
I’ve been super busy lately so I haven’t had a whole lot of time for this project, but I did manage to get some work done last nite and merge in a patch I found floating around the internet.
It was supposed to make my WiFi chip reconnect to the AP more reliably, and so far it appears to be working! My original soak tests lost connection to the AP after about an hour and failed to ever reconnect. Last night after merging and testing this new patch, I set up another soak test which has been going 10 hours strong so far!
I set up some port forwarding, so you can check out the test page running on the Arduino right now (this link won’t be live for very long): http://www.grendelsdomain.com:1234 (Note: Some people report this link as not working, but it’s still working for me… go figure.)
Also note that it is currently NOT resynchronizing with NTP servers, so you will notice a widening divergence between the time reported and actual time (EDT).
Next up, (hopefully this weekend) I need to get it resyncing with NTP servers every 12 hours. And start pulling data from my Google Calendar. So hopefully by the end of the weekend this network connected clock will become a network connected alarm clock 😉
LLOONNGG week of packing, moving, and unpacking. Still not done unpacking. Probably won’t be fully unpacked by the time we move again Oh well.
ANYWAY! Onward and upward!
[ I really like my little Paint.NET logo, so thought I’d throw it in again 😉 ]
So since my last post I began working on NTP (Network Time Protocol) synchronization. As with EVERY part of the project so far, there were a lot of snags along the way, but I got it there. It’s a truly crippling problem having the maker of my WiFi chip defunct. It leads to all sorts of problems with documentation and community support. But “Damn the torpedoes!” I say! FORWARD!
I had to implement the NTP protocol on my end. I simplified it quite a bit by not taking advantage of many features [40 bytes of hard coded zeros in the middle of my message 😉 ], so it was actually pretty easy. Sending and receiving the UDP packets, however, was a bear because of the poor documentation for my WiFi chip. Took quite a bit of fiddling, but I got it working.
Then I found the great little Time library for Arduino that allows for easy manipulation of time and time keeping, and set that up to use my new NTP code for synchronization.
Putting it all together, here you can see the current boot sequence for the C3:
With this working, I set it up for a soak test. I wanted to see how much time the Arduino would lose after it synchronized only once, that way I could figure out how often I would have to re-sync with the NTP servers. After 24 hours I had lost just under a minute, and after 48 hours I had lost just about 2 minutes, which looks pretty good because it doesn’t seem to be accelerating. It’s a pretty minimal, and a pretty linear loss. I could probably sync with NTP as little as once a day, but to be safe I’ll probably start by syncing every 12 hours.
So that’s all good! But during the soak tests I did discover yet another problem with my WiFi software stack. It doesn’t automatically reconnect when it’s connection to the WiFi AP is dropped. It’s a fairly minor problem in the software stack that I already found someone’s patch for. My version of the stack is already pretty customized however.
So my next goal will be to setup auto-syncing at 12 hour intervals. Merge the WiFi auto-reconnect patch with my customized stack. And finally further customize the stack in preparation for working along side the display shield I will eventually be integrating. (I need to move some pins around in the code)
With all of that I should have a rock solid NTP clock, which of course is the necessary basis for everything going forward. After that I can focus on Google Calendar integration and other “fancy features” like audio output and a display
So I got my brandy new Arduino Mega 2560 in the mail. It has 256KiB of program memory (8x the memory of a standard Arduino!)
As I mentioned in my last post, the standard Arduino only has 32KiB of program memory, and with all of the networking features I want compiled into the library I’m using, I was already at 33KiB. But now with a spacious 256KiB (What will I ever do with it all!) I can add in features until my heart’s content! (DNS and DHCP oh my!) Other than the extra memory (and extra I/O pins) It is identical to the regular Arduinos. Or so I thought… (cue the misery.)
Getting a blinking LED sketch (Arduino speak for program) running on it from the Arduino IDE was easy enough. But replicating it inside my Code::Blocks setup was not so easy. It took further modification of my command line scripts for which there was little to no documentation to base it off of. After lots of groping around in the dark, trial and error, and some guess work, I got it there. Though the auto-reset was not working, so I have to time a physical reset of the board with the compile button in the IDE to get the programs to upload. *annoying*. This took a few hours… but it gets worse.
Then began the real pain. You see, the trouble starts with the fact that the wonderful WiFi board that I use (the WiShield, made by AsyncLabs) is no longer in production. In fact, in March of this year, AsyncLabs shuttered their little studio completely. Which is a real bummer because they are the ONLY mature, drop-in WiFi solution for Arduino 🙁
With AsyncLabs out of the picture, development on its library and support in its forums has all but ceased. With the Mega2560 being a relatively new board, its fair to say that support will never be added for it in the WiShield’s code. Now you might ask, but Adam! You said the Mega was pretty much identical to other Arduinos! Why would support need to be added at all! And it’s because it’s NOT identical. There is a small difference that turned out to be vitally important.
You see the Arduino’s are based on an AVR type chip manufactured by Atmel. Atmel makes a variety of these chips under the ATmega line.
These ATmega chips provide a nice little piece of hardware/software functionality called SPI or Serial Protocol Interface. I won’t go into the details, but it’s critical to the functioning of the WiShield.
This is where the problem lies. Arduino’s based on the ATmega168 or the ATmega328, have their SPI pins on 11, 12, 13.
But Arduino’s based on the ATmega1280 or the ATmega2560, have their SPI pins on 51, 52, 53.