Going mobile

Massive, massive success tonight. Finally took the leap to get the iPhone setup. It was a hold your breath kind of night. A few hiccups. One, I had trouble finding the right ground pin. What I was told in some of the blogs wasn’t giving me the 3.3V that I needed to power the XBee. I finally settled on pin 15 which I found referred to as a valid ground. Second, I forgot to change the serial port identifier to the iPhone (/dev/tty.iap). Patience. Got those items fixed and was good to go. Got it to work exactly the same as it works in XCode. Huge grins. Popped the corks kind of thing.

I also received my Mega proto shield and built it up to start testing with 2 clients. There was some concern on the sparkfun website about building it up but it went ok. Another couple of hiccups. First, the TX / RX pins were difficult to get to (because there are so many on the Mega). Second, the SPI pins are moved to the 50s. Forgot about that one but…patience again. Read up on the TCL documentation and its reference to check the documentation. Got it. So 2 clients running now. And they popped up! Great to see them both on the screen and getting them to work with the iPhone.

Upped the baud rate to 57,600. This helped with the dropped packet issue I was seeing in XCode. Funnily enough though, I didn’t see the dropped packet issue on the iPhone. I’m wondering if this has something to do with the USB connection to the XBee from the computer.

So my big concern now here is openframeworks performance. In XCode, I’m seeing a full CPU being taken up. Not good. Also, some of the animation that I was doing on the phone looks sluggish. I have to look into this now.

Accessories / Details

Last couple of nights has been a good cleanup opportunity. I’ve tidied up some of the error handling and logging so that I have more information on timing of messaging. One of the issues was that I wasn’t getting a TX status response message. I forgot to set the frameId in the transmission. I’m now getting a status response. One of the issues that we’re going to have is with timing. The status response takes on the order of 50ms. This seems long and may be an issue as the swarm grows. 10 members means .5 seconds. We’ll see how it scales but I may need to investigate the broadcast message. I’m just concerned with acknowledgement. Research, research.

Batteries. Some research needed here too. hobbyking.com has some good options (and I just learned about them today). I need to talk to someone about this and I’ll be going to Boss Robot to see what they have. Maybe a little more expensive but will make the network more stable.

I’ve been playing around with the system here for a while and it’s really fun. Pump, sparkle, full color…. No problem!

Poco! I just learned about this framework and it looks like a great thing. It’s bundled in the openframeworks distribution. There is a lot of functionality here that I will take advantage of. First was to get logging message with millisecond resolution. There’s a lot more here to look at. I’m thinking that there may be some opportunity to link into the network at burningman to see if we can get some synchronized messaging from what’s happening there live.

Happy Birthday

Had a nice day of around the house puttering. Sometimes that’s what you need on your birthday.

Was able to make some good progress on Coordinator -> Member communication. I had to refactor the Member Arduino code a bit to help modularize how patterns are going to be designed and executed. Once that was done, I got the coordinator to fire off various commands to the member (full color strand control, sparkle, sparkle descending). I then got Elan to wear it and wander around while I controlled it through the simulator. Works!

still have a couple of problems. One is that the member inexplicably drops out and the “time in swarm” count resets to zero. I haven’t seen a pattern to this yet. Also, I haven’t gotten the iOS memory usage analyzed and I really need to get a handle on that in order to avoid any long running issues.

And, I need to figure out the battery situation. A 9V wasn’t cutting it for long. I could probably address part of it by not running the brightness so high. This was part of the sparkle design that was interesting to discover. Your eye can’t really tell the changes at the top 25% of the brightness loop. I shortened the time it spends there and it helped make it more ‘sparkly’. I should probably take advantage of this with the full brightness control.


Weekend was productive. Was able to setup a sync script to make sure that the iOS and OSX versions are based on the same code. Code is copied from iOS, renamed and then checked in to SVN.

Also, I’ve created an openFrameworks slider that I’m going to use to help select the color for the LED strand. Below is a screenshot from the iPhone simulator. Lifting your finger will broadcast a color setting message to the clients. That is the next step.

Two way communication

It’s been a fun couple of nights. I’ve been working on the bi-directional communication aspects of the project and now have the iPhone simulator sending commands to the Arduino to change the pattern of an LED. Simple but cool.

I’ve also solved the issue of the dropped member. I’ve instituted a 20 second heartbeat absence as a drop. The icon representing the member changes when a drop is recognized.

Did a little hardware work too. Soldered up the iPhone breakout board and built up a connector for the TCL LED string. It’s plugged in and ready to play with. What I want to do is build an openframworks widget to help control various aspects of the TCL wire. Specifically the RGE levels and overall output level of the string. There are a bunch of openframeworks addons available but after reviewing them I’m of the mind that I should create them myself. Wish me luck.

Work with me XCode

Ok a few nights since the last update. I’ve added the ability to monitor and display multiple members. Looks good and is pretty stable. What’s working is that it monitors and displays membership length and available RAM pretty reliably. One thing to add is the ability to monitor a drop. Still need to figure that one out.

I’ve been having some trouble on the iPhone side. The data that I got fromhttp://hcgilje.wordpress.com/2010/02/15/iphone-serial-communication/┬áhas been incredibly helpful. Most of my issues are in XCode and trying to get the compiler to play nice with my .cpp code. I tried building a new project from scratch but it was very problematic. I’ve resorted to taking an existing openframeworks example and trickling in my code until I had a working version. A few things.

  • ofSerial.cpp and ofSerial.h are not available in the iPhone distribution from openframeworks. I copied them into my project and updated the ifdefs to include TARGET_OF_IPHONE where there was a TARGET_OSX.
  • Renamed my .cpp to .mm
  • Changed the Supported architecture to “armv6 armv7”
  • Change the iPhone deployment target to 4.2

I have the executable loaded on the phone and am now starting to work on the hardware interface to the XBee. The connectors finally came in and I have to assemble the harness between the iPhone breakout board and the XBee.

Also! I hate having to support both the .mm and .cpp files. I was having trouble keeping them .cpp in XCode. What I’m planning on doing is having a script to develop in the OSX platform and run the script to check changes into SVN and rename / copy to the iPhone project. That way we’ll have only one copy of the logic. May be a bit brute force.