Raspberry Pi Conference Room Schedule Display

The company I work for recently moved into a new office, and I've been wanting to make a digital display to put outside the conference room I'm near, so that I know if it's free for ad-hoc meetings, or if I need to find somewhere else to convene.  Since I recently worked on a project that involved querying Exchange WebServices (EWS) to retrieve information, and the room has a shared calendar with the schedule, it seemed like a pretty straightforward project.  It was.

Part 1 - The Hardware

Start with one Raspberry Pi (http://www.amazon.com/RASPBERRY-MODEL-756-8308-Raspberry-Pi/dp/B009SQQF9C), add a 2.8" TFT touchscreen that attaches on top (http://www.adafruit.com/product/1601), and a micro USB Wi-Fi receiver (http://www.amazon.com/gp/product/B003MTTJOY).  Cobble together the two boards into a case printed on a MakerBot (box from http://www.thingiverse.com/thing:233396), configure the operating system to connect to the office network and launch the browser to the schedule in fullscreen, and presto, you've got a dandy device that can display the schedule outside a conference room, with only a power cable going to it.

Part 2 - The Software

Using EWS, write an app to retrieve the events from a shared calendar (in this case, the calendar for the conference room in question).  Push that data into a database, and schedule the app to run every hour (Efficient?  No.  Effective and simple?  Sure is).  Then create a simple PHP web page to query the database for the data and format it into a website designed for the screen resolution of the TFT.  Bam, you just created a conference room schedule board that shows the meetings scheduled for each day.

End result:

Nerf Escalations

For a period of time, our office was in an all-out Nerf war.  Truly, there were battles to be remembered.  To gain true superiority, I decided it was necessary to, not only get a weapon superior to others, but modify it to gain yet more power.

It all started with a Nerf N-Strike Rayven.  For those not well versed in the world of foam darts, the N-Strike series is designed with battles in mind, utilizing aerodynamically streamlined darts.  The Rayven is one of the guns that uses spinning wheels powered by batteries rather than air to propel the darts.  The wheels counterrotate, the dart is pressed between them, and the wheels fling it forward.

The major advantage of the Rayven for my purposes was that, it was designed with a neat little trick of using glow-in-the-dark darts, with little lights in the magazine that charged them with light before they were fired.  Pretty cool trick, if you're into that sort of thing.  What made it even more appealing, was that the lights were powered by a separate bank of batteries.  

With a little ingenuity, screwdrivers, and hot glue, I re-worked the circuitry to be able to include the magazine's battery bank in with the primary bank that powers the motors.  This ran 10.5v through them, rather than the paltry 6v that comes stock (when I wanted the power, that is.  The switch on the trigger guard allowed the overclocking to be activated or disabled).  With the additional voltage running through the motors, I was able to improve the distance it threw darts by 50% - a nice little bump.  A quick-release, reversable connection between the magazine and the body ensured that reloading could be quick and polarity was never a concern.

They never saw it coming.

DMX Lighting Control Application - And Then Some!

There's been a bit of a dry spell around here, eh?  Shifting from the scholastic world to the professional world comes with it's share of changes, and some projects had to be put on hold for a bit.  Let's get back on that horse!

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.

Grid Mark II

After completing the first version of the grid (see post a couple ago for complete details), I began pondering how awesome it would be to make a new version that had less spaghetti and fragility and was smaller with higher LED density, but had the same basic circuit design and components. The best way to do this was to make a printed circuit board. After doing some research on different options, I decided to try to make the PCB myself using the toner transfer method. The basic idea is to print the circuit on a laser printer onto glossy paper, then iron that onto a copper-covered substrate, then soak it in etchant to remove the copper not covered by the toner, then remove the toner and you have a PCB. Great and seemingly quite simple in theory. If you are looking into this method, I think it would work really well for small single sided boards. My board, however, is 5x8 inches (quite large) and double sided. If I ever did get one side correct, it would be ruined when I did the other side. Long story short, it was a failure. These are the best transfers that I ever got:

So, since DIYing it was out of the question, I looked into where I could get it made for less than a small fortune. Most places were well over $100 for a board of my size, but 4pcb.com has a deal for students where it is only ~$50 for a board including shipping. So, after re-doing my design in their application (wrangling all the wires to fit on 2 sides is not an easy task, and replicating it in a new application is no spring chicken) I ordered the board and crossed my fingers that I hadn't messed it up too badly, as this was my first foray into designing PCBs. A couple weeks later, and voila!

Gorgeous, yes? As an added benefit, ordering it meant that i didn't need to drill all 810 holes myself, and it was coated with a solder mask, which makes it more resilient to wear and tear. This board is actually 2 boards in one that needed to be split; the display is the square part that will hold all the LEDs, and the side board will stick off the back with a 90 degree connector to house the control chips. This means that it can theoretically be places side-by-side with more of it to make a larger overall screen. Future versions will likely contain this functionality. Nevertheless, after splitting the board (running a box cutter down the split 20 times per side or so and breaking it in half along the line), it was time to populate the board. It was at this point, however, that I discovered a mistake in my design that had been in it from the beginning. Without getting into too much specifics, I had switched 2 sets of 4 pins 3 times along the connection between the two boards. After having a minor freak-out, I managed to solve it by disconnecting 24 of the joints in the elbow connector and jumpering it together so the correct pins were connected. This is what the 3 juts of wire are off the side as you'll see. I also needed to re-write a bit of the multiplexing logic, but that only took a few minutes. After about 10 straight hours of soldering, I had myself a completed grid device. All told, there are 882 solder joints, 144 LEDs and 1 board of awesomeness.

Since I was making a new version of the board, I also decided to rewrite the controlling application to make it more user-friendly and include some more useful functionalities. This version adds the ability to dim lights, a large clock (the colon blinks on the second at 50% to 100% brightness) and the ability to display custom color images. To help make these (I had previously been doing it my manually creating a massive boolean array), I made an editor. There are still visualizations that cycle automatically and a marquise that can say whatever you'd like. Additionally, the app is backward-compatable with the old grid.

And now the money shots:

I would appreciate any comments or suggestions or ideas anyone has, new things are always good to add!

8-Switch Panel

This project was something simple that had been mulling around my mind for a while, and made my freshman year. I DJ'd in High School, and for controlling my lights, I purchased a power-strip type device that had 8 switches on the front, and 8 outlets on that back that were, you guessed it, controlled by the switches. This was nice, because it allowed me to turn each device on and off individually. My freshman year, I was inspired by the video of the house that had Christmas Lights that flashed to a Trans-Siberian Orchestra song. To create a similar setup without spending gobs of money, I found a solid-state relay that was activated by the voltage put out by the data pins on the parallel port, and could handle the wattage drawn by lights. Once I had the relays, it was very easy to simple solder a bridge that would duplicate the functionality of the switch through the relay if it were activated, and attach each of the eight relays to each of the eight data lines from the parallel port. One challenge I had was to identify what wires in the parallel cable were the data lines, and what order they were in, but an application that activated one at a time and a voltmeter make that relitively easy.

Once I had the hardware working, I needed to develop an application that would take advantage of the automation capabilities. I decided that the best way to give it similar functionality to the video would be to make the application take a text file of cues, then cycle through the cues on a button press so that the lights could be synced up to the music. Additionally, I had included an automation function in the application that attempted to calculate how quickly the button was pressed, then identify what the tempo was and continue cueing once the tempo was set. The cue file I made by having each line be a new cue, and the line consist of 0s and 1s to indicate that that channel was off or on. For example, 00010100 would use all 8 outlets, with all off except 4 and 6. The application converted that into an integer and transmitted it over the parallel port and, when that integer was converted by the parallel driver into electrical signals, it resulted in the required wires putting out a voltage. For one song, I made a cue file that was several hundred lines; the grew quite rapidly. It was somewhat of a challenge to get the song started and begin cueing right away, but when you got it synched up perfectly, it was really cool. As an added bennefit, the switches still function as originally, so no functionality was taken away.

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.

In looking to what else I can do with this project, I am considering designing a PCB that could be used with this with the LEDs on one side and the contents of the breadboard on either a brother board or the backside of the main board, so that it can have a higher LED density, as well as potentially making it extendable with connections on all four sides to connect the individual components together so that they can work together as a large screen. The code that I have is extremely easy to change for a larger grid size (it would probably only take an hour or so to make it adjustable), and that would be a really cool way to give it more real-world applications, as well as potentially mass-producible. While devices that do essentially the same thing already exist, I'm quite proud that I was able to design this from scratch with only a very basic analog circuit fundamentals class. Please let me know if you want more detail on the circuit design and series of signals to produce the desired output; I figured that would not be of interest to anyone else except someone working with the same LED controlling chips, which I can recommend as working quite well if you are doing a project with a lot of LEDs.

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.