Wireless Tower of Lights
|Tower Lights Show|
|Team Name||LEaD Design|
|Duration||Fall 2017 - Spring 2018|
The Wireless Tower of Lights at the University of Idaho is an ongoing project to convert the show's electronics to a fully wireless system. The Tower Lights show is displayed on the south side of the University of Idaho's Theophilus Tower. Each window is rigged with a set of LED lights which illuminate in synchronization to music. The old system relies on the building's unused CAT-5 wiring that runs from the basement up through every room. The new system will not rely on wires, and could be used in any building.
- 1 Project Overview
- 2 Design
- 3 Implementation/Testing
- 4 Document Archive
- 5 Team LEaD Design
The Tower Lights Show has been an exciting part of the University of Idaho for years. The system used to make this light show happen is outdated however. We are renovating the Tower Lights hardware and making it wireless. This new system will be easy to transport and set up, so that the light show could be used in any building. There has been interest for using the system in buildings in Coeur d'Alene, Idaho to put on light shows for events.
The University of Idaho’s Tower Lights system currently runs on old unused Ethernet wiring in the Theophilus Tower. Our team is faced with the problem of turning the current Tower Lights control system into a battery powered wireless system.
The current control system must be made wireless. The changes that we will make to the system are outlined below.
|Diagram of the current Tower Lights System.
This is a flow chart of how the old Tower Lights system operated. It used CAT-5 wiring, which we will eliminate.
|Diagram of the desired Tower Lights System.
This diagram shows the desired system which we hoped to implement from the start. By creating this flow chart, we started off with a solid road map of where we wanted the project to go. This allowed us to make incremental progress and ultimately create a fully functional system.
The system that we design must meet all of our client's needs. The specifications provided by the client are that the light bars must be able to conserve battery for up to three days and then perform a show of up to one hour, and the wireless range should be around 100 meters. The lightbars must produce enough brightness to be visible from a 100 meter distance, and otherwise we were left with a lot of freedom for the design.
Problems encountered during the project, as well as our solutions to these problems, are outlined below.
|We need to identify a wireless protocol to have an effective range of potentially up to 100 meters. Additionally, the frequency must be one that will work even in crowded venues, with lots of different cellphones, and Wi-Fi signals present.||The 802.15.4 protocol (Zigbee) is 2.4Ghz, but will not interfere with Wi-Fi. This protocol can operate at a speed of 250kbps, which is much lower than Wi-Fi, but may be adequate for this project. Shown below is a diagram of how 802.15.4 differs from Wi-Fi.|
|Exact battery selection and design is not yet solidified.||Test a couple different battery options once we have completed the rest of the project. Torture/time test each option.|
|Our wireless protocol can only send 250 kbits/s. If we have enough light bars in a large building, we may run out of bandwidth.||We can change the quality of the RGB color sent to each light bar. For example instead of sending 24bit Truecolor RGB with 16 million possible colors, we could send 12bit RGB and have only 4,096 possible colors.|
There are a couple subsystems to our project including the light bar itself, the LED circuitry, and the battery. Outlined below are the diagrams and thoughts that we have put into the project.
Before initial prototyping, we created a CAD model.
|Sketchup 3D Rendering of Finished Wireless Light Bar. Batteries and Wireless Receiver Mounted on Top.
This CAD model shows how we wanted to layout the lightbar. By the time we got to actual hardware prototyping, we decided to go with four LEDs instead of three, and opted for the 9V battery. By laying everything out in CAD before soldering the actual wires and LEDs on our prototype, we were able to avoid potentially silly design mistakes, like laying out the battery and receiver boards in such a was that would produce excess wiring.
Below are some diagrams showing the electrical components and considerations about their selection in our design.
|Wireless Protocol Doesn't Interact With Wifi.
This diagram shows the channels used by the WiFi protocol as well as the Zigbee protocol. We used the top two channels, as these are above the range of WiFi and this should help to eliminate any possible interference. The protocol we used is the underlying protocol for Zigbee, 802.15.4. This enables us to transmit up to 250 kbits per second.
|Specs For Potential Battery: 9V
We ended up using rechargeable lithium 9V batteries on our final prototype lightbars. This gave us good run times and helped to keep the cost down.
|Specs For Potential Battery: 18650
The 18650 battery provided more power than the 9V, but we did not end up using this battery for the final hardware. It seemed like the best option for most of the project however.
|Diagram of Potential LED Circuit: Parallel
By running LEDs in parallel, we can run a battery with less voltage but it will draw more current.
|Diagram of Potential LED Circuit: Series
By running LEDs in series, we would require higher a higher voltage battery.
Initial implementation and testing of our design has just begun. Below you can see the hardware we plan to use followed by our schedule.
|List of All Hardware Used in Prototype.
This list contains all of the components used in the production of our wireless light bars.
|Circuit diagram of the circuit we used on each lightbar.
This is a diagram of the circuit board that we created for each lightbar. The LEDs are switched via transistors and the microprocessor used is an ATmega328.
|First prototype lightbar fully functional.
This was a very exciting moment for our project. Once we got our first prototype working, we made three more and then the rest of the work was just modifying our code to support 64 channels and to conserver battery before a show.
We did extensive testing on the lightbars to ensure that we met all of our client's needs. We did battery testing to show that the lightbars can withstand a 2+ hour show, and our code is able able to support 64 channels which exceeds the client's need of 40 channels.
The schedule for out project has not changed much since the beginning. Here is a basic outline of the entire schedule of the project.
|September||Team Assignment and Initial Client Meeting|
|December||Prototyping and Unit Testing|
|January||Finalize Hardware Decisions|
|February||Production of Final Hardware|
|May||Deliver Final Product|
|Our Gantt Chart
This Gantt chart shows how our schedule panned out ultimately. We ended up running behind schedule on several items but fortunately we were able to get everything done by the end of the project.
Our meeting minutes and meeting agendas can be viewed at the following URL:
Meeting Agendas and Minutes
Below are links to the presentation material and reports generated throughout the semester:
Snapshot Day 1 Poster Materials
Snapshot Day 2 Poster Materials
Snapshot Day 3 Poster Materials
Expo Poster and Presentation
Final Project Portfolio
Final Design Report
Below is a link to all of the code that we generated in order to make this project work. This includes code that runs from a laptop to broadcast to the lightbars, as well as Arduino code that runs on each individual lightbar.
Wireless Tower of Lights Code
Team LEaD Design
Our team has 4 members, all of which provide unique talent and bring new ideas to the table.
Adrian is a remote student, this can introduce unique challenges. He directs the budget for our project.
Andrew is in charge of documentation for the project.
Kevin is the client liaison and organizes team meetings.
Paul is the team's Wiki-master and designer.
Paul Martin (email@example.com)
Kevin Dorscher (firstname.lastname@example.org)
Andrew Butler (email@example.com)
Adrian Beehner (firstname.lastname@example.org)