Just thought I’d take some time to catch us all up on several recent developments beyond Interlock, but somewhat local, that are relevant to our interests.
Last month, I read in the local paper of the formation of the Rochester Brainery, opening early next month in the Village Gate, across the Goodman Street railyard from us here at Interlock and our neighbors at the Hungerford.
We’ll always owe a debt to Dave at Coworking Rochester for helping us get started by offering space and moral support during some of our bigger early organizational meetings, before we settled on a space of our own to rent. Still, it’s interesting to see people coming together in another coworking space in town, Smokestack Coworking, High Falls area.
Here’s hoping they both thrive and complement each other.
Last month we received a visitor from Ithaca, José, who traveled up with a couple of friends maybe to join what he thought at the time was the closest hackerspace to him. I had a great time talking with him, so it was a little bittersweet to tell him Ithaca Generator has recently gotten off to what looks like a good start and might just meet his needs without the long drive.
I wasn’t able to make it to their open house back in December. But, I
did visit with some family over the holidays who were able to go and got to see the party favors they made at the open house. Fun. Look like good things are in store for the hands-on, DIY hacker and maker community in Ithaca.
We’ve also been having a friend, Joe, make the trip from Niagara Falls every so often to visit, which has had us asking how things are going at Buffalo Lab. Figured we’ve give them a shout out while we’re at it.
[placehold for eventual Rochester Makerspace logo]
Last, but hopefully not least, the most recent big news is a much-anticipated step for the group calling themselves Rochester Makerspace. They’ve rented a space a little north of downtown, on St. Paul Street. Just Tuesday they had a get-together with pizza at the new location.
Though the planning for this new space has been careful and deliberate, ongoing since at least this last summer, they now are moving towards ambitious goals to grow fast. I continue eagerly to await the opening of another maker-friendly space in Rochester, expected some time in March.
Hi there Hardware Hackers,
My name is MacGyvrBot. I’m an open-source 3D Printer hacked-up from a Printrbot LC kit by Skip (Printrbot LC | printrbot). I hang out at the INTERLOCK space a lot, but I’m portable and I often follow Skip around to help at Tango Product Design.
Skip creates most of my gcode instructions on Slic3r – G-code generator for 3D printers from stl files created on Tinkercad – Mind to design in minutes. I often publish my designs on Thingiverse – Digital Designs for Physical Objects.
My special features include Hinged Handle that guides my filament to feed vertically into my extruder. This minimizes perturbations on my x-axis and doubles as an alarm by slamming down if my Filament gets snarled from the supply spooled on a Rack made from a hacked-up Power Tower | printrbot. I can carry my MacBook around in Brackets on my starboard side. MacBook Brackets by MacGyvrBot – Thingiverse
My power cord and my usb connector along with a power connector for the MacBook can be stored in a Zipper Pouch below the filament rack. I also have a handy Z-stop Adjustment Z-Stop Adjuster for Printrbot LC by MacGyvrBot – Thingiverse that lets Skip tweak the thickness of my first layer if the printed perimeter doesn’t look perfect.
On my starboard bow there is 70mm Muffin Fan (scrounged from Skip’s junk pile) with an Air-flow Adjuster and Shroud custom made for the fan 70mm Fan Shroud by MacGyvrBot – Thingiverse. I made a similar fan for my RepRap Mendle friend from an 80mm fan 80mm Fan Shroud by MacGyvrBot – Thingiverse. The adjustment allows Skip to conveniently adjust my bed-cooling during a print job. The maximum airflow marginally allows my heated bed to maintain the 80 degrees C required to stick onto ABS while it allows tall single features to quickly cool layer by layer. The fan can be adjusted back to make sure the first layers stick properly.
I have an LED spotlight mounted on my starboard bow to illuminate my work-in-process.
Skip’s iPad can hang on my port side during our travels. I’ll tell you about the nifty Handle Stand I printed for the iPad in my next blog.
As seen in a previous post, I have a Tron Mini/Cabaret arcade machine. I used to have a Tron full-sized (FS) machine, but sold it many years ago. One thing that the FS had over the mini was lots of extra lighting.
It had artwork beyond the monitor lit with a regular light, it had a blacklight above the control panel to make the traces glow, and make the joystick glow. There’s also a second blacklight below the control panel to backlight the bottom portion as well. All of these lights are always lit, making the machine extra awesome. On the mini, there is glow artwork, but no light to illuminate them. Ever since the late 90s, I’ve had a plan to change this, so I bought a pack of UV LEDs, but they’ve sat dormant in my parts bin until now!
One thing that I’d like to bring to this, is to go an extra step, and bring some ideas over from the “Environmental Discs Of Tron” (EDOT) machine. On the EDOT, you walk inside of it… one of the few, if not the only, games where you can do this. Around the monitor and control panel are lights, similar to the FS Tron. However, on EDOT, they’re controlled by the game. They will flash and such when certain game events happen. I can make this happen with Tron, using an interface to the game, and a ROM hack.
Above all, the modifications made must be reversible without any damage to the machine. I do not want to inflict any permanent damage or changes to the cabinet. I will simply add lighting, make a ROM hack to control the lights, and mount an additional board inside the cabinet.
To start with, I need a secondary micro to control the lights. I’ll use one of my stepper motor controller/Arduino devices. I made the FTDI programming and power interface seen above in about 30 minutes on the piece of strip board at Interlock this past Tuesday. You can see the resistor/capacitor pair to handle the programmer’s reset, power, and TX/RX lines, and a red power indicator LED for the heck of it.
After a bit more work, I had the 3 LED driver chips wired up, with their 8 outputs, along with the 5 pin header which I’ll be using to interface it with the arcade machine. The pinout there is two bits of input, 5v power input, and ground. I’ll add in SPI-like (clock+data) communications from the TRON game. I figure that the first version will just send down a packet stating the lighting effect, but in the future I can use this to send down high scores as well, which can be sent out via serial to a host PC and post them on the net or something like that.
At first it didn’t power on properly, and the LED driver chips got VERY hot. Then I remembered that the circuit diagram I was referring to while soldering this up was incorrect and had power and ground reversed to the chip. I also had + and – wired backwards for the LEDs as well. I forgot that these driver chips sink current, rather than sourcing it. After a little bit of emergency soldering, all of that got worked out.
I’ve since cleaned up the wiring a bit, adding some insulation.
I decided to wire up the LEDs such that the current limiting resistor was wired up with the LEDs, rather than on the main board. I’m glad I did this, as the resistance I picked (220 ohms) was way too high.
Enhanced image. It sadly doesn’t look quite this intense in person.
Experimenting with how it will look to have LEDs inside of the joystick to illuminate it.
The output from these LEDs was much dimmer than I was hoping for. I will be experimenting with lower-valued resistors, as well as possibly doubling-up LEDs for lighting the various artwork elements. I also need to figure out how to mount the LEDs without damaging the machine at all.
Next up is the ROM hack to talk with this!
I’m in the process of constructing/setting up my office in the house, and for lighting, I have decided that I want to use xmas light-style lighting. Many years ago, I used to light my room with multicolored incandescent lights. I loved the warm indirect glow, and smooth light without a single light source. This time, I’m going to take it a step further.
While there’s nothing about this project yet that is really innovative over what others have done, it is the first step to getting the office lighting done. The real fun will come into play once I’m able to hang this up, and start programming effects, and tying those effects in to physical or time-based events.
A couple years back I picked up a strand of addressable LED lights, similar to this one, available at adafruit.com. I got a strand of 50 lights, blew out one of them while being stupid, and used a few of them in Jasper’s Toy Box (posts to come about that eventually), so I’m left with 42 lights. A nice number.
In any event, the plan is to hang them up around the upper perimeter of the room, and it will give a nice comfortable glow to illuminate the room. I can also extend it by doing lighting effects with the color. For example, in the evening I can have all of them dim blue, and randomly twinkle one to white, to simulate a star in the sky. I could also tie them in to an automation system to glow a particular corner of the room red or yellow when i have email from a specific person. I could also adjust their color based on the content of my monitor, or the light outisde, etc.
The basic design for the control circuitry is that there will be an Arduino-based AVR micro (actually one of the D-15 servo controllers I’ve appropriated), which is perfect, since the strands only need two lines to control them. The host computer will send down codes to address the LEDs (set all to color X, set led Y to color X, etc) and this will pass on the content to the strand, and twiddle the data lines and all of that fun stuff. I had considered putting more “smarts” into the micro, but the amount of space in there would severely limit the kind of content I could “display”, so I decided to put all of the grunt work back on the host computer.
To power it, I needed to get a 5 volt power supply. I snagged a power brick from an old external drive case, as well as a standard PC power connector, from a failed power supply, and spliced the two of them together.
Copious, yet appropriate amounts of heat shrink tubing and splicing some wires yielded a nice power supply.
Next, I built an interface board to tie it all together. The ports on the board are (left to right) – 6 pin FTDI interface for serial IO, 2 pin jumper (power the D15 from the power supply rather than FTDI source), 3 pin power, 4 pin light strand connector. You can also see in this picture, the process of crimping the terminals for the molex connector on the LED strand’s wires.
I kept the layout and pinout of the FTDI the same as I used for my serial node experiment. This will help me plug that connector in correctly. I still need to add visual cues (colored sharpie markings) to help me align the pins correctly. The power connector has GND on pins 1 and 3, and +5V on pin 2. Keeping it symmetrical will help me always plug it in correctly, reducing the chance that I will blow it all up. The 4 pin connector is the same pinout as the wiring of the LEDs. GND, Data, Clock, +5.
The jumper on the board (dis)connects the power header from the D15 and FTDI portion. If I make standalone firmware for it, I can power everything from the power supply, if need be. The tiny green LED on the board just lights when the D15 has power. A nice indicator in case everything else is not functioning.
The protocol I used for this is very simple. There’s a command character sent through serial, then the data for that command. If the firmware is expecting a command character but gets something it doesn’t understand, it just keeps checking the serial input for a command it knows. The protocol is as follows:
p<index of LED><red value><green value><blue value>
Five bytes. It sets the specified LED (0..42 in this case) with the specified RGB value (0..255 each). Note that this is not an ascii string, it is data. So no matter what, it is 5 bytes to change a single pixel.
f<red value><green value><blue value>
Force all of the lights to the specified color. This is handy for clearing everything to black, or flashing/fading effects.
Here’s the Arduino firmware used to handle all of this: (Note: it requires that the strand’s library be installed.)
For now, that’s it. I made a simple interface on the desktop side in Processing, adapted from my previous controllable pixel software, to let me click and change the color of an LED. I also added some key commands to do simple effects with the lights. (all red/green/blue. flash, etc)
Eventually, I will write better desktop software which will use the LEDs for indication of events, as well as f.lux style color effects throughout the day, audio/visual synchronization to media being played, and other effects as well as time goes on
NOTE: All of the source/projects for this are available on github.