• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

330 Neutral

About Wavesonics

  • Rank

Personal Information

  1. RSS Needs

    As most techies I know, I have a set of websites I check up on each morning, and throughout the day. I get to the office in the morning, and first things first, I "make the rounds." And thanks to my handy dandy RSS reader, I never miss a single thing. I'm hyper-informed about the narrow set of topics that the sites in my usual rotation cover. One of those sites is The Verge. A splinter group formed from former Engadget editors, it's quickly becoming one of the best tech and tech culture news sites on the web. Recently, one of the editors that I follow closely, Paul Miller, came up with an experiment he wanted to run: go internet free for an entire year. And I mean completely internet free. Not just browsing websites, but email, streaming video, music, everything. He even ditched his smart phone and got an old Nokia, and won't even text on it. I actually kinda get it at a basic level. The internet is completely integrated into my life, it's always there. Any lull in a conversation, out comes the smartphone. Any down time at the office, up comes the browser. So limiting one's interactions with the internet to a more balanced amount sounds perfectly fine to me. I began following his updates from the disconnected world with some interest. My first reaction was one of: Why so extreme? So many little tasks would become orders of magnitude more difficult for him. But the more I read of his dispatches, I began identifying with a lot of what he was saying. He talks about the "phantom limb syndrome" of the tech world. Like when you Ctrl+X a piece of text, you almost feel its unpasted ghost in your fingers until you Ctrl+V it back into existence. Or phantom leg vibrations that make you check your phone. Or worse still for me... the phantom RSS stories left unchecked in my feed. I get a high filtering through my RSS feeds, saving the interesting articles to Pocket (formerly Read-It-Later) for more dedicated consumption later. I've got it down to a science, I'm hyper efficient at it. Clearing out my RSS feeds in the morning is a cathartic experience. For a few minutes... and then I start to get the itch... What new stories have been posted... What am I missing. I better check now so they don't pile up and require even more time to sift through later! It kinda sucks actually. Something I really enjoyed has become a compulsive need. I tell myself it's both enjoyment (I do genuinely enjoy tech news) and important to stay up on the industry for professional reasons. But it's almost a chore now. This must be how OCD people feel about checking the lock on their door twenty times before they leave. They know it's bad but can't help themselves. Now I'm not saying the internet is bad. It's a piece of technology. And Technology isn't inherently good or evil, it's how we as human use it that give it import and meaning. I think in terms of inventions that have most profoundly impacted our species, it goes like this so far: Fire, Wheel, Internet. So don't misread my next statement. In his most recent dispatch, he talks about the signal to noise ratio on the internet being askew. And it really struck a chord with me. It's something that's been burning in the back of my mind for a long time now, and this put a name to it. I instantly seized on it. This was my problem with my RSS feeds. Out of usually around 200 articles sitting in my feed in the morning, I usually only save out about five to read later. I glean tiny fragments of information from scanning the rest, but it's mostly worthless. For the last year or so I've been trying to cut down on the worthless noise that I usually click on. I've seen enough people walking into signposts and cute kittens to last me a lifetime. It's absolutely a waste of time. So I've been making a conscious effort, before I save something out to read later, to ask myself, is this really worth spending time on? And it's helped. Some. But I'm still filtering through hundreds of articles a day. The internet has lowered the barriers on content creation so far that the noise is now the pervasive standard. And finding the signal in it requires this OCD level of effort, filtering through it all if you don't want to miss something. My RSS addiction is just one of my "phantom limb" problems though, which cumatively add up to a very distracted life style. So I'm back to reading Paul's dispatches, and being kind of jealous actually. For my part, I've got a backpacking trip coming up to the Grand Tetons in Wyoming, and from the moment my plane lands I intend to turn my phone off, throw it in the trunk of the rental car, and have my own week of extreme disconnectedness.
  2. No I haven't hit any sort of production or even commercial level polish. But the title sure had some nice alliteration huh? ;) As the title hints at though, the past month has been a great example of the vast gap between a prototype (as seen in my last YouTube video) and a production ready product. At first I thought doing all of the alarm clock stuff (with Google Calendar integration) would be easier because I was now doing it on Android, with Java and all of Androids high level features. Boy was I wrong. On Android apps are meant to be ephemeral. Meaning that if you want your app to be a permanent fixture on the system, you really have to fight the system. I've ironed out most of these bugs over the past month, but it's been a long process because I can only do one real world test a day. I've got it down to the Alarm working very reliably (so far). But the user facing Activity seems to want to die in the middle of the night some times, still working this bug. On the hardware side of things, the Bluetooth connection has some durability issues. Not every night, but often enough, the IOIO disconnects and won't reconnect without a power cycle. Still working this issue. And lastly, I've determined that the sensor it's self, can't accurately measure a whole Queen sized bed. So I've ordered the parts and will use two sensors, one for each side of the bed. This will give me the added benefit of being able to figure out how many people are actually in bed. Not sure what I will do with this info yet, but more info is always better. Once I fix the last remaining software problem, and add in some spit and polish, I'm thinking about releasing the app stand alone (sensor parts disabled in options). It will help me with wider testing, and I think the apps Google Calendar integration is a really killer feature on it's own. I'll probably release a free version with a donate micro-transaction or something.
  3. C3: Prototype Testing

    Thanks! Still working through some bugs, but should be all set shortly.
  4. Good news everyone! I've reached prototype stage! And I've got a video to prove it! [media][/media] And with that I set to some real world testing. Night 1: The alarm went off as expected! I snoozed it (as I am want to do). But 30 seconds later it went off again! I had left in my hard coded debugging value of 30 seconds for the snooze time :/ Realizing this in my half awake state, I got out of bed in order to turn the alarm off... but nothing happened... with the alarm still blaring out at full volume, I inspected the app closer, and noticed the pressure value was not updating. I close and reopened the app in an effort to reconnect to the sensor, but to no avail. I ended up having to go under my bed and power cycle the IOIO. Debugging first thing in the morning is not my idea of fun. Night 2: In preparation for night 2, I decided to connect to the IOIO over USB to ensure the connection remain steady for the whole night. But 8am come and went with no alarm. I didn't have time to collect any data on what went wrong because I was in quite a rush when I finally did get up. I had a nagging suspicion however that the volume may have been at least partly to blame. So I modified the app to hard set the volume to max every time it went off, and I improved some of the data smoothing related to the pressure sensor to avoid false positives for getting out of bed. I also discovered that, with the current firmware on the IOIO, it won't provide power to the phone over USB, so that's not really an option at the moment. Night 3: Connected over Bluetooth again for this night of testing (due to the charging issue over USB), and added in some more debug logging. This time the Alarm went off at full volume, exactly when it should, and snoozing worked beautifully. But the Bluetooth connection was lost again. I got up and plugged my phone into my computer and dumped the logs. They don't go back far enough to see the disconnect, but I got some data out of it anyway. I've modified the app now so that when the connection is lost, it dumps the Log to disk right then and there, so Night 4 should produce some more definitive results as to whats going on. Onward and upward I say!
  5. I've been making good progress since receiving my IOIO. Got it up and running over USB, tested it all out, and then had to wait for my PICKit3 to upgrade it's firmware. Once it arrived, it took some time for me to grok it (I've never used a PIC programmer or anything like it before) but finally got the Firmware upgraded and got the IOIO talking to my phone over Bluetooth. The next step was to recreate my sensor circuit and get back to where I was with the Arduino, and now I have it all soldered together in a more permanent fashion. For now anyway, that pretty much wraps up the hardware side of things. I'll create an enclosure later, and maybe add a few more sensors (temperature, humidity, etc). The other side of the coin, my Android app, has been coming along in between hardware work. I have it communicating with the sensor, and have a nice setup process to calibrate the sensor for any bed (measuring the dead load of the mattress). And I'm about 60% of the way toward using Google Calendar to set Alarms. Though Android's Calendar provider is rather... rudimentary. So I'm having to write a bit of a wrapper library in order to utilize it. Anyway, that's it for now, I should have a working prototype very shortly!
  6. C3: From the ashes!

    Oh cool, No I hadn't seen those. It makes me wounder if putting an accelerometer into my puck would help augment my ability to determine if I'm in bed. Also it could provide the ability to determine the quality of a nights rest which would be neat.
  7. I had an unexpected break through on my C3 project! A couple nights ago, I had some spare time, and had been thinking about the pressure sensor for a long time. The problem with it is, there is a circle with a radius of just 4mm, and in order to get good readings, the force must be applied to the center, not the edges. This gives me only about 2mm's in radius to apply force in. Since this will be under my mattress where things can be jostled or move around, that's a pretty narrow margin of error. With this in mind, I came up with an idea for a "puck" and threw it together in Google SketchUp: I was blown away by how easy SketchUp was, I learned the program and made this model all in less than an hour. What you are looking at here, on the right is the base of the puck. The sensor will sit at the bottom of the trench and be held in place by it's constrained neck. And the left is the top, that will insert into the trench, and the notch will hold it perfectly in place, while the nubbin will be the only thing applying pressure, and it will be held perfectly on the 2mm pad. The ease of all of this, really motivated me, and the next night I got my self over to my local hacker space, sprout & co. and printed this baby up using their fantastic Thing-o-matic: So I brought it home, marveled at how this thing that had been in my brain just two nights before, was now sitting in my hand, and set to programming my Arduino. Came up with a voltage divider so I could get good values out of it, and calibrated it so I could convert the values to readings in pounds. Then I set it up to record a full night of sleep, and dump the contents to a text file on this little net book. And it functioned perfectly! You can even see when I got out of bed near the beginning there! Despite these resounding successes, I hit the same wall I had been at for a while now. The standard Arduino, as well as the available WiFi shields, really weren't up to the scale of the project I had in mind. And the new Arduino Due and the official Arduino WiFi shield which might solve my problems, are seemingly never to be released. After a day or two of mulling this issue over in my head, I began perusing SparkFun as I am want to do. And I came across the IOIO which I have seen before, but this time it sparked (see what I did there?) a sea change in how I was thinking about this project! So many of the things I wanted the project to do (Like WiFi, NTP, Google Cal sync, Text-to-Speech) are exceedingly difficult for little 8bit Arduino's to do. And other things I wanted the project to do (interfacing with a variety of hardware sensors) are difficult for Android phones to do. But my change in thinking was to treat my Micro-controller merely as a "Sensors Package". Which a custom Alarm Clock app on my phone will communicate with in order to be smarter than it could be on it's own. So that's what I'm doing! I'll hook my sensors into my IOIO (pronounced yo-yo) which will connect to my phone via Bluetooth. And my Alarm App which I will make, will utilize the sensor data to do everything I had hoped it work! And more!
  8. First Entry

    Well let me be the first to welcome you to Journal land! Hopefully things start looking up for you. As far as learning game dev, programmer/scripting is pretty key and the good news is there's TONS of stuff online to help you teach your self, all completely free. [url="http://unity3d.com/"]Unity 3D[/url] might be a good place to start, it tries to take as much out of programming and into their Editor program as possible, and what programmer is required can be done in Javascript which many new people find easy to pick up. And the base PC version of Unity is FREE [url="http://forum.unity3d.com/threads/34015-Newbie-guide-to-Unity-Javascript-%28long%29"]This[/url] looks like a decent little tutorial for learning Javascript specifically for Unity 3D. Hope that helps. The forums here on GDNet are pretty helpful too.
  9. As I mentioned in a previous post, I'm beginning a new game project that I'm pretty excited about. Me and the artist I always work with have been mulling a new project for some months, and have been waiting for other things in our lives to clear a way for it to begin. About a month ago we started to put things together. Setting up internal servers and services for tracking and coordinating the project. As well as putting together a slightly larger team. We've brought on a programmer that I've worked with before, and a new artist/game-designer who we've known for a few years. Effectively doubling our bandwidth in both assets and engineering. After discovering that Unity 3D had changed their pricing model, offering a much cheaper non-pro version for Android and iOS, I began doing some research and have since selected it as the technology to base our project on. This is exciting, because in all our previous projects, we had been starting from scratch, technology wise. Developing the engine tech and tool chain (if you could even call them that) as we developed the game. For even our simple games, this involved a huge time investment. Now with our doubled bandwidth, and a proven technology base, we're all pretty excited about the possibilities. Lots of stuff is still up in the air, we're still heavily in discussion about game ideas, and names for our team, and so on. Though some points are beginning to gel. We're settling on a few "Guiding Principles" that we can use to evaluate each game idea as they come up, but I'll talk more about those in a later post. Just as a little sneak peak, our game will likely focus on AI driven game-play. Having autonomous actors in the world that the player works with to accomplish game-play objectives. That's all for now!
  10. 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) (Reading from a Vodka bottle, not a person ;)) It's currently using an external 9V battery for power. Though I'd like to devise an internal battery solution, it's difficult. There is much less room in the enclosure than I expected once all the components and wiring were in. (Lots of wires to route and cram in there.) The BAC calculation is pretty simple currently. I took the data I compiled from my many tests over this past month, and calculated a magic value that I simply multiply the voltage reading against. There's certainly room for improvements. For instance, according to my data, it's not a perfectly linear relationship between the voltage readings and actual BACs, so the magic value should modestly scale up as the voltage increases, but I haven't found a good fit yet. All things considered, my magic value method is producing surprisingly accurate readings, and if you just focus on the Summary I output (Sober, Buzzed, Drunk. Very Drunk, ect...) it's more than sufficient for what I was trying to accomplish with this project. Also I got to have some fun with my Dremel in order to customize parts of my enclosure: (35k RPM Dremel with solid carbide drill bits. Overkill? Yes. But sure was fun!) In other quite serendipitous news! On this very day, Arduino has FINALLY announced the imminent release of their official Wireless module and 1.0 library which brings wondrous high level networking support This is what I've been waiting for to get back to work on my C3 Alarm Clock. Unfortunately it took so long that I'm just about to begin development on a fairly sizable game project. So C3 will be on the back burner. Hopefully I'll find time here and there to push it forward, but it certainly won't be a quick project. I'll post more on C3 and the new game project as things progress. Anyway for today, it's just nice to have a working, finished project
  11. 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. While this was apparent to me, I wasn't sure at first how much I would have to control for it. For instance, if I take a drink of beer immediately before testing, I knew that would skew the results, but how long between drinking and testing was long enough? One minute, five minutes, thirty minutes? In my first set of tests, this proved to be an overwhelmingly important factor that all but invalidated my results. However they were useful in that they taught me how to test in the future. My second round of testing, I controlled for this by having everyone wait at least a minute between drinking and testing, and having everyone thoroughly rinse out their mouth with water immediately before testing. This clamped our values to much more linear and sensible readings as we went on. But we still had outliers throughout the night. And I discovered that: Burps produce readings similar to drinking right before testing.When you're drunk, you burp a lot without even thinking about it.This was much more difficult to control for as the night went on... (also of note, data taking became increasing difficult toward the end of the night ;) ) The other thing I found, which may or may not seem intutive, is that Breathalyzers essentially need a male/female setting. Example: when my girlfriend was blowing an 18 (don't worry what that means, I'm just using it as a point of refrence), we calculated her BAC to be ~0.123%. (Also imperically verified her as: pretty drunk). Mean while, I blew a 19, and calculated my BAC to be ~0.034%. Even after controling for all of the skewing factors, her readings simply needed to be interpreted differently than mine or the other male subjects. After discovering all of this I did some searching and found Breathalyzers are actually contested based on these exact grounds. They are bias against females, and there can be strongly mitigating factors during the test. Oh well, I can still get rough approximations, and it's still been loads of fun [cross-posted from: darkrockstudios.com]
  12. 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.) [warning: technical details ahead!] The general idea here is that the MQ3 is essentially a variable resistor. When no alcohol is applied, it is entirely resistive, letting no electricity through. As you apply more and more alcohol gas to the sensor, it's resistance drops, letting larger and larger amounts of electricity through. That current is piped into one of the Arduino's A2D pins, where it converts it to a digital number that I can then use in my code. The A2D takes a signal between 0V and xV and converts it to a number between 0 and 1023. Where xV is the Analog Reference Value: a voltage that the Arduino uses as the top end. By default 5V is used. There for if you put 5V into the A2D you get a reading of 1023. If you put in 2.5V, you get 512, and so on. The problem with "resolution" as I've called it here, is that even with what our bodies consider to be very large amounts of alcohol (like deadly levels) they are still relatively low levels to the sensor. Example: after 10 beers, my BAC is ~0.104%, aka: pretty darn tipsy. But the resistor is still only letting through 0.029V out of 5V. The solution? Shrink the range that the A2D is using for conversion. My first attempt at this used a built in function of the Arduino, to change the top end Analog Reference Voltage from 5V t0 1.1V. This is what gave me the roughly 4.5x improvement in resolution. But it still wasn't quite enough. So I began looking further into how to reduce the top end so the range has a closer fit to the values we are actually producing. I found a feature of the Arduino that allows you to supply a voltage to a special pin (AREF), and what ever that voltage is, will be used as the Analog Reference Voltage by the A2Ds. So the next step was to find the correct voltage and reliably produce it! I turned to voltage dividers. Very simple circuits, you just do some math based on the input voltage and the target voltage to determine what resistors to use in it. And it will always output the desired voltage. I calculated from my previous tests that the desired top end, for maximum resolution, would be ~0.24V. Maybe a little more to pad for outliers. In practice however this ran into real world problems. And I ended up hooking in my 10kOhm potentiometer to find the lowest voltage I could use. So far it looks like 0.5V is the lowest I can reliably use. Which is still pretty good. That will give me about half of the A2D value as usable range. Between 0 and 512. Which is a bit more than a 2x improvement on top of my first attempt. With that determined, I can begin working out the actual BAC calculations based on my readings which should finally be of sufficient resolution.
  13. 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. [media][/media] 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 16x2 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. [cross-posted from: darkrockstudios.com]
  14. 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
  15. 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 ;)
  • Advertisement