S18: RGB LED Sound Behavior on a Skateboard
Contents
Project Title
RGB LED Sound Behavior on a Skateboard
Abstract
Consumers are always looking to customize and decorate their belongings and clothes with lights and flamboyant colors. With music festivals, parties, and LEDs usage on the rise, we can design a behavioral system that influences the intensity and color of the RGB LEDs on products such as a skateboard, t-shirt, bike, or other countless products. The behavior LEDs can be a great attraction to music lovers and to other applications when groups of users are involved. Applications such as an echo or synchronized effect can be done and implemented using Nordic Wireless Mesh Network.
Objectives & Introduction
The project focuses on the idea manipulating an array of LEDs based on sound input. The array of LEDs could mimic a sound equalizer, change colors based on the sound intensity, beat, or frequency of the music. This project would be placed on a transportation tool such as a bike or skateboard simply for the aesthetics. A microphone or 3.55 mm jack would feed the analog data, and then be converted to digital via an ADC IC that outputs frequency bands. A PCB board will be used to power all LEDs, have a display terminal for user input features, and microphone/3.55mm jack connection. The data fed into the SJone board will then be filtered, processed, then sent to display onto the LEDs according to the music.
Team Members & Responsibilities
- Alan Chen
- LED Driver & sound behavior mechanics, code integration for LED Design
- Dhaval Raval
- PCB design, Hardware Design
- Sarvesh Harhare
- Audio Signal Processing, Data Packaging
- Kathan Patel
- Data logging
- Audio Signal Processing
- Niraj Surti
- Availability of data collected over local network to be accessed by other modules.
Schedule
| Week# | Start Date | Planned Work | Actual Work | Progress |
|---|---|---|---|---|
| 1 | 4/10/18 | Project Job Discussion/Parts List | Project Division Discussion/Project Scope | Complete |
| 2 | 4/17/18 | WikiPage/PCB Design/Parts Ordered/Coding | Majority Parts Received/Drivers Written | Complete |
|
|
|||
| 3 | 4/24/18 | PCB Design/Nordic/LED | PCB Design/Nordic/Testing LED Drivers | Complete |
|
|
|||
| 4 | 5/1/18 | Implementation/Testing PCB/Coding | Ordered PCB/LED Behavior Modes/Debugging | Complete |
|
|
|||
| 5 | 5/8/18 | Testing/Debugging/Hardware Design | LED Mode Input/Nordic Wireless Integration/Freq Analysis | Complete |
|
|
|||
| 6 | 5/15/18 | Debugging/Mounting/Finalizing | Mounting and Testing | Complete |
|
|
|||
| 7 | 5/22/18 | Final Exam/Writing Report |
|
Complete |
| 8 | 5/23/18 | Demo/Presentation |
|
Complete |
Parts List & Cost
| Part Name | Cost Unit Item | Qty | Comments |
|---|---|---|---|
| SJone Board | $80 | 3 | LED behavior & Wireless hub (send & receive) |
| Skateboard | $40 | 1 | Project Mount |
| LEDs strips | $26.95 | 2 | 1 Meter RGB LED strips |
| PCB | $30 | 3 | One for each SJone Board |
| 3.5mm Jack | $7 | 1 | Receiver of Music |
| USB Type B Connector | $0.75 | 2 | Power Source for LED |
| MSGEQ7 | $4.95 | 1 | 7-Band Graphic Equalizer |
Design & Implementation
Hardware Design
Hardware Configuration The block diagram and the connectivity of the hardware is shown in below block diagram of hardware.
The hardware is design in Altium Designer. PCB and Schematics were designed in Altium for our application. The Hardware has two main different part one is the audio input interface and other part is to provide power and SPI connectivity to the RGB LED strip. To design hardware in altium first we have to create a new project and inside new project we have to create new schematic documents in which we can design our circuit. Altium does not have the component libraries for every component which were used in the project. For that, we have to create a new library and create components schematic symbol and PCB footprint according to the datasheet. After designing the circuit in schematic we have to create new pcb document in the current project and change the size according to the estimation of the footprint.
Schematic Design
The schematic diagram below shows the circuit of the audio interface which can be fed via microphone or the 3.5mm audio input jack. The header is for selecting the audio input source either from Microphone or 3.5mm Jack. MSGEQ7 is used for filtering the audio input for 7 band. USB type B connector is for power connection for RGB LED strip as it consumes high power and we can not supply it from the SJONE boards.
PCB
After creating the PCB document we just have import changes from schematic which will import every component in the pcb document with marked possible net connections. We have two option for routing auto routing and manual routing. We chose manual routing as auto-routing needs to be implementing lots of rules for trace work and still it wasn't efficient so we opted for the manual routing. Before starting the routing we have to set up rules to make sure the pcb design correctly. The most important rules are in the Electrical section which is clearance, short-circuit protection and Un-routed net connection. Also, we have to take care of the polygon rule as we have ground plane set up. After completion of the traceroute we put plane for the ground layer. PCB size is 2.55 in x 2.275 in. The ground plane is placed on bottom layer for batter connectivity ground. Minimum trace width is 8 mils and maximum is 12 mils as we do not have high power traces. After the board completion, we have to generate files for fabrication. We have to generate Gerber files and NC-Drill files and send it to PCB manufacturer.
Altium PCB View
PCB view of different Layer
Audio Analyzer
Introduction:
This Audio Analyzer module features the MSGEQ7 graphic equalizer display filter. Sound is broken down into seven frequency bands and the peak level for each band can be read. The seven frequencies measured are as follows: 63Hz, 160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz and 16kHz. This Audio Analyzer module can be used to create sound visualizers, detect patterns in music or add sound activation to the microcontroller.
Description:
The seven band graphic equalizer IC is a CMOS chip that divides the audio spectrum into seven bands, 63Hz, 160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz and 16kHz. The seven frequencies are peak detected and multiplexed to the output to provide a DC representation of the amplitude of each band. No external components are needed to select the filter responses. Only an off chip resistor and capacitor are needed to select the on chip clock oscillator frequency. The filter center frequencies track this frequency. Other than coupling and decoupling capacitors, no other external components are needed. The chip supply can be between 2.7 and 5.5 volts with 5 volts providing the best performance. The device has very low quiescent current (less than 1mA typical) for portable audio devices. The multiplexer is controlled by a reset and a strobe, permitting multiplexer readout with only two pins. The multiplexer readout rate also controls the decay time (10% decay per read), so no external pins are needed for this function.
Multiplexer Operation:
The DC peak output for measurement is selected using the reset and strobe pins. Reset high resets the multiplexer. Reset low enables the strobe pin. After the first strobe leading edge, 63Hz output is on OUT. Each additional strobe leading edge advances the multiplexer one channel (63Hz, 160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz etc.) and this will repeat indefinitely. The multiplexer read rate is also the output decay time control. Each read decays that channel approximately 10%.
RGB LED Strips
The WS2801 IC is a LED driver designed for RGB LED displays and lighting systems. In the project, the WS2801 is utilized in a cascading RGB LED strip. The WS2801 adopts a two-wire input control scheme, consisting of a data and clock input. The WS2801 will either output a PWM waveform (out of Bout, Gout, Rout) or send the data and clock to the following WS2081 using serial shift registers. In order to communicate and manipulate the RGB LED's, SPI is suggested in order to drive the clock and specified data waveform into the WS2801 (refer to software section). In order to latch the data fed into the WS2801, a 500 micro-second period (where the clock input is set low) is required in order shift the data into the next cascading WS2801. The following images below and table will give a diagram of the WS2081 pinout and basic circuit diagram of the LED strip. Since the WS2801 echos the data to the next WS2801, users will be able to address to each individual LED and set the color upon latch.
| Specifications | Min | Max | Units |
|---|---|---|---|
| Input Clock Freq | 25 | MHz | |
| Power Supply Volt | 3.3 | 5.5 | V |
| Latch Time | 500 | us | |
| Input Current | -1 | 1 | uA |
| Constant Output Current | 5 | 30 | mA |
| Output Pin Voltage | -0.3 | 7 | V |
| Power Dissipation | 600 | mW | |
Hardware Interface
General Purpose Input Output (GPIO)
There are four switches (SW0-3) existing on the SJone board. Each switch is treated as an input pin. Each input pin symbolizes a feature for the LED strip (Mode, Color, Mode Behavior, Speed/Color Difference respectively). In order to make sure the button was treated once for a single press, a basic de-bouncing check was done.
Serial Peripheral Interface (SPI)
The SJone board utilizes SPI in order to communicate to the WS2801 IC (RGB LED strip). In the datasheet, the WS2801 takes in a CLK (SCK1) and DATA (MOSI1) Input from the SJone. The SJone board has two available SPI pins. However since SPI0 was utilized by the Nordic, SPI1 was the only SPI pin used to run a single LED strip consisting of 32 single bit RGB LEDs.
The micro-controller is connected to Nordic IC via SPI0 peripheral. Pins 15,16,17,18 of Port0 are SCK0 (clock), SSEL0 (Slave Select), MISO and MOSI respectively. A Hardware Interrupt flag (NORDIC_IRQ) is attached to Pin 22 of Port0, through an LED, as an External Interrupt.
Analog to Digital (ADC)
The Audio Analyzer has 4 main pins which are Left audio input, Strobe, Reset and Analog data out along with Vcc and Gnd. The Analog output goes to the 0.26 Pin of the SJOne board for analog to digital conversion whereas the Strobe and Reset are controlled by GPIO 0.0 and GPIO 0.1 respectively.
Transmitter Interface
On the transmitter side, LPC1758 is connected to MSGEQ7 via GPIO and with on-board Nordic Chip via SPI0 interface. Here is the detailed interface diagram:
Receiver Interface
On the receiver side, LPC1758 is connected to LED Strip via SPI1 and with on-board Nordic Chip via SPI0 interface. Here is the detailed interface diagram:
Software Design
SPI & Timer Counter (TC) Interrupts
In order to send data to the RGB LED strips, certain timings and sequences must be sent and executed to change the LED strip behaviors. The SPI was used to communicate to the RGB LED Strip through 3 bytes of data that represent the Red, Green, and Blue 0-255 bit ratio. The Timing Interrupt was used in order to time a specified delay for the individually-address LEDs.
According to the WS2801 datasheet, a minimum of 500 micro-seconds is required to latch the data to the WS2801 IC. In order to create that delay, a timing interrupt of 666 micro-seconds was created to (frequency of 1500 Hz) trigger a flag counter that will allow a queue of SPI data to send to the RGB strips once the counter reaches a desired amount. A longer timing was made to give a small room of error for the WS2801 to latch. Depending on the amount of LEDs, X amount of 24 bit RGB data(s) will be sent to the RGB strip before setting a flag to latch the data to each individual strip. N * 666 microseconds of data can be used to latch the data. The longer the N, the longer it will take to refresh the LED strip and see live changes.
When the SPI data is sent to the WS2801, the Blue data must be sent first instead of the Red data. This is due to the WS2801 interpretation of the RGB data. The WS2801 IC expect the least significant byte first to the most significant byte last (due to Endian interpretation).
Nordic RF Module
The communication between Audio Analyzer module and LED Display module is done utilizing the on-board Nordic IC. The analog data collected from audio equalizer chip is converted to digital format using ADC peripherals on the board. The data is then processed to determine speed, intensity and frequency range of operation before formatting and storing this data in a data structure. To decrease the payload size of packets, all the aforementioned properties of a band of frequency range are coded in one byte. Data of all the bands is then transmitted in a single packet. At the LED Display module, similar Nordic IC receives the data and extracts band information from the packet and sends to the task that is reponsible for changing the behavior of LEDs in the strip.
Structure of the transmitted packet
Strip No. - This is a 3-bit field that selects which strip, out of four, to select to display the equalizer behavior. Four most populated bands are selected from the equalizer IC and mapped to this field. Lower frequency range bands are mapped to Strip 0 and as bands of frequency increase, they mapped to Strip 1, 2 and 3. Most of musical tunes have frequencies that lie in the range 160 Hz - 2.5 Khz.
Speed - This 1-bit field determines the speed or refresh rate of the LEDs. Two lower frequency bands sets this field as 0 which indicates LOW speed. Two higher frequency bands are selected as HIGH speed. Frequencies in higher frequency bands and higher refresh rate.
Intensity - This 3-bit field determines the magnitude in a particular frequency band. Since one strip has eight LEDs, magnitude of 0% is mapped to 000 and 100% is mapped to 111. This magnitude is derived directly from the Audio Equalizer IC according to the bands selected.
Payload Content:
As magnitudes of different bands are received from the ADC, they are formatted and stored in an array. At every iteration this array is updated in intervals of 10 ms. Four most populated frequency bands are chosen and payload is generated using the mesh_form_pkt() function. The formed packet is then sent across using mesh_send_formed_pkt() function.
ADC Readings
There are 2 tasks, one that reads the ADC data and the other that sends the data through Nordic. In the ADC data read task raw data is collected and the intensity is calculated and packed in a byte field along with band number and speed. The Nordic send task then sends this data to the LED controller for displaying the information on the LED strip. *Refer to nordic section for the exact data sent.
LED Display
There are four modes, two behavior features, multiple selections of colors, and speed (refresh rate) in the LED display driver. Based on what was desired, specified algorithms were applied to create the behavior seen in the video and demo. The majority of the code for the LED modes and behavior is written in the LED_driver file and certain traits such as speed, behavior, or button features is updated in the main.
- Mode Selection
- Rain Mode - Rain mode makes the LEDs look like they are following a certain direction. This is done by using the rain mode algorithm in the images below and on the right. The algorithm states the last LED (last array value in dataLed) should copy the LED trailing behind as the next iteration of color. This is all done in the "For" loop, while the first array value accepts the new color or no color to create a separation effect between the colors.
- Pulse Mode - Static LED colors pulses from a faint to bright. This is done by assigning all LED's the same color but drop the intensity of the RGB spectrum. In code, simply send a scale the RGB values from 0% to 100%, then 100% to 0% to see this effect.
- Sound Mode - This mode is a mixture of rain mode and equalizer mode. It changes color base on intensity of only two bands but the colors say on the board until the next set of audio data overlaps the old information. In order to accomplish this, following both part of the equalizer algorithm and rain mode algorithm will achieve what is displayed below.
- Equalizer Mode - This mode display four bands out of the seven on a single 32 bit RGB strip on four segments of 8 individual LEDs. Depending on how many frequency bands are displayed, there are the same amount of "For" loops as show below. Each "For" loop represents a 8 LED segment of the strip. Depending on the data received from the wireless packet, the intensity of the frequency band is translated through the height of the 8 LED segment. Displaying on all 8 LEDs mean that the intensity of the band is at its peak while displayed none means there is no intensity or ADC reading in that frequency band.
- Color Selection - Select specified colors by changing the RGB data points. This is done via a switch case function and defines the data that will be sent in a queue towards the SPI pins for the LED strips. The image below shows part of the color selection algorithm and is used by all modes. This function is known as the void function "color_spectrum" displayed in images in the "Mode Selection" section.
- Behavior Selection
- LED Separation - Selects LED separation in rain mode. This is achieved by simply turning off a specified amount of LEDs before updating the desired color set by the user. *Refer to rain mode.
- Speed/Color Difference Selection
- This selection changes speed via refresh rate and the color difference gap when using the rainbow spectrum display. This is changed using a couple variables and will update the system according through the interrupt (for speed) and color_spectrum function for color difference.
The main() Function
The main() function at the transmitter side, creates a semaphore used to synchronize ADC and wireless sending tasks. The main function also selects pins that are to be used as ADC inputs, initializes the ADC driver and starts to read the ADC values using class functions. Also the wireless driver is initialized using wireless_init() function. Two tasks are created readAdcData() and nordic_send() using xTaskCreate() FreeRTOS API. readAdcData() task has higher priority than nordic_send() task.
The main() function at the receiver side, creates four tasks sound_input(), transmit_LED(), button_mode() and nordic_rx(). sound_input() task is responsible for selecting a pattern to glow LEDs on the strip. In order to generate different patterns, different sets of data is sent to the LED strip. transmit_LED() tass sends the data to the LED strips depending on pattern selected by sound_input() task. A queue is created for these two tasks to achieve inter-process communication. button_mode() task uses four buttons on the SJone board as an input to change patterns generated on LED strips. nordic_rx() task is the receiver task that is block waiting till it receives any data intended for it over a particular channel. nordic_rx() and button_mode are high priority tasks while transmit_LED and sound_input are medium priority tasks.
Implementation
RGB LED STRIP
As show in the RGB LED Strip RTOS tasks, there are 5 tasks running. Each task have their own crucial responsibility in getting the project running with user capability.
Tasks:
- sound_input: PRIORITY MEDIUM
- This task requires a queue and selects which data will be sent to the RGB LED strip(s). All the processing and data/input selection is made here. This file requires the LED Driver library created by the team in order to get this task running functionally. This task also needs TC Interrupt Drivers in order to time when to send the queue at the exact moment (when the data from the individual LEDs latch). The task was set to medium but delay is set to zero with the transmit_Led. This task will run whenever it has the opportunity.
- transmit_LED: PRIORITY MEDIUM
- The transmit_LED task is what sends the data, received from sound_input task, to the WS2801 RGB LED Strip(s). The task requires the SPI drivers and is pretty simple. The task was set to medium and yields with the sound_input task. This task will run whenever it has the opportunity also and will execute its feature when a queue is received.
- button_mode: PRIORITY HIGH
- Button_mode task checks for the input from the user from the SJone switches. In order to not register multiple times from a single press, a simple de-bouncing guard was created. Each switch represents a different feature on the board described on the software side. This task is purely for user configuration and behavioral choices. The task is set to high because the switches needs to be detected without interrupts or EIC.
- nordic_rx: PRIORITY HIGH
- The nordic_rx task is mainly to receive the data sent from the other SJone board transmitting the data (frequency bands and intensity). When sound or equalizer mode is set, the data packet is then interpreted and sent to the sound_input for processing. The task is also set to high because receiving data from the SJone board is required in order to update the LED strip when in sound or equalizer mode.
- wirelessTask: PRIORITY HIGH
- The wirelessTask is the crucial task used to receive or send data when interfacing the Nordic. Without this, the wireless transmission portion would not work because the SPI0 drivers and other features were included in this task. This task is set high.
Nordic Wireless
At Transmitter Side:
- Obtain input from ADC and determine speed, intensity and band of frequency range.
- Form the payload with the data using correct destination address and an appropriate acknowledgement scheme.
- Send the formed packet.
At Receiver Side:
- Extract the band information from the received packet.
- Send the data in a queue for the LED task to receive and modify LED behavior.
Testing & Technical Challenges
SSP SPI Conflict
| Goal: | Have two SPI (SSP0 & SSP1) running for RGB LED Strips. |
| Issue: | SSP0 (SPI0 - SCK0/MOSI0) was not functioning as expected with the Nordic integration. |
| Background | The plan was to utilize two SPI MOSI/CLK to drive two 16 RGB LEDs strips in parallel. The SJone LED board was functioning as intended until the Nordic Driver and wireless protocols were introduced into the program. The SSP0 (SPI) port was flickering the RGB LED strip and behaved incorrectly despite receiving the correct data in the terminal. In attempt to fix this, the wireless communication data was sent at a slow rate to compensate the flicker. This was not the best solution and more investigation was required. |
| Conclusion: | SSP0 (SPI0) was utilized by the Nordic, hence whenever the SJone received data, the SPI0 data sending to the strips did not function or send data correctly or at all. In order to fix this issue, one 32 bit RGB LED strip was utilized (instead of two 16 bit LED strips) at SSP1 (SPI1) while mimicking the same behavior as two separate LED strips. |
Attaining 800 kHz on a PWM LED Strip
| Goal: | Achieve 800kHz PWM on a LED strip (WS2812B). |
| Issue: | Barely Reach 800kHz PWM using PWM Interrupt Driver and/or TC Interrupt Driver without precise duty cycle changes. |
| Background | A RGB LED strip (WS2812B) required less than 100 microsecond precision when sending data to the RGB strip. Since there was only a data input and no clock, the protocol was of an asynchronous design. However, reaching to a precise timings and data output to the RGB LED with GPIO or PWM was difficult without exact timings and interrupts. In order to accomplish this, PWM Interrupts and TC interrupts were investigated to see if this goal could be achieved. |
| Conclusion: | Hardware can barely obtain ~800kHz waveform at the cost of RTOS performance and requires speed of a PLL CPU speed of 100MHz on SJone. It makes more sense to utilize a dedicated FPGA to drive the LED strip and the SJone board was simply not design to handle this LED strip with multiple tasks. Hence the group decided to utilize different LED strip and change protocols to SPI. |
Smooth transfer of data in the wireless network
| Goal: | Continually transfer data from over wireless channel with minimum delay. |
| Issue: |
Hardware Interrupt generated in the Nordic IC essentially bricking the transmitter board until reset. SJone board crashing after receiving few hundred packets of data. |
| Background |
It was observed that after transmitting two packets, an hardware interrupt disrupted the flow. The data sheets revealed that a bried 4 ms delay was mandatory between every transmission. Since initially board received few packets before crashing, available system memory was monitored at regular intervals.The bug in the code was traced to wireless initialization API being called multiple times. |
| Conclusion: | After fixing the aforementioned bugs, the communication was continuous and smooth. |
Conclusion
We were successfully able to complete the implementation of RGB LED behavior on the skateboard. This project gave us a good experience of working on a complex project with Team Environment. This project helped us to learn freertos in more depth. The initial problem was the finding proper hardware for the project which was challenging task as we have to change our hardware many times. The custom message packet format we created to work between modules proved to be very efficient and simple to use. Different Sound mode under the Skateboard looks good. We hope to see such products in markets to attract youth.
Project Video
Project Source Code
References
Acknowledgement
We would like to thank the CMPE244 Team and Professor Preetpal Kang for their guidance and Spring 2018 semester. Past labs/assignments has help lead to the completion of this project by covering materials in SPI, PWM, ADC, GPIO, and FreeRTOS.
