Wireless Tower of Lights

From Mindworks
Jump to navigation Jump to search
Tower Lights Show
Sponsors
  • 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 | edit source]

Background[edit | edit source]

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 | edit source]

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 | edit source]

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.

This is a flow chart of how the old Tower Lights system operated. It used CAT-5 wiring, which we will eliminate.

Lead2017What We Want.png
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.

Specifications[edit | edit source]

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.

Project Problems/Solutions[edit | edit source]

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.

Design[edit | edit source]

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.

CAD Modeling[edit | edit source]

Before initial prototyping, we created a CAD model.

Diagram Description
Lead2017Light Bar.png
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.

Electrical Components[edit | edit source]

Below are some diagrams showing the electrical components and considerations about their selection in our design.

Diagram Description
Lead2017Zigbee.png
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.

Lead20179V Battery.jpg
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.

Lead201718650 Battery.jpg
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.

Lead2017ParallelLED.jpg
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.

Lead2017SeriesLED.jpg
Diagram of Potential LED Circuit: Series

By running LEDs in series, we would require higher a higher voltage battery.

Implementation/Testing[edit | edit source]

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

Prototyping[edit | edit source]

Diagram Description
Lead2017HardwareList.jpg
List of All Hardware Used in Prototype.

This list contains all of the components used in the production of our wireless light bars.

2018leadcircuit.png
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.

2018leadprototype.jpg
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.

Testing[edit | edit source]

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.

Document Archive[edit | edit source]

Schedule[edit | edit source]

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
Diagram Description
2018leadshedule.png
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.

Meeting Minutes[edit | edit source]

Our meeting minutes and meeting agendas can be viewed at the following URL:
Meeting Agendas and Minutes

Presentations/Reports[edit | edit source]

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

Software[edit | edit source]

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[edit | edit source]

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

Bios[edit | edit source]

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

Contact[edit | edit source]

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