posts tagged with the keyword ‘adafruit’


In accordance with a request from organizations and people I respect, here’s a photo take on 2015-04-19 showing the packaging from an Arduino UNO I purchased from Adafruit Industries (in the United States of America) on 2010-10-19 showing the text “Manufactured under license from Arduino by SMART PROJECTS S.r.l.”.

Adafruit /

Here is the order information from that purchase. For more info, see the Hackaday post Your Arduino Packaging Could Sway a Court Case and the Adafruit post Please post old Arduino packaging that says “Manufactured under license from Arduino” #TeamArduinoCC.



Here’s my CheerLight 2012 device, which I call the CheerLCD! And what is CheerLights you say?

CheerLights is an ioBridge Labs project that allows people’s lights all across the world to synchronize, stay linked based on social networking trends. It’s a way to connect physical things with social networking experiences and spread cheer at the same time.

Much like last year, I’ve opted for a small desktop display—a USB-powered computer peripheral—rather than some giant string of multicolored lights…


With the combined power of 3D printing, affordable electronics, and the duct tape of programming languages that is Perl, we’ve developed a device that informs you of what color the CheerLights around the globe are, not only with color, but with words!

(Though we’ve not yet done extensive testing, the text should be legible even by those suffering from color blindness. Accessibility, FTW!)


The CheerLCD consists of a USB + Serial Backpack Kit and LCD Display from our friends at Adafruit Industries. But you can’t just have a display without some sort of thingy to display the display properly… enter the 3D Printer!


The CheerTree was designed specifically to hold the LCD Display. I utilized Inkscape for the design of the front plate, and then brought that shape into OpenSCAD to add the base and create an STL file for printing. (It ended up warping a bit but that just adds to the charm and aesthetic of the overall device.)

I know what you’re saying, “This is all well and good… but we need to see the CheerLCD in action!” As you wish, my friends… as you wish.

There’s some code over on github/CheerLCD, and some files on Thingiverse for the CheerTree.

Enjoy the Holiday Cheer!


Welcome to Part II of my self-awarded skill badges! (See Part I for background.)

Speaking of badges, there’s been some talk of badge systems, and some hackerspace/makerspace things happening where we might get to the point of awarding badges to members, maybe using Les Orchard’s Badger code, or maybe something else. It’s in the works… that’s all I can say right now. (And that’s pretty cool, right!?)


Programming: I will award myself the Programming badge based on the fact that I’ve gone from BASIC in the 1980s to Perl in the 1990s to PHP in the 2000s and Processing in the 2010s. That’s like 30 years of programming!

QR code

QR code: Flags on cupcakes for Bay View Gallery Night at Milwaukee Makerspace last year… Done!


Robotics: I’ll pitch Friday Night Drawbot for this one… Some of the other things I build have bot in the name, but this might be the only true robot. (Plus, I just built a second Drawbot.)


Soldering: Heck yes to soldering! I first learned to solder when I was a teenager, and I did take electronics classes in high school. I’ve learned in the last two years though that my technique was crap. No matter, it’s much improved lately. I’m only doing through-hole stuff, but I think that counts.


Welding: This one is questionable. I did a bit of welding at a demo we had at Milwaukee Makerspace, but I’m still not at the point where I could do it all on my own. I should do more welding this year…


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…


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.

« Older Entries |

buy the button:

Buy The Button

top recent artists: