Skill Badges

I decided to award myself some badges, I mean, no one else is gonna do it, right? Badges? Badges! Yeah, all those awesome badges you’ll find over at Adafruitthose badges.

And, no, I’m not the first to show some badges, and hopefully not the last either. At Milwaukee Makerspace we often refer to ourselves as “Skill Collectors” so these badges fit in nicely with that idea.

3D Printing

3D Printing: I think I’ve earned this one. While it’s true my RepRap is only (about) 80% done, I’ve managed to tame the MakerBot CupCake we have at Milwaukee Makerspace.

Bike Repair

Bike Repair: As a kid I used to fix my bike all the time. Also, when I was in college I managed to rescue a bike from a dumpster behind a frat house in Madison and re-built it into a completely usable ride.


Catapult: I seem to remember building a small catapult out of scrap wood and rubber bands when I was a kid. I’m pretty sure I scared the cat with it. (Since I have no photographic evidence I should probably try to earn this one again.)

Circuit bender

Circuit bender: I supposed I did do this thing… but let’s be honest, that was pretty simple, and again, I should do much better to earn this badge.


Drawdio!: I have built a Drawdio! I wasn’t really happy with it though, and I want to rebuild it into another device, but that’s a project for another time.

Dumspter Diving

Dumpster Diving: I’d actually have a sash full of these. Besides the bike I mentioned above, things I’ve gotten from dumpsters include: stereos, books, money, a photocopier, food, clothing, tools, and on and on and… I’ll stop before I embarrass my family any more.

(ESD) Electrostatic discharge

ESD (Electrostatic discharge): Have you ever grounded yourself by touching something metal before installing something new inside your computer? In the olden days when I had a Macintosh IIvx I used to put on rubber soled shoes, attached a wrist strap and treat RAM like it was highly explosive. Of course nowadays I install new RAM while eating pizza and sipping whiskey. (RAM also costs about 1/10 what it did back then.)

Hacked Kinect

Hacked Kinect: All I’ve got so far is that we did some 3D scanning of heads at Milwaukee Makerspace, and then reduced the complexity of the models, and 3D printed one of them. (It’s a work in progress.)


HTML 5: I’ve built more than one thing using HTML 5. The first one was probably the Evil-O-Mator.


Lasers: Although it’s been a learning process, I’m getting good results from the Laser Cutter now.


LEDs: I’ve definitely done projects with LEDs. My CheerLight is one of them.


Linux: Although it took me a few years to get into Linux, I now own about 3 Linux machines and administer 5 more. I like Linux. (Well, for servers anyway.)

Magic Blue Smoke

Magic Blue Smoke: Sadly, I have released the Magic Blue Smoke at lease once… and at least once it wasn’t my own equipment. Oops!

Metric System

Metric System: Ah, the good old Metric System! I really didn’t use it much until recently. Working in the RepRap world, and with the laser cutter, and other hacker/maker things, I’m starting to get used to it. (Sort of.)


Micro-controllers: Do Arduinos count? Does the Teensy count? Then yeah, I got this one…


Multimeter: I probably first used a multimeter in 1986, and while I still have a lot to learn about them, I can handle the basics, so that’s something.

Whew, I didn’t realize there were so many badges!

That said, I’m going to break this post into two parts, and I’ll cover the rest of my skills (or lack of skills) in the next post…


Logging the temperature and humidity (code)

Temperature and Humidity

I’m always annoyed with myself when I don’t publish my code, so this is a follow-up to my Logging the temperature and humidity post.

This whole thing is definitely a work in progress. The hardware has exposed wires, and the software is all just cobbled together pieces. Making something that works is much different than making something that will continue to work, and work properly, and efficiently. Making something that works is a first step. It’s an important step, but it’s only the first step. So let’s begin!

I started with the example from Adafruit over on GitHub and about the only changes I made was to the format output of the data.

// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain

#include "DHT.h"
#define DHTPIN 2     // what pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302)


void setup() {

void loop() {
  int h = dht.readHumidity();
  int t = dht.readTemperature();

  // check if returns are valid, if they are NaN (not a number) then something went wrong!
  if (isnan(t) || isnan(h)) {
    Serial.println("Failed to read from DHT");
  } else {
    int temperatureF = (t * 9 / 5) + 32.5;

So this outputs the value for the humidity, then a tab, then the value for the temperature, and then a line return. Oh, I did change the code to output the temperature in Fahrenheit instead of Celcius. If we get a bad value, it’ll print “Failed to read from DHT” though I’ve yet to see that in the log files, I should probably take it out. Also, the Arduino just streams data at a fast rate, much faster than I need. I typically put the sleep functions (to limit the amount of data logged) in my reading code which runs on the computer. I think this is the right way to go, but if you have other ideas, please let me know.

Here’s a fairly simple Processing sketch that will read the data coming in from the Arduino. (Obviously you need the Arduino connected to the computer via USB.)

import processing.serial.*;

PrintWriter output;

Serial myPort;    // The serial port: 
PFont myFont;     // The display font: 
String inString;  // Input string from serial port: 
int lf = 10;      // ASCII linefeed 

void setup () {
  // set the window size:
  myPort = new Serial(this, Serial.list()[0], 9600);
  // don't generate a serialEvent() unless you get a newline character:
  output = createWriter("output.txt");

void draw () {
  // everything happens in the serialEvent()

void serialEvent (Serial myPort) {
  // get the ASCII string:
  String inString = myPort.readStringUntil('\n');
    String[] words = split(inString, '\t');
    String humid = words[0];
    String tempe = words[1];
    text("   Humidity: " + humid, 40,90);
    text("Temperature: " + tempe, 40,160);

   output.printf("%d-%02d-%02d %02d:%02d:%02d\t%s", year(), month(), day(), hour(), minute(), second(), inString); // Write to the file
   output.flush(); // flush output

Besides displaying a small window with the humidity and temperature (seen at the top of this post) it will also log the data to a file named output.txt

Processing Output

2011-07-25 19:09:14     44      91
2011-07-25 19:09:14     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:16     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:18     44      91
2011-07-25 19:09:18     44      91

This is pretty terrible, as we’re getting way too much data. I should probably add some delay into the Processing sketch, as it’s creating a log file line much faster than the sensor can even output data! This will result in large log files and is just wasteful. If all I wanted was the window showing the current temperature and humidity, I’d probably just delete the logging part of the sketch. Add that to the TODO list. Anyway, it works, and as a proof of concept, it’s a start.

Here’s the Perl code I was using:


use Device::SerialPort;
use IO::Handle; FILE->autoflush(1);
my $port = Device::SerialPort->new("/dev/tty.usbmodemfd411");


my $fileout = './templight.log';
my $filerec = './templight-recent.log';

open (FILE, ">>$fileout") or die ("Ooops! Could not open $fileout: $!");

while () {
    # Poll to see if any data is coming in
    my $char = $port->lookfor();

    # If we get data, then print it
    if ($char) {
	$time = localtime(time);
	if (length($char) > 1) {

		my $str = ($time . "\t" . $char . "\n");
		print FILE $str;

		open (FREC, ">$filerec") or die ("Ooops! Could not open $filerec: $!");
		print FREC $str;
		close (FREC);
    # Uncomment the following lines, for slower reading, 
    # but lower CPU usage, and to avoid 
    # buffer overflow due to sleep function. 

    sleep (10);
close (FILE);

The logging here is a little better than the Processing sketch, at least we add some delay with that sleep at the bottom so our log files won’t be quite as large. We’re saving to two files, templight.log and templight-recent.log. The second one just saves the current data, this just enables us to grab the data from that file and do something else with it, like… send it to Twitter or something.

Perl Output

Tue Jul 26 04:30:39 2011        46      89
Tue Jul 26 04:30:49 2011        46      89
Tue Jul 26 04:30:59 2011        46      89
Tue Jul 26 04:31:09 2011        46      89
Tue Jul 26 04:31:19 2011        46      89
Tue Jul 26 04:31:29 2011        46      89
Tue Jul 26 04:31:39 2011        46      89
Tue Jul 26 04:31:49 2011        46      89
Tue Jul 26 04:31:59 2011        46      89

So our output from Perl looks similar, though we have much less data (but still plenty of data) and the date format is a little different. (Chalk that up to laziness.) Oh, the Perl code also has the serial port hardcoded to /dev/tty.usbmodemfd411, which is lame, and I do have code somewhere to grab the serial port dynamically, but I didn’t implement it yet.

Whew! It feels so liberating to publish all that terrible code… (I mean my own code, not Adafruit’s!) Now I feel the need to start re-writing it and making it less terrible.


Logging the temperature and humidity

Adafruit DHT22 temperature-humidity sensor

Last November one of the Arduino-based projects I started working on was a temperature logger for the office. With winter coming up I wanted to see just how cold it got. (The office is in a converted attic, and the heating and cooling leaves much to be desired.)

I picked up a TMP36 – Analog Temperature sensor and got it wired up and wrote some hacky perl code to read the data and log it. I never really got it out of the experimentation stage, and ended up pulling the Arduino out for another project. (Isn’t that often the case!?)

So last month when Adafruit came out with the DHT22 temperature-humidity sensor I figured I should grab one, and maybe I’d get around to finishing the project.

My temperature (and humidity!) logger is still not done, but I did whip up something to run this week while Wisconsin is having a heat wave. The office has a window air conditioning unit, but it only runs when someone is in the office. When no one is there, it gets hot. How hot? Well, now we know….

Time Humidity Temperature
00:00 50% 89°F
00:30 50% 89°F
01:00 50% 89°F
01:30 49% 89°F
02:00 49% 89°F
02:30 49% 89°F
03:00 48% 89°F
03:30 48% 89°F
04:00 48% 89°F
04:30 48% 89°F
05:00 48% 89°F
05:30 48% 89°F
06:00 48% 89°F
06:30 49% 89°F
07:00 57% 89°F
07:30 58% 89°F
08:00 53% 91°F
08:30 52% 91°F
09:00 52% 91°F
09:30 52% 91°F
10:00 52% 91°F
10:30 52% 91°F
11:00 52% 91°F
11:30 52% 93°F
12:00 52% 93°F
12:30 52% 93°F
13:00 51% 93°F
13:30 51% 95°F
14:00 50% 95°F
14:30 50% 95°F
15:00 50% 95°F
15:30 50% 96°F
16:00 50% 96°F
16:30 50% 96°F
17:00 49% 96°F
17:30 50% 98°F
18:00 48% 96°F
18:30 43% 93°F
19:00 41% 91°F
19:30 40% 89°F
20:00 41% 87°F
20:30 39% 89°F
21:00 37% 89°F
21:30 42% 86°F
22:00 40% 86°F
22:30 39% 86°F
23:00 39% 84°F
23:30 37% 84°F


The hard part of the code is provided by Adafruit’s DHT-sensor-library and their DHTxx Sensor Tutorial was also useful. And just for fun we dug up another old bit of perl which was wired up to SuperTweet.Net so we could send the data out via the 2XL Networks Twitter account.

2XL Networks - Logging

I should really get around to finishing this project, since I have a spare Seeeduino that would be a good fit for it. I can always feed the data into Pachube or roll my own logging application.

I’m really just hoping the heat wave ends and it doesn’t get up to 98°F in the office again…

Update: See the post: Logging the temperature and humidity (code)


Getting Started with the Atmega32u4 Breakout Board+

Atmega32u4 Breakout Board+

I’ve talked about Adafruit’s Atmega32u4 Breakout Board+ before, first in my post Teensy vs. Atmega32u4 Breakout Board+ and then in the post The Future of Open Source (Part II), so I figured I should actually get a Atmega32u4 Breakout Board+. (Also, I’m just going to call it the Atmega32u4 from now on.)

Now as far as AVR development, I’m a guy who doesn’t like to stray too far from the Arduino world, partly because I find it fun and comfortable, and it does most of what I’ve needed so far. That said, I did end up dabbling with the Teensy for The Button.

Don’t get me wrong, the Teensy is awesome for what it does, and what it is, but occasionally my open source bias takes hold and it bothers me (just a little bit) that the Teensy is not open source. Of course, Adafruit’s Atmega32u4 is open source, which gives it a few more points in it’s favor. Price-wise, the Tensy is $16.00 and the Atmega32u4 is $20.00. Consider it the “open source tax” if you will. (Or buy 100 of them and they’re only $16.00 each then!) (Update: Actually, the Teensy with pins is $19.00 and the Atmega32u4 Breakout Board+ with pins is $20.00, which is even closer in price. You can buy the Teensy without pins at $16.00 but you can’t buy the Atmega32u4 Breakout Board+ without pins.)

So with an Atmega32u4 in hand, and from the perspective of someone who used a Teensy successfully, here’s my review.

Atmega32u4 Breakout Board+ (Close-Up)

You’ll want to start with the Atmega32u4 product page. Without that, I’d still be watching a pulsating LED and swearing.

Read the section titled “Why not use a Teensy” and decide if you really want to use the Atmega32u4 instead. Done? Good. If you still want to use the Atmega32u4, continue reading!

The next section I’d call your attention to is the Using Teensyduino section. As I said, I’m an Arduino guy, so I wanted to give Teensyduino a try. Teensyduino is a software add-on for the Arduino IDE. It adds the ability to build and run sketches on the Teensy. If you don’t want to install avrdude or deal with command line stuff, this is another option. I’m not against using avrdude, but I wanted to try to parallel my Teensy experience, so Teensyduino was part of the toolchain.

I had already installed Teensyduino for use with the Teensy, so the section on that topic was where I jumped in. I walked through the changes, from editing boards.txt to restarting the Arduino IDE. It didn’t work.

But wait! There’s a line that says “Download the Arduino IDE from – as of this tutorial, IDE v21 works best – its not the latest one so scroll down to find it.” And yes, I’m running IDE v22. I’m not sure if that’s what broke things, but rather than download version v21 and try the edits again, I just grabbed the “ready to go” dmg that Adafruit supplied. Since I already had the Arduino IDE in my applications folder, I just renamed it to “ArduinoAtmega32u4” and ran it. It worked!

So the software installation/configuration part was a bit more difficult for the Atmega32u4 than for the Teensy, at first, but not much of an issue in the end.


So here’s a simple blink sketch, slightly modified from one that worked with the Teensy. The one issue with the Atmega32u4 is that you need to press the reset button on the board before you upload a sketch. Each time. Adafruit mentions this, so it’s not a surprise, but you just need to remember to do it. If you use a Teensy or an Arduino all the time, you might forget.


So the next test was to make the Atmega32u4 emulate a USB keyboard, just like the Teensy can do. You’ll need to change the menu options, but besides that, it worked well. At this point, with everything working, the differences between the Teensy and the Atmega32u4 seem pretty minimal. Granted, I’m not doing anything complex here, but it’s good to know that I could easily swap out the Teensy for the Atmega32u4 in some situations.

Here’s the code I used, which prints a space, similar to what the Teensy does for The Photo Booth:

void setup() {

void loop() {
  // Your computer will receive these characters from a USB keyboard.
  Keyboard.print(" "); 

  // typing too rapidly can overwhelm a PC

So now that I’ve got an Atmega32u4, and know what it can do, the only thing left is to let the hacking begin! :)


The Future of Open Source (Part II)

Open Source

In our first piece, The Future of Open Source, I talked a bit about hardware, and touched on community, as well as mentioned a few specific companies. This time I’ll talk about specific pieces of hardware.

Let’s start with the Arduino. The Arduino is probably the most successful piece of open hardware. There’s an estimate of 300,000 Arduinos “in the wild” as it were, and if that does not count “official” Arduinos, I can see that number easily being double.

Recently Phillip Torrone published an article titled: Why the Arduino Won and Why It’s Here to Stay:

While it’s nice that Arduino is open source, and commercial use is allowed if you make a clone, it’s not the biggest reason, which is why it’s down near the end of the list. However, that isn’t to say it doesn’t matter at all. Specialized derivatives can be made without paying someone or asking anyone. It’s open source hardware so a company or school can use it without any per-seat licensing. There’s no risk that it will be discontinued and the software gone forever. If you want a new feature, you can spend the time and get it added. When thousands of people have a small stake in something, or ownership, they care more. Does anyone even debate if open source software is a good idea any more?

I think part of the reason the Arduino (and its clones) have flourished is due to the community built around it. Thanks goes out to the people who are really into doing things with Arduinos, and sharing their work with others, and helping out on the forums, and teaching classes, and basically connecting with others and evangelizing the Arduino platform.

The first Arduino I purchased was the “official” Arduino Uno, which I acquired from Adafruit Industries. I remember finding out about Adafruit from the web site, run by Limor Fried (Lady Ada) who runs Adafruit. The fact that she had shared so many project details online led me to her business, and I became a customer. My Uno is what I consider my “top of the line” Arduino, and I feel pretty confident that it will work with any shield I get, not have any weird quirks to work around, and that buying it supported the Arduino project. Chances are when a new “official” version of the Arduino comes out, I’ll but that one as well.

I do have other Arduinos, like the Boarduino, also purchased from Adafruit. I wanted another Arduino, at a lower cost, that I could dedicate to a project. It fit the bill, and supporting Adafruit was something I felt good about doing. I’ve also got a Diavolino, from the folks at Evil Mad Scientist Laboratories. As I mentioned in my blog post, The Diavolino comes in at about $13—less than half the cost of an Uno—though there are some compromises with the Diavolino. If these compromises don’t affect you, it’s a nice little Arduino board. And as for the folks at Evil Mad Scientist Laboratories, they’re pretty awesome, just like Adafruit, and I feel good supporting them.

Now we move away from the US and over to China. I’ve got two “Seeeduinos” from Seeed Studio. I know some people would prefer not to buy from China, and if these were cheap knock-off products from a questionable company, I’d agree, but Seeed Studio seems to be a pretty well respected member of the open hardware community. They were a sponsor of Maker Faire, they helped with the radiation detection project after Japan’s Fukushima incident, and they actually develop a number of innovative products. If all they did was make a cheaper Arduino, I probably wouldn’t be as supportive of their efforts. As it is, I think they provide some friendly competition for others in the Arduino space, and do plenty of other things to be a good citizen of the open hardware community.

I’ve already mentioned the Evil Mad Scientist Laboratories gang, and their Diavolino, but I’ll also talk about the Egg-Bot. I bought the Egg-Bot kit because I think it’s awesome. Here’s the description of it: “The Eggbot is an open-source art robot that can draw on spherical or egg-shaped objects.” See? Awesome! (I’m sort of a fan of art robots.) Now, the Egg-Bot is awesome, but it’s an open & shared kind of awesome. Every time I demo it, I explain to people that it’s an open source device, and you can download the software for free, and you can download the plans to build your own for free. I’ve see a SphereBot, a Completely printable Eggbot, a Fischer Technik Eggbot, and an EggBot Makerbot Attachment over on Thingiverse, as well as many Egg-Bot design files. (Heck, you could even make an Egg-Bot out of LEGOs.)

The point of all this is, the Evil Mad Scientist guys aren’t out to crush anyone who tries to make an Egg-Bot… they encourage it. They’ve grown a community of users who help each other out, sharing what they’ve learned along the way. This helps make people fans of Evil Mad Scientist Laboratories, and the Egg-Bot, and be more willing to support their future endeavors.

But hardware, just like software, and life itself, is often a compromise, consisting of grey areas, like the Teensy. While I used a Teensy for The Button, and it was perfect for it, I still hope to move to an open source alternative if possible. I covered most of this in my Teensy vs. Atmega32u4 Breakout Board+ post. I’ll get my hands on an Atmega32u4 Breakout Board+ and see how it stacks up against the Teensy for future projects.

So where does that leave us, and the future of open source? Personally, I see open hardware as a choice sort of like buying food. You can choose to support companies you know, like, and trust, and you can even go to the local farmer’s market and talk to the people who make the food. I hate to use the word “sustainability” (only because I think it gets overused) but I think it fits. A sustainable future through open source. Works for me…