The Putnam Museum is throwing a Mad Scientist Ball to help fund their new STEM (Science, Technology, Engineering, and Mathematics) Learning Center on Saturday, May 18th at 7:30 PM.  The Putnam is helping to energize the Quad Cities and build more awareness about the STEM community, and are hoping to put together a fantastic set of exhibits for our community.  When the QC Co-Lab heard about this formal soiree, we knew that we needed to be there.

QC Co-Lab president David Hinkle and secretary Cody Wilson will be in attendance at the ball.  According to the invitation, the dress for the event is ”Cocktail attire, Lab Coats encouraged.”  We plan to take this instruction literally.  We’ll be sure to post an update after the ball detailing the event.

Come learn basic programming skills on the Arduino platform with the QC Co-Lab!

David Hinkle, QC Co-Lab President and self-proclaimed “pretty good programmer” is hosting an Arduino programming class with a focus on robotics automation. This class will start on Saturday, May 25th, 2013, and span 4 sessions held weekly from 2 to 4pm. Each session has a suggested donation of $10, payable either online at our donations page, or at the QC Co-Lab. According to Dave, the topics the class will cover over the 4 weeks:

1. Basic digital electronics. What is Volts, Current, and Resistance What are pullup and pulldown resistors. Ohms Law. Various forms of pulse width modulation.
2. Basic programming. Variables, functions, using libraries. Making stuff do stuff.
3. Basic hardware control. Servo’s, steppers, electronic speed controls, LED’s, interfacing with off the shelf RC electronics.
4. User requested content.

The user requested content can range to anything related to Arduinos, robotics, and micro-controller computing. Feel free to contact David before the class at dhinkle@qccolab.com with your suggestions.

You will want to have an Arduino Uno or compatible development platform for this class. A limited amount of Arduino Unos are available at the QC Co-Lab for $35, and can be purchased before any session as supply remains.

If you’d like to take part in the class, please contact David Hinkle at dhinkle@qccolab.com, and consider donating $10 or more per class. We look forward to seeing you there!

Update: The suggested donation amount was amended to $10 per class as per the original suggestion made by Dave. We apologize for the misinformation.

The QC Co-Lab attended the 2nd Annual Cedar Rapids Mini-Maker Faire on Saturday, April 27. Hosted by the Cedar Rapids Science Center located in the Lindale Mall, fellow makers and tinkers alike attended the event to show off interesting contraptions, gizmos, projects and wares.

Jacob Burkamper attends to the quadcopter display during the 2nd Annual Cedar Rapids Mini-Maker Faire on April 27, 2013. QC CO-LAB/Keith Claussen

We were very well represented by Jacob Burkamper, Keith Claussen, Chris Cooper, David Hinkle, Phil Haubrich, Mark Kruse, Cody Wilson and Ben Ziegler as they managed the exhibits, chatted with show visitors, and made sure everyone was safe while experiments were exhibited.

Our display was the largest at the show, taking up a total of four tables. Quadcopters, the Rubens’ Tube, Van Der Graff Generator, Jacob’s Ladder, POV machine, and the Liquid Nitrogen (LN₂) demonstrations were the life of the Faire. There was so much we wanted to show, it took three vehicles to transport all the gear.

Quad Coper flights by David Hinkle thrilled spectators as the high-tech remote-controlled craft hovered in the air while streaming live video back to our booth several yards away. Chris Cooper’s LN₂ demonstrations dazzled the dozens of show visitors who gathered around to see how superconductors react, pound nails into wood with a ‘banana hammer,’ shattered a racquet ball and served freeze-dried marshmallows to those brave enough to try.

Chris Cooper, QC Co-Lab Vice President, demonstrates different experiments and offers freeze-dried marshmallows with liquid nitrogen (LN₂) during the 2nd Annual Cedar Rapids Mini-Maker Faire on April 27, 2013. QC CO-LAB/Keith Claussen

In between shows, Chris had the opportunity to venture outside and attempt to make contact with the International Space Station as it passed by overhead. He used a DIY Yagi antenna hooked up to an APRS enabled handheld radio that operates in the amateur radio spectrum. With some help from Mark Kruse to locate the flightpath, they were successful in doing so.

There were a couple of unfortunate situations we had to overcome. The Co-Labulance developed a coolant leak we were unable to resolve in time for the road trip. After operating briefly, the Rubens’ Tube demonstration fell victim to venue regulations, so the propane tanks were removed and the Rubens’ Tube became a static display.

Despite the setbacks, it was still a great show and everyone had lots of fun. Norah Hammond, General Manager and Education Director, Cedar Rapids Science Center and Mini-Maker Faire organizer, was thrilled with our efforts. We have already been invited back for next year!

Cody Wilson, QC Co-Lab Secretary, explains how the Rubens’ Tube operates during the 2nd Annual Cedar Rapids Mini-Maker Faire on April 27, 2013. QC CO-LAB/Keith Claussen

So, hats off to everyone that helped out getting things ready, made the trip to visit us, or presented because it was definitely a CO-LABorative effort to make it all happen.

Ben Ziegler demonstrates the Jacob’s Ladder during the 2nd Annual Cedar Rapids Mini-Maker Faire on April 27, 2013. QC CO-LAB/Keith Claussen

This Saturday, April 27 from 10 am to 4 pm, join the QC Co-Lab as we head up to the Lindale Mall for the Cedar Rapids Mini Maker Faire!  We’ll be showcasing a myriad of projects that embrace the STEAM (science, technology, engineering, the arts, and mathematics) and/or maker philosophies, such as quad copters, a Ruben’s tube, and liquid nitrogen.  We’ll also be making the trip with the Co-Labulance, our 1981 Chevrolet G30 de-commissioned ambulance / mobile hacking rig.  Wish us luck as we take her out on her maiden voyage after a considerable amount of maintenance and work was put into her.

If you’d like to check out our 4-table booth, as well as what should be a fantastic showing of making at its finest, head on over to the CR Mini-Maker Faire site at makerfairecedarrapids.com, and click the “Register to Attend” button on the right-hand side of the page to request your free tickets.

If you weren’t able to attend, the live stream is available here recorded video will be made available after the show.

First up was getting the redesign finished, and important content transferred over.  Additional content from the old site will be available at old.qccolab.com until it is migrated over to the new site.

Code: https://github.com/CCDKP/QC-Co-Lab-Light-Wall
Videos: https://www.qccolab.com/LightWall?page=7

GE Light Effects strand with soldered extensions

Phase 1: Inception

Located in the heart of the Midwest, we sit between some of the biggest names on the US hackerspace map. TCMaker to the North West, Pumping Station One to the East, ArchReactor to the South, and CCCKC to the South West. With such big names all around us, we were really going to have to do something special to make our mark.

On the north wall of the QC Co-Lab, there is a 15×17 glass block wall facing a major city thoroughfare.

When we were searching for the making of our first big project, the thought hit us; those 8” blocks would make perfect pixels in an LED display! So we dug in and started researching our options.

We looked around at several solutions, including the BlinkM and ShiftBrite, but we quickly ran into an issue, at 255 pixels, the costs were adding up quick. We decided that we would need to wait to raise some funds and see if we could find another option.

In November of 2010, an enterprising hacker named Darco (Robert Sun Quattlebaum), stumbled upon a little secret that took the hacker community by storm. He discovered the hidden secrets of GE Color Effects Christmas Lights. A few days later, one our our members, Ben Ziegler, managed to pick up two strings to play with during the QC Co-Lab Holiday party.

Taping lights directly up to the glass, the lights were bright enough, but we wanted a solid block of color. A regular QC Co-Lab visitor, Josh Conroy, built some reflectors out of cardboard triangles coated with spray adhesive and aluminum foil. They were built into pyramids with duct tape. By bending the tips inward at the peak the cardboard kept the bulbs in place. We assembled the first 36 light string into two 3×5 sets using some ceiling tile frames with a fluorescent light diffuser in front to get a solid color wash.

With the help of member Don Kieu, we got a modified version of Darco’s initial Arduino code running and the timings worked out. Using a 3×5 pixel font Josh made, we had a two character scrolling marquee, and more importantly, a solid idea for moving forward. We thought that if we could catch an after-Christmas clearance sale, these lights would be a cheap and awesome way to fill out our lightwall. The problem was, it seemed like everyone else had the same idea.

While searching from store to store looking at ‘Sold Out’ signs, we noticed an overlooked gem: GE Color Changing Snowflakes!

These use the same bulbs as the strands everyone else was using, but in a different form factor. We quickly bought up the last 5 sets we could find and started unlocking their secrets.

Phase 2: Initial Testing

With our stack of lights in hand, we started dismantling them and trying to scale up our earlier success. Since we had a plethora of dead power supplies and old AV cable lying around, we decided to salvage some old RCA jacks and 4-pin Molex power connectors to make everything modular. Since our target wall was 15×17, we decided to chop our lights into modular 15 LED strands. We also built some splitters to allow us to use the stock 5v transformer for powering both the lights and an Arduino.

It wasn’t long before we had these modular strings up and running. We had some fun playing with the colors and building some basic test patterns.

It was about this time that the scale of our project started to sink in. The addressing in the lights allowed for 63 lights per string. Because we broke everything into rows of 15, this meant a maximum of 60 lights, or 4 rows, per string in our final design.

Up to this point, all the code we worked with was designed to power a single strand of lights, not five, which meant we were going to have to redesign our code from the ground up. To rebuild it, we needed to know these lights inside and out, so we started researching. Most of our information came from Darco’soriginal post (and comments) and the Do it yourself Christmas forums.

I strongly encourage anyone wanting to work with these to read both those threads, as they have excellent information about the inner-workings of these lights, specifically Darco’s analysis of the protocol. Assuming you have at least read Darco’s post, here are some additional details we thought were worth noting:

• If the brightness is changed by more than a single bit, the lights flicker a bit, so single bit brightness changes are required for smooth fades.
• The lights are self clocking based off the falling edge. The sample appears to be taken half-way between clocks, meaning there is some play in the timings.
• The stock clocking is based around 30 μSeconds, with the first 10 μS always being low, and the last 10 μS always being high. The middle 10 μS is the “data” bit and is inverted. This means 10 μS low, 20 μS high for a “0”
• The DigitalWrite() function in the Arduino has roughly 7 μS of overhead, making it impractical for our use (given our 10 μS timing needs)
• The stock Delay() functions in the Arduino are not accurate enough for our use.
• The Lights are self-addressing at startup, so the physical order isn’t that critical.

Along with the research, we started doing the math on the timings. At 840 μS to address a single bulb, writing to all 255 one at a time would take 214 mS, leaving us with a jerky 5 frames per second. If we figured out how to write to all five strings at the same time (with 60 bulbs per string), we could do almost 20 FPS. This was better, but it left no time for any processing. We finally settled on splitting our strings in half, giving up 30 bulbs to a string, but netting us a whopping 40 FPS on paper. Running at 30 FPS, this would leave us with 244 mS of processing time between frames. (We put together a fun google docs spreadsheet to help us work out the timings. If you download it, you can play with the timings for yourself. It is available here.)

It was around this time we found out our neighbors, Hamilton Technical College, were going to have an open house in a few months. This meant a lot of foot traffic right outside our space in about a month. If we could have the lightwall finished in time, it would be a great chance to introduce some people to the hackerspace community. Since we knew the timings would work and had our string layout finalized, we decided to split up the project to get it done in time. Part of the team started on the code, while others went to work on mounting.

Phase 3: The Code

With the math done, we knew the wall would work in theory. We just needed a way to talk to it. Our plan relied very heavily on the ability to write to 9 strings simultaneously. We considered the Arduino, since we used it in our initial testing, but with only 16 MHz and 2K of RAM to work with, we quickly discounted it and looked for something else.

We started looking into various development boards and even a dedicated x86 PC to run it. We figured it would be a quick job for David Hinkle, a member and veteran Linux programmer, but was unfortunately tied up with work and didn’t have the free time to help with the project. With our deadline fast approaching, we decided to give the Arduino another go. We figured we could use if for a simple display, then move to a bigger platform later.

The big challenge we had now was how to write to all nine strings at once. We started trying to interleave our writes, using the 10 μS between state changes to manipulate the other strings. DigitalWrite had a horrible 7 μS overhead. Even DigitalWriteFast wasn’t fast enough. At 16 Mhz, we only had about 17 CPU cycles per string to work with. As we were looking for ways to speed up the code, Mark Kruse discovered Port Manipulation, a way to write to a whole register at the same time. This would give us a speedy write, but we still needed a way to process nine strings worth of data at the same time.

The following evening, we sat around trying to find a way to use our new-found trick. In a caffeine-induced moment of inspiration, we had the answer! What if we did all the processing ahead of time on a PC, so all the Arduino had to do was pump raw data directly into the register? If we cut out our last half-string, leaving us with a 15×16 lightwall, our data would fit into conveniently sized 8-bit chunks. If we write to the same address on all eight strings at once, all that would need to be transferred is a 12 byte long chunk of interlaced color data.

We originally wanted to use the bottom half of the Analog register and the top half of the first digital register, then have a PC stream the raw data over the serial link. After the first few trial runs, we ran into an issue with the Analog pins. While writing directly to the Digital pins was quick and responsive, the Analog pins we a bit unpredictable. Sometimes they would push the data just fine, other times they would mangle the signal resulting in a rainbow of random colored flickers that would make Nyan Cat jealous.  The more we thought about it, the less we liked the idea of being tied to a PC. We decided to just bite the bullet and use the whole first Digital Buffer.

Using the entire first Digital buffer was great, since we no longer had to split up the data while writing. The down side was we lost our serial link: our best source of debugging information. Fortunately, we just made a giant wall of lights we could communicate with, so an error code function was crafted and we moved on.

Somewhere along the line we found an SD shield we could use to store the data on. We decided to use the Fat16 libraries, since they used almost half the ram of the Fat32 library.

Since we now had up to 2GB to work with, we decided to come up with some sort of file format, so anyone could go and create an animation to display. Being a networking engineer by trade, I’m a sucker for a good, flexible, protocol. Since I was doing most of the base code writing at this time, I decided that we would make an expandable file format, capable of many different types of animations. In hindsight, it may have been a little overkill, but hey, what’s the point if you can’t have a little fun, plus it made a great learning opportunity. For the initial release, we decided on just supporting a raw data stream format, but several other formats are in the works.

In the spirit of modular code, and knowing that not everyone would want to use just our player, we broke the lightwall manipulation portions into their own class library. We also cleaned up the code and made supporting additional message types easier down the road. You can find our lightwall library and the associated player on Github: https://github.com/CCDKP/QC-Co-Lab-Light-Wall

Now that we had a player, we needed a way to make files to play on it. Because most of the processing is done on the PC, the routines for saving and loading are kind of ugly. Colors need to be cut down to 12 bit, the data needs to be inverted, and the pixel data needs to be interleaved across multiple rows at the same time. In another late night programming session this chunk of psuedocode found its way to the whiteboard:

The top half is for saving, the bottom for reading the file back in. The code would be repeated two more times for the green and red color bits. Seeing this again, I can’t help but feel slightly responsible for the passing of Dennis Ritchie. Ugly as it may be, it worked, and because of it two additional projects were spurred.

The first is a Visual Basic program written by our very own Mark Kruse. It is the full-featured editor, and at this point in time the only tool short of the wall itself that can open and display lightwall files. Check him out here: https://github.com/krusem/LightWallEditor

The second project is a python script by Mark Riedesel. It converts animated gifs or series of PNGs into lightwall files. One particularly entertaining trick is using FFMPEG to convert a video file into a series of PNGs, which can then be used as input for the script. His code is available here:https://github.com/Klowner/8cic-encode

While all this coding was being worked out, the more physically inclined members were working on building something to put all this code to use.

Phase 4: Construction

While our initial cardboard cones worked great as an example, they only held up for a few weeks before falling apart. It was clear we were going to need something more durable, and able to support the weight of an 11-foot structure.

Over the course of the week he was here, Josh helped us build more prototype cones out of everything from aluminum pie pans and funnels to wood and plastic, all the time trying to balance cost, reflection, diffusion, and structural integrity. We tried various translucent plastics, parchment paper, and spray-on window frosting for diffusers, and foil, mirrors, and reflective paint for linings. We always kept a string of different prototypes up to let everyone see and comment. Each new idea meant finding parts, calculating cost, constructing, mounting, then waiting for nightfall before running outside the building to compare.

We finally settled on a design built out of white plastic sheet in a pyramid form. The raw  materials were affordable sheets of shower lining from the local hardware store. The white plastic was lightweight, sturdy, and reflective enough that it didn’t require additional treatment. The plastic was malleable enough we could use a vacuum-former to mold the pyramids. A flat lip around the outside edge would be used for mounting, while a 1” hole in the flattened tip would hold the lights. We decided to use the plastic diffusers that came on the bulbs, as they doubled as clips to hold the lights in the cones.

The plan was coming together, save the small issue of not having a vacuum-former. Being a hackerspace, however, we didn’t let that stop us!

While the details of the vacuum-former construction is probably best left for it’s own writeup, with the combined effort of Ben Ziegler, Neal Meeker, and Mark Riedesel, we had a functioning machine. Using a fiberglass form build by our president Steve Hamer, and an improvised hole-punch made from some sharpened steel pipe, we are able to start turning out cones.

To assist with mounting, Dave Langcamp designed a jig for making interlocking 5×5 lattices out of thin wood strips.

We could staple the cones directly to the lattices, then attach three panels together to make a 5×15 module to hang on the wall. They were sturdy enough to support the whole structure, but light enough we could still hoist them up with some nylon rope and a few eyelets. They were also just small enough that we could break down a couple of them if we wanted to take a section of the wall to a makerfair.

As we started to expand beyond our initial testing strings, we ran into another speed bump. The lights we used for testing up to this point were built for stringing up along the house, and had a nice 10” spacing between bulbs. The lights from the snowflakes we purchased were more densely packed, so they only had 6” of wire between bulbs. Since our glass blocks are 8” center-to-center, this meant we would need to splice a 4” extension of 3-conductor wire between each and every bulb. This project was going to take a serious labor involvement.

In a scene reminiscent of a 1990’s movie montage, 1400 solder joints, 255 vacuum-formed cones, nine wooden frames, three weeks, two small fires and a tube of burn-cream later, we had all the parts we needed to put this project together.

Phase 5: Mounting & Testing

With less than two weeks until the open house, we were getting down to the wire. We attached a few of the frames, stapled in the cones, and wired up all the lights. This was our first chance to bring all the software and hardware together and see what we had worked so hard to build.

After a bit of fiddling with wires and checking connections, the first segment of the wall sprang to life. A simple binary counter clicked away in a twinkle of dazzling colors.

As we stood back and marveled at our now toy, we noticed the occasional glitch and flicker. Chalking it up to a bug in the counter, we shut the wall down and loaded up our color diagnostics program.

As the lights fired up one by one, we noticed them getting dimmer and dimmer. By the time it got to the last few bulbs, the colors shifted and the program quit running. As we went to check the cabling, we noticed the power brick was really hot! Up to this point, we had been using the original 3-Amp transformers that came with the lights. While it happily supported 75 lights when they were blinking away random colors, when the lights were all a solid white, it could only sustain 3 strands (45 lights). Scaling it up, we figured we would need a 15 Amp power supply to safely power the wall at peak. As it turns out, a 15-Amp 5-Volt power supply is not as easy to find as one might think. We ended up modifying an old PC power supply (Which conveniently matched the 4-pin Molex we were using for connections), and soon we had enough power to light the whole wall at once.

Now that power was no longer a limiting factor, we started to tie together more strings. By the time we had the second module online (150 lights), what started as an occasional glitch soon became a steady nuisance. After borrowing an oscilloscope from work, we saw our timings were a few microseconds off.

After a bit of tweaking, we found that each string had a varying tolerance for the timing. We tuned our code to get as close to the stock 30 μS bits as possible and most of the problems cleared up, but we were still experiencing a small problem that jumped around.

With how far we had come, we refused to be beaten by a little blinking, but it was frustratingly difficult to find. The problem was the inconsistency of the code. Sometimes a bulb wouldn’t update, other times the color would be off or the bulb would be very dim. Every time it would be a different bulb on a different string. There didn’t seem to be an reason to it. After much code review and wiring checks, we finally caught a break and captured a defective packet on the scope

.

Examining the timing, we noticed an extra 3 μS right in the middle of the color data. We had worked hard to insure a rigid 30 μS, so we were confused by this mysterious 33 μS bit. It suddenly occurred to us that our trusty Arduino might have been sabotaging us this whole time. For all the time we spent trying to get our timings absolutely right, we forgot to disable the internal interrupts. Every so often the internal Arduino interrupts would go and run 3 measly microseconds worth of internal house keeping, but it was just enough to throw the timing off on picky bulbs and mess up the packet. One little code tweak later and everything was back in action. The lights were bright, the colors were crisp; it was time to mount the wall in its final home.

Our president, Steve Hamer, decided to brave the heights and climb the ladder to the top of the window and install a couple of eye hooks in the ceiling. After threading through some nylon rope, we attached eye hooks to the back of panels and tied them to the rope. From here we started joining panels together and hoisting them into place. A pair of shower curtain rods served as supports to keep the center flush against the window. After everything was up and mounted, the only thing we had left to do was wait until dusk and see if our months of hard work would pay off.

Phase 6: Display

The first night we fired up the wall, there was a lot of excitement. We had talked about this project since we first founded the QC Co-Lab more than a year prior. After months of hard work by many of our members it was finally time to see it in action.

Seeing the wall in action, we were jumping around in the parking lot laughing. The animations were smooth and the colors were vivid. From across the street, you could see the picture perfectly. We had finally completed the QC Co-Lab LightWall. All that was left was to clean up some code and release it for the rest of the hacker community to share.

The Demo routine from inside

All glory to the Hypnotoad!

Simulated Blue Screen & Reboot

Nyan Cat

Never gonna give you up

Phase 7: So Now what?

Getting the LightWall built was just the beginning. Now that the wall is up and running, we have the fun job of making entertaining things to display on it. We have two solid plans for moving forward: expanding the current LightWall display protocol we set up and creating an interactive platform.

When we built the Arduino player to run the wall, we designed a modular system. While we only initially wrote the raw data stream format, plans are in the works to create additional data types, including scrolling text, sprite-based animations, and variable-delay frames. Keep an eye on the project, or feel free to contribute. We built the system as a starting point and really want to see where it can go from there.

The other plan we had was to find a way to make the wall more interactive. The current player is fairly static, due the the limited resources of the Arduino. There has been discussion amongst our member of porting the project to a larger platform, like the Netduino [URL][http://netduino.com/], so we can produce games, and real-time animations involving physics, anti-aliasing, and more.

There is a long road ahead for the QC Co-Lab and the LightWall. We hope the community will get involved and help us take it further than we would have imagined. If you have any questions or comments, we are always happy to hear from you: CCooper@QCCoLab.com. Thanks for reading.

Core LightWall Team:

Chris Cooper
Steve Hamer
Mark Kruse
Dave Langcamp
Mark Riedesel
Ben Ziegler

Special Thanks

John Abdul-Masih
Keith Claussen
Josh Conroy
David Hinkle
Don Kieu
Neal Meeker
Dustin Saldivar
Cody Wilson
Robert Sun Quattlebaum
The DoItYourselfChristmas.com forum community
& The rest of the QC Co-Lab

On Friday, September 16th, a team of gamers from the Quad Cities area will hold their first annual MegaMan For Healing fundraiser supporting Child’s Play Charity.

MegaMan For Healing is a multi-day charity drive broadcast live online. The event starts with a group of gamers attempting to complete a list of levels from the MegaMan video game franchise by CAPCOM. Viewers add levels to the players’ queue by making donations to Child’s Play. This live-streamed cat-and-mouse game continues until the team successfully completes all of the unlocked levels or the team runs out of levels to play, whichever comes first. During the event, viewers will be encouraged to interact with the team via the website, as well as through popular social media services Twitter and Facebook.

“While I’ve never benefited from Child’s Play’s programs, I know the power of their vision first-hand,” says Cody Wilson, Event Coordinator, who was inspired to organize this event in part due to a life experience. “As a boy, I broke my arm right before school let out for the summer. Due to the nature of the break, I was placed in an immobilizer and wasn’t permitted to play outside. My mother saved money until she could buy me a Super Nintendo, which kept my spirits up through the summer.” As for why he chose to organize an event like this, Wilson answers, “It works. Gamers love reliving classic moments from childhood, and people love watching other people do silly, entertaining things on the Internet. Combine those two things and add in the fact that you’re doing it all for charity, and you see why over 12.7% of Child’s Play’s 2010 donations were raised by two events that inspired our own.”

The Child’s Play Charity (www.childsplaycharity.org) is a game industry charity dedicated to improving the lives of children staying in an international 70 hospital network. Child’s Play has distributed over $10 million worth of video games, toys, books, and money since the charity formed in 2003. “Child’s Play is fortunate to have such incredible community support,” says Jamie Dillion, Project Manager for Child’s Play. “Events like MegaMan For Healing really make a huge difference: the funds raised go directly to buying games, consoles, and handhelds for children in hospitals around the world.”

The event will stream live over the Internet at www.megamanforhealing.com beginning September 16th at 12 PM CDT.

Every generation inspires their own counter culture. Their own beatniks, hippies or rebels without a cause. These ideas are alternatively rejected, accepted, re-ordered and recombined in a multitude of permutations that make up the dance of memes in human generations as their progenitors are born, rebel, conform, and die.

The cycle of life continues, and we each live it in or own way, in our own small timeslice of the great simulation (Wave Particle Paradox) that creates the illusion (Michael_Talbot, Wikipedia: Holographic Principle, Wired) we call reality.

So people call me. They write me emails. They want me to announce that they’re coming. They work their way across the country, one hackerspace at a time. At each stop, they teach a workshop, sell some kits, and earn enough money to buy a hamburger and put gas in the car.

The next day, they wake up on some one’s couch, and leave one step closer to San Francisco California or New York New York.

They are always welcome, they bring with them eclectic knowledge and the story of a romantic, sometimes spiritual, experience. The service they provide is to keep us entertained on a quiet weekday night. They teach, we learn, together we build. It’s our mission.

They are the new “Backpacking Across Europe”. The new “Hitchhiking to Woodstock”. They spread ideas and hacker culture with them wherever they go.

Some of them, like Mitch Altman, do it to spread word of a movement. Some of them, like CMKT4, do it to pay their way to Maker Fair in California.

As a matter of fact, CMKT4 stopped by this week. We made some contact mics, learned about Piezo’s, and had a good time. After which they played some of their music for us.