ThingM at Maker Faire 2010

My company ThingM had an official presence at Maker Faire this year. We were showing off the BlinkM line, including the new BlinkM MinM and the LinkM USB BlinkM controller. It was a lot of fun. And packed!

ThingM at Maker Faire 2010
(click any photo to go to larger version on Flickr)

We were in the Maker Shed building, right underneath the Arduino banner, so we got lots of awesome questions about Arduino. The most common: “So I just picked up this thing that says ‘works with Arduino’…well, what *is* Arduino?” It was so great to see so many people interested in building their own gizmos.

ThingM at Maker Faire 2010 ThingM at Maker Faire 2010

By far the most fun demo we had was TwitM, the Twitter-controlled BlinkM. Using LinkM, a couple BlinkMs, and a Processing sketch, I had it so anyone who tweeted anything with the keyword “makerfaire” made one BlinkM flash. If you tweeted “blinkm colorname”, where colorname was any color in the X11 color names or a hex color code RRGGBB, the other BlinkM would turn that color. Because of the streaming Twitter API, these changes happened instantly; it was really something to see.

ThingM at Maker Faire 2010 ThingM at Maker Faire 2010

Kim and Mike made up some really nice “walltext” describing the various demos we had up.

ThingM at Maker Faire 2010 ThingM at Maker Faire 2010

A big hit was MaxM controlling RGB LED flexible circuit tape, using the same techniques I used for the Crystal Monster.

ThingM at Maker Faire 2010 ThingM at Maker Faire 2010

This was about regular busy at the Faire. There were many times when it got way more packed.

MobileMe Free: iPhone to iCal OTA syncing

I’ve been frustrated with my calendars not being in sync between my iPhone and my Mac’s iCal. I’ve inadvertently double-booked myself many times. I didn’t want to spend $99 a year for MobileMe because I already spent a lot on remote servers and don’t need most of what MobileMe offers. I just want calendar syncing. The below has been described by many others, in much greater detail and clarity. This is really a list of things I did so I can remember it.

The essential idea is both iCal and the iPhone Calendar program can talk to a CalDAV server, much like Mail.app and iPhone Mail can talk to an IMAP server. Google Calendar is a CalDAV server, so let’s use that, since it’s free and already set up. If you already have a CalDAV server, you can use that instead as the intermediary.

1. Create calendars in Google Calendar

Sign into Google Calendar and set up however many calendars you want. Once you do that, go to the bottom of the settings details for a particular calendar you’re interested in and note its “calendar address”:

2. Set up iCal to sync with Google Calendar

In Preferences in iCal, go to Accounts, click the “+” to add an account, and choose “Google” as the account type. Fill in your info.

Click on the “Delegation” tab for the newly created account, and pick which other calendars you want besides your main one (if any). You’ll see them in a separate list in the calendar list pane.

Now you have calendars that sync between iCal and Google Calendar.

3. Set up iPhone to sync with Google Calendar

On the iPhone Settings app, go to the “Mail, Contacts, Calendars” section and scroll down to “Add An Account…”. Choose “Add CalDAV Account” and fill in your Google Calendar login info.

If you just have the one main calendar on Google Calendar, that was the last step, you’re done and any changes you make on the iPhone will get send to your Google Calendar, which iCal will then pick up. And vice-versa. If you want to add one of the secondary calendars, you have one more step.

4. Adding a “delegate” Google calendar to iPhone

To add secondary Google calendars (what iCal calls “Delegates”), you need to do step (3) again. Then with this second CalDAV account on the iPhone, go into its “Advanced Settings” section of that account’s information and edit the Account URL. Replace the “username@gmail.com” part of the URL with the Calendar address you noted down from step (1).

That is, the full CalDAV URL for my main Google calendar is:
https://www.google.com/calendar/dav/tod.kurrt@gmail.com/user
and the full CalDAV URL for my “things-to-do” calendar is:
https://www.google.com/calendar/dav/c96o9s8ne6fb070cle0frp8e58@group.calendar.google.com/user

You’ll probably find it easier if you email yourself this URL from your computer, pull it up on your phone, and use copy-n-paste to enter it.

BristleBots and LED throwie art at Crash Space!

This upcoming Tuesday, 9 March 2010, 8pm at Crash Space in Culver City, we’ll be having some fun quick DIY projects for you to build. Come on over and have fun with us. The project kits are $5 for CrashSpace members or $10 for non-members and you can take them home after you build them.

In the kit you get the parts to build your own Bristlebot, a tiny robot made from a toothbrush:
Crash Space bristlebots
(consists of toothbrush, pager motor, battery, and foam tape)

and LED throwie art:
Crash Space LED art throwies
Crash Space LED art
(consists of two color-changing RGB LEDs, battery, and a magnet)

We’ll have a Bristlebot race track you can do time trials on:
Creativity Lab  at TEDActive2010

And we’ll be showing you how to build all of this, no previous experience required. Come build bots and lights!

Momentary Button as On/Off Toggle using 555

(as a few had noticed, I had an error in the schematic shown. It’s been updated, thanks!)

A recent question from a friend who made a really cool BlinkM hoodie was: How can you turn a momentary button press into an on/off toggle?

There are tons of ways to do this if you like getting into electronics. Most all work off of some flip-flop like principle. And while I could have suggested a true flip-flop chip, I thought it would be cooler if you could use a 555 timer chip (which contains a single flip-flop and a couple of comparators). After scouring my childhood collection of Forrest Mims electronics books and a few 555 timer devoted websites (two of the best I found were: http://www.bowdenshobbycircuits.info/ & http://www.kpsec.freeuk.com/555timer.htm), I cobbled together the following circuit based off a few almost-what-I-wanted examples.

This is what it looks like in use:

The schematic is pretty straightforward, but does use a bit of feedback trickery to get the toggle functionality:
On/off toggle switch from a momentary switch using 555
(old incorrect version here)

The parts cost is pretty low. The 555 timer chip can be had for about $0.43, the 2N3904 transistor for ~$0.40, and various resistors & capacitors are essentially free if you have them.

The circuit has 3 external two-pin connections: 5V&Gnd, button input, and the two pins of the thing to switch. In this case, the switched thing is a power supply to a BlinkM.

By changing the transistor to a beefier one, you can switch much larger loads. The little 2N3904 transistor in there now can switch around 200mA, but a bigger NPN or FET transistor and you could switch a few amps.

It can be made pretty small on a tiny breadboard (courtesy of FunGizmos.com) like this:
Simple on/off toggle from a momentary switch

It’s not the greatest for battery-powered applications. When “off” it draws about 4-6mA, depending on the brand of 555 timer chip you use. When on it draws that plus whatever power the switched device draws. Best to put a proper power switch on the battery pack to eliminate this quiescent drain.
On/off toggle switch from a momentary switch using 555

I2CScanner.pde: Arduino as I2C bus scanner

One of the challenges of working with I2C (aka “two-wire” or “TWI” or “Wire”) devices is knowing the I2C address of the device. Older devices have a fixed address, or a “choose one-of-four” approach. But newer I2C devices have fully programmable addresses, leading to cases of not knowing what address a device is at.

Fortunately, there’s a technique one can use to “scan” an I2C bus and determine these addresses. Conceptually it’s very similar to a network “ping”. Below is an Arduino sketch “I2CScanner.pde” that turns an Arduino into an I2C bus scanner.

- I2CScanner.pde — Turn Arduino into I2C bus scanner

When loaded up on an Arduino, the sketch will immediately scan the I2C network, showing which addresses are responding.

i2cscanner-out

For example, the above output is from an I2C bus with four slave devices on it (one BlinkM MaxM, three regular BlinkMs).
I2CScanner with BlinkMs
(Notice the 2 pull-up resistors on SDA & SCL. This is needed for longer bus lengths)

One thing to notice about the I2CScanner output is that although there are four devices on the bus, only three addresses were detected. This is because unlike IP networks and “ping”, you can’t tell if two devices have the same address. They’ll both respond to commands sent to them just fine, you just can’t read back data from them.

How it works

In I2C, the first byte transmitted/written by the master to a slave is the address of the slave. If there is a slave at that address, the slave will signal the I2C bus, otherwise it leaves it alone. We can use this to implement a bus scanner.

The Arduino “Wire” library utilizes a set of C functions called “twi.c”. One of those functions is “twi_writeTo()”. This function is used to both send the address of the slave down the bus and also to write data to slaves. It returns 0 if it was able to successfully transmit a byte or non-zero if it couldn’t. Since the very first write to a slave is its address, a very simple bus scanner using it would be:

void scanI2CBus(byte from_addr, byte to_addr) {
  byte data = 0; // not used, just a ptr to feed to twi_writeTo()
  for( byte addr = from_addr; addr < = to_addr; addr++ ) {
    byte rc = twi_writeTo(addr, &data, 0, 1);
    if( rc == 0 ) {
      Serial.printl("device found at address ");
      Serial.println(addr,DEC);
    }
  }
}

In the I2CScanner sketch, this function is extended a bit to support a callback function. The callback function is called with the result of every address scan. In I2CScanner, this callback function is called "scanFunc()" and just prints out "found!" or nothing, but it could be modified to do more complex tasks like doing additional I2C transactions to figure out what kind of device it is, or setting all the devices to a known state, etc.

Too Much RFID

[This post was part of a CrashSpace mailing list discussion on a "proximity t-shirt": a shirt that would light up or similar when other similar t-shirts were nearby. People were wondering how good RFID was at localized detection of tags.]

Okay so I’m a big RFID nerd, did a lot of consulting work using it. So here’s a quick brain dump.

Regular passive RFID is designed for identification not localization. The RFID tags can be reliably read only to within a few centimeters. But the readers are cheap. You can get 128kHz (LF) and 13.56MHz (HF) RFID readers for $20-40 and the reader chips themselves for under $2. RFID tags that work with these systems are around $1. These systems typically cannot handle multiple tags in the reader’s field at a time.

UHF (900MHz-2.4GHz) passive RFID readers can read up to a few meters, and the tags can be a $0.05 in large quantities. The readers can get pretty expensive though: >$1000. These are the systems used by Walmart et al to read a palette of Mach3 razors as they transit the warehouse. And by the marathon race timers. The standard is called EPC, if you’re interested. These systems can handle a few hundred tags in the reader’s field, but read time goes down exponentially with tag count.

“Active RFID” has ranges up to hundreds of meters. The term “active RFID” is a bit loose, since one can describe a WiFi laptop or a cellphone as active RFID tag. Really it just means an RF radio system that transmits a unique ID using its own power source. There are active RFID versions of all the above technologies. Eric’s suggested use of the RF Link boards is essentially an active RFID beacon. One of my favorite active RFID designs is OpenBeacon (http://www.openbeacon.org/ ). It uses the ubiquitous Nordic RF chips (used in almost every wireless keyboard & mouse) Sparkfun has a ton of Nordic boards to play with.

“Localization” of RFID tags can mean two things. For normal passive RFID, the tag is “located” when a reader sees it. It’s a boolean: sees it / doesn’t see it. This is often called “proximity detecton”. So one way to approach localization is to just have a lot of readers. True localization (knowing where in a reader’s field-of-view a tag is) is pretty tricky. The main issue is just finding how far away an RF source is. The simplest is signal-strength (”the louder you are the closer you are”), but that falls prey to the non-homogeneity of the environment: in free space it would work; in a room full of RF-absorbing humans, it fails. If you’re really savvy, you can do time-of-flight calculation. The reader sends out a ping and measures the time it takes to receive the tag’s echo ping. This requires nanosecond-accurate clocks on the reader (speed of light is very fast) and falls prey to multipath distortion (reflections off the environment). And then you need multiple antennae for a single region to do triangulation. It’s hard, but RFID vendors are starting to release stuff.

Scary Shifty Servo Eyeballs

If you want a slightly different look for your Halloween pumpkin or skull, you can pretty quickly whip something up with a few servos and an Arduino. Here’s a set of Scary Shifty Servo Eyeballs, for instance:

It looks around randomly…what’s over there!… wait, what’s that!

As you can probably tell it’s a pretty simple arrangement (click for bigger):
Scary Shifty Eyeballs

Scary Shifty EyeballsScary Shifty Eyeballs
Continue reading Scary Shifty Servo Eyeballs