Jump to content

  • Log In with Google      Sign In   
  • Create Account

Wavesonics Pseudo-Random Journal Generator

RSS Needs

Posted by , 18 May 2012 - - - - - - · 1,009 views

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.
Posted Image
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.

C3 :: From Prototype to Production

Posted by , 22 February 2012 - - - - - - · 819 views

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.

C3: Prototype Testing

Posted by , 25 January 2012 - - - - - - · 864 views

Good news everyone! I've reached prototype stage! And I've got a video to prove it!


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!

C3: Wireless Sensors!

Posted by , 19 January 2012 - - - - - - · 562 views

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.

Posted Image

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.

Posted Image

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.

Posted Image

Anyway, that's it for now, I should have a working prototype very shortly!

C3: From the ashes!

Posted by , 09 January 2012 - - - - - - · 789 views

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!

Getting things moving

Posted by , 20 December 2011 - - - - - - · 493 views

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!

MQ3 :: Completion!

Posted by , 30 November 2011 - - - - - - · 535 views

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)

Posted Image
(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.

Posted Image
(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:

Posted Image
(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 :D 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 :)

MQ3 :: Testing Practices and Breathalyzers

Posted by , 10 November 2011 - - - - - - · 559 views

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]

MQ3 :: Greater Resolution

Posted by , 04 November 2011 - - - - - - · 458 views

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.
Posted Image
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.

MQ3 :: A quick project

Posted by , 27 October 2011 - - - - - - · 796 views

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 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]

C3: The bad news and the good news

Posted by , 03 October 2011 - - - - - - · 738 views

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 :)

C3: Connection Durability Win

Posted by , 16 September 2011 - - - - - - · 732 views

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 ;)

C3: NTP FTW! (And other acronyms)

Posted by , 04 September 2011 - - - - - - · 783 views

LLOONNGG week of packing, moving, and unpacking. Still not done unpacking. Probably won't be fully unpacked by the time we move again :P Oh well.

ANYWAY! Onward and upward!

Posted Image
[ 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:
Posted Image

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 :P

C3: Misery and Progress

Posted by , 29 August 2011 - - - - - - · 1,164 views
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!)

Posted Image

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. <- these pins don't even exist on the original Arduinos!

This was a deep rabbit hole the wasn't helped by my ignorance of underlying hardware. Most Ardunio hobbyists never need to get this deep into the micro-controller at the heart of the Arduino, so I initially wasn't trying to learn all about it, I was just trying to solve the problem. And I wasted a *lot* of hours going down this vein. After two days of researching the problem, banging my head against a wall, investigating other WiFi chips and even other micro-controllers entirely, the project was in real danger. But I finally had a break through. I pieced together a solution from many different forum posts and a deeper understanding of the hardware and the problem at large.

It ended up being both a hardware and a software fix. And I had to mutilate my beloved WiFi board a little :(

Posted Image

This was not a fun excursion. But I hope it clears the the path for some smoother sailing. Next I'm going to try to make the Arduino keep time using NTP (Network Time Protocol) for synchronization. And after that work on pulling events from a Google Calendar. So stay tuned, and I hope to keep these posts shorter :P

C3: Prepping for serious dev

Posted by , 27 August 2011 - - - - - - · 692 views

The next real step forward was to begin working on the networking and time keeping. But those steps were the beginning of what is to become a real software project. Still small to medium sized compared to PC projects. But it will have a level of complexity that Ardunio projects don't usually achieve. What this means is the Arduino IDE would be wholly unsuited for developing it. I ran into this a bit with the Robot project. Towards the end of development as some complexity emerged with the socket communications, it got fairly difficult to manage in the Ardunio IDE.

My solution was to fall back to my trusty C++ IDE Code::Blocks.
Posted Image
I love this IDE, so light weight, cross-platform, and infinitely configurable. C::B has some high level support for AVR projects (that's the architecture of the micro-controller that the Arduino uses), but it's really a thin veneer. All of the guts, GCC-AVR and others, must be setup on your own.


I was following spotty tutorials written for much older versions of every piece of software in the chain. I had to extract AVR-libc and the Arduino Core lib from the Arduino IDE, get headers, do all sorts of fun stuff that Arduino clearly never intended for you to do. But in the end, I got it all compiling, burning, and running from within C::B. I even got C::B auto-resetting the hardware prior to burning! (Something none of the tutorials managed to do!)

I'll tell you, when I got my own code without any of the Arduino auto-magical trickery running on that chip:
int main()

            // Insert celebration here

That was a gooooood day.

So with everything ready to go, all set for serious software development, I began looking into the networking. Dusted off my old networking WiFi shield (Arduino speak for daughter board) and began loading up all the libraries. I got a basic web server test running, and then went on to compile in more feature in the library. And all of a sudden, cla-thunk! My program wouldn't upload. Scrolled through the build log and found "Memory out of range". Crap... opened up the /bin directory of my project and saw the .elf file's size at 33KiB. The Arduino only has 32KiB of program memory...

After playing with stripping & size optimization options, and weighing if I really needed those library features that had pushed me over the limit. I concluded that I needed a new micro-controller with more memory. Luckily Arduino's come in several flavors! After a quick look-see, I decided on the new Arduino Mega 2560. It's based off of the newest Arduino, the Uno, has 8 times the program memory, and MANY more I/O pins. But other than that, it's identical to my current one. Which means it can be a slot in replacement, and I don't have to change any of my plans :)
Posted Image

So I'm waiting on that to be delivered before I can continue.

That's all!

My Picture

Recent Entries

Recent Comments