Nuit Blanche badge recap

So, the code will come. I promise that.

I had a fun 24 hours just before Nuit Blanche. I had this crazy idea of taking the SoonCon badge which we (@saeruaisu, @jjstautt & me) built and programmed in 2011 and seeing if I could up the ante a bit on it. Find a couple of analog inputs, and have my iPhone send data to it in order to allow me to send tweets and other live data to the badge.

@jjstautt did a great job soldering the heads onto the end of a repurposed pair of headphones (sans headphones) and I bought a splitter so I could listen to the data as I sent it to the badge to make sure the computer was transmitting correctly.

[caption id=”” align=”alignnone” width=”485"]

Badge connected to laptop for testing with splitter and earphones to hear signal. (dit dit dit dit)[/caption]

Now, the theory behind how I would send signals was to use the right ear as a clock pulse of sorts and the left ear as the data line. When the right ear had a signal, it meant that the arduino should listen to the left until the right ears signal goes down, if the left goes on for a set period of time (is up and not just noise), then the signal is a 1 and reflect that in whatever code that exists in the arduino software.

This alone was a bit of a pain in the butt. Took me a while to find a sound that the arduino would recognize reliably, as well as get it to not hear noise as the right or left ear turning on. My code is awful, but when I github it you’ll see the generla methodology I used for it. Having a variable I could fiddle to determine the best time to wait for the signal to be marked as on for both ears.

Once I had this in place, I simply made it so the clock pulse would iterate through the screen turning on or off the lights as per the signal. Since the fastest pulse I could reliable send to the arduino and have it receive it was around 0.15s, I could really only get about 8 bits per second to the arduino. When painting the screen, this lead to a refresh rate of approximately 15 seconds. Nowhere near fast enough to simply drive the badge with the iPhone.

Regardless, I trudged forward and programmed in xcode (I will also post this on github) a simple application that would let me draw “HI :)” and “< 3” on the phone as well as a few simple test patterns. Once I was confident that the data channel was solid and, in general, fault free. I went to sleep Friday night. Leaving a wonderful video for everyone showing I had the basic proof of concept working. Yes in this video that is xCode’s iPhone simulator running the badgeduino.

[vimeo 50415415 w=500 h=281]
iPhone / Arduino sound modem project “Hello World!”

The next day I decided to continue on with this project, but to get it so I can send tweets effectively to the arduino badge, I would need to be able to send letters to it and not simply draw on the screen one bit at a time.

So, I added a special command where the left ear would send sole signals without the right ear at all to tell the arduino to go into “COMMAND_MODE”. This meant that the next 4 bits would be a command to do something or switch to some other mode of receiving. 1111 meant go back to the start, and 1000 went to what I refer fondly as “TEXT_MODE”. Now, there was intended to be the possibility of sending more commands, but I hit a pain in the butt hiccup which meant my code was too big for the badgeduino.

TEXT_MODE worked as follows. Each letter was 6 bits. This allowed me to have every letter of the alphabet and ! , . @ # . I forgot about the numbers, but by the time I hardcoded all the letters into the arduino code I ran out of usable space on the badgeduino and couldn’t have added them if I wanted.

When 111111 was received by the badge, that meant the message was complete, and that it should start scrolling it across the screen. I programmed a text box + button into the xcode and it worked wonderfully. I could type a long message and it would send it, slowly, to the arduino and it would scroll nicely across the screen.

However, it was at this point that I started seeing bugs appear since I was actually using more space on the arduino for the badge than there was space to store, so the code didn’t quite respond correctly and it would simply crash. I’m betting with some work I could optimize the code and get more onto that board, but at this point it was 6:30 and I still wanted to get tweets working in the xCode.

For the next 1 1/2 hours, I realized how pitiful the documentation was for the newest version of xCode around Tweets. I thought I had something working, but by the time I uploaded it to the phone, it would crash everytime I tried to get tweets.

So I came up with a plan so we could all get going. I would copy and paste any tweets sent to @kjrose so they would scroll across the screen. I got a few people asking me to put things that scrolled across, but it wasn’t as spiffy as having it run live.

I think I’m going to play with it some more for next year. Maybe turn it into a distance detector for @saeruaisu’s and @jjstautt’s phones pointing in the direction they are in from my iPhone making sure we don’t get lost now that I have the communication working.

Perhaps next year we can get some more of these badgeduinos (or build a better one that can handle a bluetooth adaptor so I don’t have to use my fancy, but somewhat noisy channel over the speakers) and get a larger crowd with these plugged into their phones.

Regardless. It was good fun, and I will get the code up hopefully this week. I just want to add some comments so it’s not all entirely badly written in a rush code. (remember I only had 24 hours from when I first got started on the idea to NB.)

Have fun everyone. Oh, and if anyone knows where to get the badge design for the SoonCon 2011 badge, let me know. I’ve very tempted to upgrade it for next year.

KJR