Wireless Tower of Lights

From Mindworks
Jump to: navigation, search
Tower Lights Show
  • Dr. Rinker
Mentor Bruce Bolden
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.

Project Overview[edit]


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.

Problem Statement[edit]

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.

Project Goals[edit]

The current control system must be made wireless. The changes that we will make to the system are outlined below.

Diagram Description
Lead2017What We Have.png
Diagram of the current Tower Lights System.
Lead2017What We Want.png
Diagram of the desired Tower Lights System.

Project Problems/Solutions[edit]

Problems encountered during the project, as well as our solutions to these problems, are outlined below.

Problem Solution
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.

Diagram Description
Lead2017Light Bar.png
Sketchup 3D Rendering of Finished Wireless Light Bar. Batteries and Wireless Receiver Mounted on Top.
Diagram Description
Wireless Protocol Doesn't Interact With Wifi.
Lead20179V Battery.jpg
Specs For Potential Battery: 9V
Lead201718650 Battery.jpg
Specs For Potential Battery: 18650
Diagram of Potential LED Circuit: Parallel
Diagram of Potential LED Circuit: Series


Initial implementation and testing of our design has just begun. Below you can see the hardware we plan to use followed by our schedule.


Diagram Description
List of All Hardware Used in Prototype.


The schedule for out project has not changed much since the beginning. Here is a basic outline of the entire schedule of the project.

Month Tasks
August Project Selection
September Team Assignment and Initial Client Meeting
October Project Learning
November Initial Prototyping
December Prototyping and Unit Testing
January Finalize Hardware Decisions
February Production of Final Hardware
March Scale Testing
April Final Testing
May Deliver Final Product

Team LEaD Design[edit]

Our team has 4 members, all of which provide unique talent and bring new ideas to the table.


Team Member Major
Adrian Beehner:

Adrian is a remote student, this can introduce unique challenges. He directs the budget for our project.

Computer Science
Andrew Butler:

Andrew is in charge of documentation for the project.

Computer Science
Kevin Dorscher:

Kevin is the client liaison and organizes team meetings.

Computer Science
Paul Martin:

Paul is the team's Wiki-master and designer.

Computer Science


Paul Martin (mart2659@vandals.uidaho.edu)
Kevin Dorscher (dors7905@vandals.uidaho.edu)
Andrew Butler (butl6046@vandals.uidaho.edu)
Adrian Beehner ()