Monday, September 29, 2014
Nerf Escalations
Thursday, September 25, 2014
DMX Lighting Control Application - And Then Some!
I've always had a love for stage technologies - pro sound, stage lighting, all that good stuff. Once I got a real job, I was able to start getting some of my own equipment to use on the side - soundboards, speakers, and stage lights. The next logical step (well, to me anyway) was to use those stage lights in my apartment instead of normal things like lamps. They're all RGB LED fixtures (that is, each contains red, green, and blue LEDs in an array) positioned on the floor pointing up at the wall, so they give off a nice indirect, diffused glow. The lights are all controlled via DMX (standard stage lighting control), so logically, I needed to make an application that would control them using a USB to DMX interface.
I started off with a very modular setup from the outset. I set up a database that allowed for configured Light Types (each fixture has a specific way it needs to be controlled, as certain number of DMX channels it requires, etc), Lights (the actual devices, with their associated Type), Groups of lights, and Scenes (conglomerations of groups and their lighting state, like bright red). I made a super-simple Windows Forms application to be able to configure all those settings in a tabular format. Now that I had information about all the lights and their current state when various things happened, I was able to build a 'universe' of information about what value every DMX channel needed to be configured for in the current setup. Using a USB > DMX interface with an API that plays nicely with C# (http://www.amazon.com/Velleman-VM116-Usb-Controlled-Interface/dp/B001IRMFUW, using K8062D.dll), I was able to commune with the lights to my heart's content.
Except the heart wanted more. The nest step was to make the application web-accessable so that I could set the lights from my phone. Obviously. So, I updated the application to host a REST endpoint that allowed it to load requested scenes. I then created a simple PHP web page that connected to the database, retrieved a list of all configured scenes, and then displayed them on the screen as big buttons that, when clicked, triggered a call to the application's service endpoint to enact the change. Simple, and highly effective - my lights were now mobile-friendly! And I saw that it was good.
And yet, there was something missing. Sure, it was nice being able to take out my phone and set the lights, but shouldn't they be able to do that themselves? I added a new tab to my rapidly growing application for Schedule items. These had information about what Scene should be triggered, at what time, and on what days. Once set up, my lights turned on a bright white in the morning when I was supposed to be awake (during the week, that is), green when I should start heading out, red when I really-no-kidding-for-realzies need to leave, then turn off when I sure as heck should be out of the house. They then turn back on a nice bright white just before I get home in the evening, a soothing blue when I need to start heading to bed, and turn off when I should be falling asleep. And thus, the lights gained a speck of artificial sentience, and my heart was happy for a time.
But alas, one cannot stem the torrent of need from the heart. Yet another use case presented itself that seemed to be a wonderful fit for my little application. One of my good friends was getting married, and he asked if I could provide sound and lights for the reception. Never one to go into something halfway, I added to grant the application the ability to function as fully automated DJ. I added a new tab to the interface for Songs. Each song had an associated lead-in and end buffer (to trim out introductions and fade-outs to keep the party jammin'), as well as it's own scene (yep, I made a scene for each song). These are mostly empty because I cleaned the lists out for everyday use.
Once started, the application cross-fades through each song in the list (using WMPLib.WindowsMediaPlayer objects), fades the lights from one scene to the next, and in general takes care of itself. It also allowed for skipping and re-ordering songs (which, for those of you who have never played the role of music selection master, happens. A. Lot.) There were a couple minor glitches like songs repeating, but in general, it worked out quite nicely, and allowed me to enjoy the reception as well.
What's next for Moody? Who knows - the heart is a fickle organ; you can never quite tell what it's going to pine after next.
Sunday, May 9, 2010
Grid Mark II
Monday, February 15, 2010
8-Switch Panel
Saturday, January 30, 2010
LED Grid
This project is something that I have been working on for the past 3 years, and was finally able to finish a couple months ago. I got the inspiration for this project from a swimming pool jumbotron that had groups of 4 LEDs that combined en masse to create a giant screen. I figured that if I could control 8 channels from the parallel port, I should be able to figure out something to control more channels to make a rudimentary screen with 3-color LEDs. I started on this project with the application that was to control the grid. At this point, I had no idea how i would get the data to the screen itself or run that, but to start I needed something worth putting up. I started with some very basic designs that wiped a bar any number of pixels wide up, down, left right, diagonally etc around the screen to learn the logic. Then I combined them to make more designs with multiple colors and patterns. After the designs, i made an alphabet and created a marquise that was user-settable, and images that could move across the grid. While working on the computer, I had a process running that emulated the box by outputting HTML representing each light to a file and showing that page in a control in the UI that refreshed several times each second. Additionally, I found a control that someone had made that gave the overall sound output level of the computer (http://www.codeproject.com/KB/directx/volumemeter.aspx?df=100&forumid=328840&exp=0&select=1956575). I created an algorithm based on that to figure out what the beat of the song was, and them made an option to have the pattern change color with the beat.
After I had the software portion pretty well started I began work on the grid itself. I had read a good bit about how LCDs were made and how to control 12 LEDs x 12 LEDs x 4 leads = 576 channels, and was aware that I had to multiplex the display. Multiplexing consists of activating one row at a time and cycling through them extremely fast, taking advantage of the human eye's persistence of vision to make it appear solid. Because of this, I could take the number from 576 to 48. soldering so many LEDs, however, could have very easily gotten to be an absolute mess of wires, so I did what you can see below in the pictures, which I think is rather pretty. The RGB lines go across, and the anode lines go vertically, and they all go to a block connector that has a ribbon cable connecting it to the breadboard with the electronics, allowing it to be worked on much more easily. The LEDs are mounted in a piece of plexiglass every inch, in holes that I drilled, then hot-glued in. This was ultimately mounted into a box with a frosted piece of plexi in front of it, which gives them much better dispersion and makes it look like solid light instead of many small points.
The circuitry was the reason that the project took 3 years to complete. Since there was no way that I was going to be able to control 48 channels with a parallel port, I found a microchip that could control 24 LEDs (or channels as I used it) by feeding it a signal with a clock, then latching it in and grounding the pins that were given a high signal to complete the circuit to attached LEDs (http://www.allegromicro.com/en/Products/Part_Numbers/6276/). Stringing three of these together gave me the 48 channels that I needed, so that was a step in the right direction. Since 12 of the channels needed to be power supply rather than ground, I added an array of 12 PNP transistors that gave me the functionality I needed for that.
All this was completed my sophomore year as well, but this was the point at which I got stuck. In order to feed the LED controlling chips data to multiplex the array at all, I had to have something with the capability of sending out the required signals, and then would be able to interpret a signal from the computer with what it is supposed to display. At that time, the only thing that I and anyone I talked to could come up with to serve that purpose was a microcontroller. I had absolutely zero experience working with anything like a microcontroller, however, so after many hours trying to work that out, I shelved the project.
A few months ago, I was talking to a friend about his senior design project for Electrical Engineering, and he mentioned a chip that was a USB controller and gave 8 pins of control at high speed to a breadboard and had a C# plugin allowing it to be used with almost no effort (http://www.ftdichip.com/Products/EvaluationKits/UM232R.htm). Immediately, I recognized that this could eliminate the need for a microcontroller and allow me to finish the project; I ordered one the next day. The time from when I received the device to when it started working on the actual grid was only a few hours, which I think is pretty awesome - most of the code I wrote with very little testing and the circuits I designed with no history of circuit design or way to test them worked perfectly. It took a few tweaks on the code and device, but it is now working great. The only functionality that is not working is the volume level control; for some reason it is not registering any sound, and I did not design the control so I can't really debug it very well. I built a basic container for it with the frosted screen and all, and eventually may put it into the top of a bar. This works in a manner very similar to how the 8-switch panel sends out data; it converts Booleans to a number which is sent out to the USB/pins controller and is outputted giving the proper pins signal.
RFID Unlocker
This is part 2 of the door openers.
After I moved out of the dorms into a house, I concluded that i needed another door opener system for my room door. However the system that I used in the dorms of pulling the handle down to unlock the door no longer worked. Additionally, I wanted to upgrade to RFID so that I did not even to have to take the card out of my wallet. The RFID board that I used in this project is a Phidgets RFID USB module (http://www.phidgets.com/products.php?category=14&product_id=1023 , I got mine for $10 from Ebay), which has a couple really nice features. First, it is USB, which means that I am not limited to older computers that have parallel ports. Second, it has an awesome driver and C# .NET module that throws a system message when a tag is read. This makes it extremely easy to just write a method that is called each time that the application 'sees' the appropriate message. Finally, the board contains 2 pins that can be controlled from an application that can put out enough power to activate a relay. I created an application that listened for the appropriate message and dealt with it that generally lived in the system tray, but also had a small interface with information about the most recent entry. To control what tags were allowed entry, I created a file that would be referenced that contained allowed tags and their respective owners. The application then logged each tag so that I could go back and see what tags were tried, if they were identified, and what the result was (opened/not opened). To handle actually opening the door, I purchased a fail-secure electronic door strike for ~$20 that, once a voltage was applied to the pins, would allow the door to simply be pushed open. I used one of the control pins on RFID board to activate a series of relays that activated the door strike, allowing the application to let the door be pushed open. Put them all together on a dedicated computer with battery backup and voila, it works. I attempted to have everything (USB data, 5v, 12v, strike activation return) go over a cat6 cable to the box to increase security, but was unable to get USB to travel over the cat6 (I read many articles on it, and think that the reason is because it already goes ~8 feet when it hits the cat6 injector, then an additional 4 feet or so over the twisted pairs, and signal degradation is just too much over that distance). In the pictures, the black USB B connector in the box that is just hanging there is left over from that attempt.
Sunday, November 15, 2009
Dorm Room Door Cardswipe Unlocker
For the method of opening the door I had to have something that was nondescript enough that it wouldn't be stolen or broken, but also wasn't something that could easily be hacked, because that would defeat the purpose of locking the door in the first place. After doing some research on what would fit within my limited budget, I found a used magnetic stripe reader on ebay for $15 that interfaced with a standard keyboard port. This was doubly nice, because it would allow me to use a standard Purdue ID card as the key, and others could be entered with just their Purdue ID number, which was coded onto the card.
Having come up with a solution for getting input, I could then move on to how I would unlock the door itself once a person was confirmed. This was an issue that stumped me for quite a while, because of the constraints of not modifying the door impeding door functionality. What I eventually came up with was a motor that ran off of 9v and ran through a massive gearing-down that pulled down a rope, which pulled down the handle, which unlocked the door (the first image below). I was really lucky with the type of door handle that we had, because it only was openable from the inside by pulling down, and pulling down on the locked door unlocked it. As a result, the rope that attached to the motor just went slack when it was opened normally, and it just had to pull the handle to unlock the door.
The second image below shows the circuitry that controlled the motor, which turned out to be a lot more complex than you might think. To interface with the computer, I found a class that allowed extremely easy control of the parallel port. The result of this, was that I had 8 pins that I could easily turn on or off, and would provide ~1.5v to the active pins. I found solid state relays that were perfect for this purpose. SS relays are basically electronic switches that connect 2 pins when a small voltage is applied to the other 2. While this was good for activating the motor, I also needed a way to be able to reverse the motor, and for that I needed a mechanical relay. For that I had a SS relay that was activated from the parallel port activate a mechanical relay to reverse the motor's direction (to let the handle back up). Finally, I found that some of the time, the motor would keep running, because there was a trickle of power running through that kept the circuits closed, so I added an additional set of relays that disconnected the power supplied (9v for motor and 12v for relays) from mains power.
This box I kept in a drawer with the computer that controlled the door, and it had a long keyboard cable running to the card reader, 2 wires running to the motor on the door, and mains power.
Once I had all the mechanical parts finished, I needed the code to run all of it. I had the parallel port class that allowed me to control physical things from code, so that part was easy(once I found that). The computer that this app was running on was an old laptop with no screen that would be sitting in a drawer accessed via remote desktop, and I wanted an easy way to modify the user control list. For this, I had the program copy an access control file from a network drive every hour that contained Purdue IDs and names so that it could be logged back to the server in case something went missing. For getting the data from the card reader, the reader sent a specific series of characters and emulated keystrokes whenever it read a card, so I made a service that listened for that series of keystrokes, parsed the ID from it, and acted accordingly.
As an interesting sidenote, I recently found out that my card reader has become somewhat of legend in Cary, and people are still talking about it 2 years later. Awesome.
This was the version that I had in the dorms, and once I moved to a house where I could modify things, I made version 2, which I will go over in my next post. Let me know if you have any questions!












