SMARTPHONE CONTROLLED JUKEBOX

By

James Lang

Sam Sagan

Nikhil Sancheti

Final Report for ECE 445, Senior Design, Fall 2015

TA: Eric Clark

9 December 2015

Project No. 32

ii

Abstract

This project is a modern redesign of the jukebox. Songs from the Spotify library are streamed over a Wi-

Fi or ethernet connection. Two XLR ports output fully differential, stereo audio. Our jukebox uses the

iBeacon protocol to broadcast its unique identifier to nearby devices, and an iOS application provides

the user interface. Upon opening the application, users are able to select a jukebox from a list of those

currently in range. Once connected, users can search for songs, play song previews on their iPhone, and

request songs to queued onto the selected jukebox. The top surface of the jukebox’s housing features

an LED array, which illuminates the room with an animated rainbow pattern.

iii

Contents

1. Introduction .............................................................................................................................................. 1

1.1 Functions & Features .................................................................................................................... 1

1.1.1 Functions ............................................................................................................................... 1

1.1.2 Features ................................................................................................................................ 1

1.2 Block Diagram ............................................................................................................................... 2

1.3 Block Descriptions ......................................................................................................................... 2

1.3.1 User Interface Module .......................................................................................................... 2

1.3.2 Control Module ..................................................................................................................... 2

1.3.3 Filter ...................................................................................................................................... 3

1.3.4 Software ................................................................................................................................ 3

1.3.5 Sensors .................................................................................................................................. 3

1.3.6 Power .................................................................................................................................... 4

2 Design .................................................................................................................................................... 5

2.1 Raspberry Pi .................................................................................................................................. 5

2.1.1 Operating System .................................................................................................................. 5

2.2 Audio Board .................................................................................................................................. 5

2.2.1 Audio CODEC ......................................................................................................................... 5

2.2.2 Analog Filter .......................................................................................................................... 6

2.3 LED Peripheral ............................................................................................................................... 9

2.3.1 LED Signal Level and Photosensor ........................................................................................ 9

2.4 Software Components .................................................................................................................. 9

2.4.1 iOS Guest App ............................................................................................................................ 10

2.4.2 Main/Control Server .................................................................................................................. 10

2.4.3 Local RPi Server .......................................................................................................................... 11

2.5 Power ................................................................................................................................................ 11

2.5.1 Power Distribution ..................................................................................................................... 11

2.5.2 Power Supply Quality (Decoupling) ........................................................................................... 12

3. Design Verification .................................................................................................................................. 14

3.1 Overall Success .................................................................................................................................. 14

iv

3.2 Shortcomings and Unmet Requirements .......................................................................................... 14

4. Costs ........................................................................................................................................................ 17

4.1 Parts .................................................................................................................................................. 17

4.2 Labor ................................................................................................................................................. 18

5. Conclusion ............................................................................................................................................... 19

5.1 Ethical considerations ....................................................................................................................... 19

5.2 Future work ....................................................................................................................................... 19

5.3 Market Analysis ................................................................................................................................. 19

References .................................................................................................................................................. 20

Appendix A Requirement and Verification Table ................................................................................... 21

Appendix B – Audio Board Schematic ......................................................................................................... 24

Appendix C - Raspberry Pi Connections ...................................................................................................... 27

Appendix D - Filter Test Code ..................................................................................................................... 28

Appendix E - Raspberry Pi Configuration .................................................................................................... 29

Appendix F – iOS Screenshots ..................................................................................................................... 31

Appendix H – iBeacon ................................................................................................................................. 33

Appendix I – Market Analysis ...................................................................................................................... 34

1

1. Introduction Jukeboxes used to be a staple of the social scene in bars. Our Smartphone-Controlled Jukebox will

modernize the old-school device and create a social entertainment system for both the commercial and

home application. Our team is committed to improving the experience of guests and hosts in bars and at

home.

1.1 Functions & Features In designing our jukebox, we examined existing sound systems that share various functionalities with

our product. We differentiate ourselves by providing higher quality sound than some and a far lower

price-point than others. We accomplish this by focusing hardware resources on the audio and building a

robust iOS application.

1.1.1 Functions

We aim to modernize the jukebox. We tap into the ubiquitous and powerful world of smartphones for

our user interface and take advantage of the power and quality of modern processors and audio

integrated circuits. These are the benefits that users may enjoy from our jukebox.

Unlimited access to the entirety of the Spotify music library

Seamless and enjoyable control of the jukebox through an admin app and guest user app

Visually appealing LED lit package responding to the ambient light

User-friendly payment processing

Audiophile-quality audio

Limits users to the immediate vicinity

1.1.2 Features

The following features make our jukebox unique.

Song requests, queue visualization, and payment processing in iOS guest user app

Separate admin iOS app for queue management and payment configuration

56 full-color LED display

Credit card, Coinbase, Venmo, and PayPal payments accepted

Dual-channel, fully-differential XLR output ports for professional audio

Analog audio output with .02% THD+N and no more than 1dB attenuation 20Hz - 20kHz

BLE iBeacon for proximity detection

Ethernet or WiFi connection to internet

2

1.2 Block Diagram

Figure 1. Block Diagram

1.3 Block Descriptions

1.3.1 User Interface Module

Our jukebox provides an audio-visual user experience.

LEDs: The Raspberry Pi sends control signals to individually addressable LEDs embedded in the Jukebox’s

housing. We use a level-shifter at the interface between the Pi and LEDs. The LEDs shift between two

modes of operation based on the ambient light level measured by the photosensor.

Audio-out Port: Balanced, stereo XLR output provides professional quality audio. XLR cables have low

resistance and the differential lines allow for RF noise elimination. This provides the ideal audio solution

for a commercial venue.

1.3.2 Control Module

This module is the heart of our design. It takes streaming audio from Spotify, serializes it, and then

converts from digital to analog to be heard by the user.

Raspberry Pi 2: The Raspberry Pi (RPi or Pi) is a system-on-chip (SoC) with an ARM processor, running

Raspbian OS. It streams audio from Spotify over a Wi-Fi connection and serializes it for the CODEC. The

RPi controls the LED array with a single PWM signal. The iBeacon attached to the Pi broadcasts

3

identifiers for authentication to nearby iPhones. We also attach a Wi-Fi module to allow for either

ethernet or Wi-Fi internet connection. Wired connections are outlined in Appendix C.

Audio CODEC: We use a Cirrus Logic CS4272 which has internal digital-to-analog converters. Our CODEC

converts the serial, digital audio signal of the songs from the RPi to analog. An external crystal oscillator

allows the CODEC to produce a master clock and derive word and bit clocks for serial digital audio

transmission according to the I2S protocol. The CODEC requires external analog filtering.

1.3.3 Filter

Analog Filter: The CS4272 is a high-end IC with great specifications, but it requires external filtering.

Both channels have two differential analog outputs. To achieve necessary flatness of the frequency

response in the audible range with minimum order filters, we use low-pass 3rd-order, active

Butterworth filters. We eliminate DC components of the frequency spectrum with AC coupling at the

filter output. We design the filters to have less than 1dB of attenuation throughout the audible

frequency range 20Hz to 20kHz.

1.3.4 Software

iOS App: The iOS user app will be the user’s main point of interaction with the jukebox. The main

functions of the app are to

Search for the iBeacon

Select the jukebox

Search for songs from the Spotify API

Select a song

Pay to play the song

See the player queue

Braintree: We chose the Braintree API for payments. It has the flexibility to accept payments from

different platforms including PayPal, Bitcoin, Venmo, Apple Pay, Android Pay and credit cards.

Spotify: The Spotify API provides a high quality audio library. It helps search for and stream songs. The

owner needs a premium account to use our jukebox.

Server: The server provides user sessions, handle jukebox sessions, stream songs, and finish payment

loop.

1.3.5 Sensors

Our sensors allow our Jukebox to respond to changes in ambient lighting and proximity of users.

iBeacon: The iBeacon creates a way to uniquely identify a jukebox with a unique major and minor

identifier.

Photosensor: Using a light dependent resistor known as a photocell, this circuit produces a logical high

when the ambient light is high. Conversely, it produces a low when there is little to no light. We use this

output to differentiate the full light and low light modes of operation.

4

1.3.6 Power

Power Supply: Our jukebox draws power from a standard 120V, 60Hz wall outlet. We power our internal

components with 5 V VCC.

5

2 Design

2.1 Raspberry Pi The Raspberry Pi lies at the center of our design. Its operating system (OS) provides a platform on which

we can run software to stream music from Spotify, handle connections with nearby iPhones, and

interface with our hardware. In order to provide this functionality, the RPi must have an internet

connection, load drivers to define communication between hardware and user-space software, and

inform the kernel of external hardware with a device tree overlay.

2.1.1 Operating System

The Raspberry Pi runs Raspbian OS, an operating system based on Debian, which is specifically designed

for the SoC. We use the kernel developed for the SuperAudioBoard, a sound card which uses the same

CODEC as our project. This source includes the device tree files and drivers we need to recognize our

hardware as a sound card and communicate with the CS4272 over I2S and I2C. Appendix E lays out how

the Raspberry Pi is configured.

2.2 Audio Board

2.2.1 Audio CODEC

Our audio board uses a Cirrus Logic CS4272 audio CODEC for audio conversion. The Raspberry Pi feeds

digital audio and control signals into the CODEC, and the CODEC outputs analog audio. There are

important design considerations in using this chip.

I2S is a serial digital audio protocol that involves two clocks and a data line. The bit-clock goes high once

for every bit of audio data. The word-clock selects the channel for which the current word of serial data

is meant--a high voltage selects the right channel and a low selects the left channel. Either the CODEC or

Raspberry Pi may produce the I2S clocks, and is thus the I2S master. In our implementation, the CODEC

is the master. The CS4272 allows us to use an external crystal oscillator to generate I2S clocks internally.

This arrangement provides the most accurate clocks with the least jitter and frequency drift.

We set our CODEC to operate with 48kHz digital audio. 48kHz is the most widely used audio sampling

frequency in professional settings. The CODEC requires certain ratios between the sampling frequency,

bit-clock, word-clock, and crystal oscillator. The operating frequencies are in table 1.

Table 1. CODEC operating frequencies

Sampling Frequency 48 kHz

Word-Clock 48 kHz

Bit-Clock 3.022 MHz

Crystal Oscillator 24.576 MHz

The Raspberry Pi controls the CODEC’s operating modes using an I2C bus and standard I2C protocol. In

this way, the Raspberry Pi sets the CODEC to function as I2S master. Further, the Raspberry Pi produces

6

a separate reset signal tied to the CODEC’s active-low Reset pin. We must enable this control port mode

on the CODEC, as it defaults to a separate stand-alone mode with no I2C interface.

The CS4272 datasheet outlines recommended wiring for setting control port mode and powering the

chip. It also provides a schematic for mute circuitry that eliminates crackles and pops due to transitional

states inside the chip. That schematic is designed for single-ended analog output rather than fully-

differential output, however. Thus, we extended the circuitry appropriately, and we include it in the

schematic in appendix B.

2.2.2 Analog Filter

Design Overview

Our CODEC requires external filtering of the analog audio in order to limit noise and guarantee Total

Harmonic Distortion plus Noise (THD+N) of .02%. Key considerations in designing this filter include the

filter type and order.

Common filter types for analog audio include Butterworth and Bessel filters. Butterworth filters have

zero passband gain ripple, and Bessel filters have zero passband group delay ripple. We chose to use a

Butterworth filter to ensure accurate volume reproduction across all frequencies in the audible range

(20Hz to 20kHz). This does not guarantee a flat group delay ripple, but we decided to listen to our audio

output before determining that this is a problem. This was a reasonable approach because we could

rather easily compensate for group delay ripple with a Group-Delay All-Pass Filter cascaded with the

Butterworth. Ultimately, we decided that group delay does not prove audibly detrimental to our system.

We chose the filter order such that we achieve a balance between transition-band roll-off and bill-of-

materials complexity. A third order butterworth filter provides 60dB per decade attenuation while

requiring two opamps, three resistors, and three capacitors. Figure 2 includes a general schematic for

such a filter.

Figure 2. General filter schematic

Design Details

7

Designing a filter involves deriving the circuit’s transfer function and analyzing the pole-zero form of

Butterworth filters. We use a third-order filter which is composed of a preliminary first-order stage

followed by a second-order stage. The first-order stage merely consists of one RC pole at the cutoff

frequency. We focus this filter design guide on the more intricate second-order stage.

First, we analyze the circuit in the following equation. The transfer function of the second stage,

calculated using ideal opamp assumptions and KCL, is as follows:

In general, a second-order filter has two poles, and our Butterworth filter has no zeros. We analyze the

s-domain pole-zero form with complex poles a ± jb. Note that the magnitude of these poles is always

unity in Butterworth filter design—this fact allows for simplifications in the remainder of this derivation.

We scale s = j2πf by 1/(2πfc), where fc is the cutoff frequency.

Filter tables often give the poles of filters of varying order when forming higher order filters out of

cascaded first and second-order filters. TI’s filter table gives the values in terms of Q = -1/2a. For a third-

order Butterworth, Q = 1 for the second-order stage. Comparing the transfer functions and using the

given Q produces the following design equations:

Solving these equations requires picking values for the cutoff frequency and two of the components.

Initially, we chose 20kHz for fc because that is the highest frequency in the audible range. We chose R =

R1 = 5.11kΩ because the output impedance of the analog output ports on the audio CODEC/DAC is

about 3kΩ and we want to ensure that we do not draw too much current from the IC. I chose C2 = 1nF

because it is a common capacitor value and it provides acceptable component values for the other two

components.

Simulations with the values calculated in this way were 3dB down at 20kHz, as expected. This, however

is unacceptable for our tight design requirements on the gain of the frequency response between 20Hz

and 20kHz. We need the response to be no more than 1 dB down at 20kHz, so we identified the

8

frequency at which the response is 1dB down; about 16kHz. To compensate, we change the cutoff

frequency to 24kHz in the above design equations while maintaining the two set component values.

Thus we arrive at the following component values, including those from the first-order stage. In

simulation, these successfully produce the frequency response we desire.

Figure 3. Complete filter stage schematic

In the above schematic, notice the single high-pass RC pole near Vout. This filter stage removes

frequencies near DC. This filter stage has a 3dB passband frequency of 9.5Hz. We chose these

component values of 33uF and 501Ω through experimentation in simulation to ensure that the response

is only 1dB down at 20Hz. The 33uF capacitor is known as an AC coupling capacitor. The simulation of

our analog output filter and AC couple is in figure 4.

Figure 4. Filter simulation

9

The filter quality is essential for eliminating noise and producing reliably accurate sound across the

entire audible range. Further considerations in audio fidelity are seen in the layout of the PCB; placing

decoupling capacitors as close to necessary power and ground ports on the CODEC/DAC and OpAmps as

possible.

2.3 LED Peripheral

2.3.1 LED Signal Level and Photosensor

We require circuitry on the signal path between our Raspberry Pi and LEDs. Our LED strip requires 5V

logic on the input serial data line. The Raspberry Pi outputs 3.3V logic. We use a non-inverting line buffer

(MC74HC125) to boost the logical output level of the Raspberry Pi. Further, we place a current-limiting

resistor on the data line at the input to the LEDs.

We tie the photosensor’s output to the output enable of the line buffer. As the output enable is active-

low and the photosensor outputs a logical low in darkness, we enable LED color patterns in dim light.

Figure 5 displays the schematic for this LED control circuit.

Figure 5. LED circuit schematic

2.4 Software Components There are three major components to the Jukebox’s software.

iOS Guest and Owner Apps

Control Server

Raspberry Pi Server

We chose this architecture since it is highly scalable and reliable. It allowed us to implement a jukebox

that only used the owner’s Spotify premium account. We detect the iBeacon and generate sessions

based on the connected iBeacon. As long as the user stays in range, the person is authenticated to buy

or play a song.

10

Figure 6. Software components

2.4.1 iOS Guest App

The login page (displayed in Appendix F) shows the UUID major and minor values and the RSSI. We

picked this design to aid testing and show the capabilities of how proximity detection could be done. We

use the uuidgen tool to pick the UUID. After selecting the jukebox, the user arrives at the Spotify search

page.

The search page (displayed in Appendix F) accesses the Spotify API to search for songs. It has a preview

button to get 30 second previews of songs. The objective of the UI design was to make components

easily accessible. The Queue button helped access the player queue to see songs currently in the player

queue.

The player queue shows the order of songs put into the Jukebox. This information is currently stored on

the control server database under the Jukebox identifier. The design of the UI was very similar to that of

the search screen. The owner app is a simple app that sends authentication to the local RPi server for

Spotify.

2.4.2 Main/Control Server

The main purpose of the global server was to process payments centrally and easily.It also flattens JSON

coming from the Spotify server. This server could be extremely useful in the future for scalability since it

could store the major/minor ibeacon identifier metadata and help extend the jukebox from one box to

several thousand quickly. Hence, we made the server with the intent of making the device future-proof

and also make the user experience faster on the phone by preventing it the need for excess json

processing on the phone. The only interaction it has with the local RPi is to get the local endpoint so that

users can send music requests. The block diagram for server-smartphone communication is in figure 7.

11

Figure 7. Smartphone interactions

2.4.3 Local RPi Server

This component streams music via pyspotify and uses node.js to receive requests and setup the iBeacon.

To communicate with the python library via node an RPC library. Zerorpc helped expose the modules

and functions as endpoints which makes it easy to call the library to authenticate the owner and let

users send music. The local node server on the rpi also does the bluetooth setup for the ibeacon via a

library called bleno which makes the bluetooth chip function as a peripheral or ibeacon based on its use.

The block diagram for this is as follows.

Figure 8. Local RPi server

PySpotify was used with PortAudio. PortAudio is a layer written above ALSA which gives access to the

low level control of audio. Modifications were made to the internal pyspotify library to make sure the

audio output was at 48KHz and it was sending the output via the i2s port.

2.5 Power

2.5.1 Power Distribution

Our jukebox requires 5 V DC power at up to four amps. Figure 9 provides a schematic of our power

distribution. We choose to power our jukebox from a traditional wall outlet since the device does not

need to move around and battery power would demand unnecessary servicing. We had the choice of

putting the AC/DC converter inside or outside of our package. We chose to use an external converter

(the same style that laptops use) so as to keep our box small and avoid excessively heating the other

12

components in the package. Ultimately, we use a 5 V, 10 A power supply to ensure some room for error

even though we could have likely used a 5 V, 4 A supply.

The AC/DC converter plugs into a 2.1 mm DC jack on the side of the jukebox. Internally, we route the 5 V

power to two separate systems in parallel--the LED and control systems. The positive line to the LED

system has a 3 A fuse to avoid damage to components. The positive line to the control system has a 1 A

fuse.

The LED system consists of the LED strip, the photosensor, and the LED signal buffer circuit. All

components require 5 V VCC. The 56-LED strip requires up to 3.3 A; however, our software never runs

the LEDs at full load (white light on all LEDs) so we never draw more than about 2.8 A. The photosensor

and line buffer IC draw less than .1A each, so this system never draws no more than 3 A under normal

operating conditions.

The control system consists of the Raspberry Pi and audio board. The audio board houses the CODEC

and analog filters. The audio board receives its power from the 3.3 V and 5 V pins on the Raspberry Pi, as

requires less than .1 A total. The power supply connects to the Raspberry Pi’s micro-USB port. We cut a

micro-USB power cable and attached its VCC and ground leads to our power supply; then we plugged

the connector into the Pi’s micro-USB port. The Pi draws around .7 A during normal operation and the

audio board draws less than .1 A, so this system draws no more than 1 A under normal operating

conditions.

We carefully chose our wire sizes based on max current draw. Wires carrying up to 3 A are 16 AWG,

those carrying up to 1A are 18 AWG, and those carrying .1 A or less are 22 AWG. These wire sizes keep

all connections within safe operating temperatures.

Figure 9. Power schematic

2.5.2 Power Supply Quality (Decoupling)

Capacitive decoupling is a common method for optimizing the operation of sensitive devices. Many

devices’ operating characteristics vary with the value of VCC; thus power supply ripple and noise have a

direct effect on the operation of many devices. In order to ensure optimal sound quality, we minimize

power supply ripple and noise through the use of decoupling capacitors.

13

Decoupling capacitors are capacitors placed between VCC and ground that minimize these negative

effects. These capacitors shunt the high-frequency ripples and noise while passing the DC component of

the power. We place decoupling capacitors at every VCC port on our board. The exact values of

decoupling capacitors are not terribly important, but parallel 1 µF and .1 µF capacitors perform well in

our circuits. Design guides for our LED strip ask for a 1mF decoupling capacitor. The larger capacitance

ensures a lower cutoff frequency; thus filtering lower-frequency deviations (above DC) in the voltage

across the LED strip’s terminals. We believe that this helps minimize voltage deviations caused by non-

ideal switching behavior when changing LED colors.

We designed our PCB to minimize trace-length between the decoupling capacitors and any given VCC

pin on an IC. Longer traces pick up more RF noise, so placing the capacitors within a few millimeters of

the VCC pin on any given IC provides the cleanest power.

14

3. Design Verification

3.1 Overall Success Our jukebox successfully performs all necessary functions as a unified system. System-level testing

began with plugging the box into a wall outlet and the lab’s XLR audio cables. Next, we ran the

initialization commands that prepare the software and servers. This enables audio playback begins LED

visualization. Placing your hand over the exposed photoresistor successfully causes the LEDs to stop

blinking until you remove your hand.

To test the playback flow, we then logged into the owner iOS app on an iPhone with our Spotify

Premium account. This enables the jukebox to take requests from guest users, so we then open the

guest iOS app. We demonstrate the proximity detection of the jukebox by walking away from the box

with the guest app open--once we reach about 40 feet, the guest app can no longer see the jukebox as

available. We return to the jukebox with the iPhone and select it in the app. From the search screen that

appears, we type in “Hey Jude” and the Beatles’ song appears. Clicking preview plays a 30 second

snippet of the song. Finally, we click purchase and “Hey Jude” begins to play over the lab’s speakers.

3.2 Shortcomings and Unmet Requirements We achieved near-perfect operation; however, we had some shortcomings in audio quality and LED

display consistency.

When listening to the analog audio output of our system on high-quality speakers, we hear rich and

accurate tones, but we hear small skips while streaming. This suggests two things--first, our audio board

supports the high-fidelity we expect; second, Spotify streaming competes with serial I2S writing for the

Pi’s processing cycles.

More specifically, we believe the skips occur because writing the serial audio data takes place on the

same thread as reading the Spotify stream. If a packet comes in from the audio stream and the

processor gives the reading of it higher priority than writing I2S data at a necessary time, we lose the I2S

data that the Pi would have sent to the CODEC. It is important to note that these skips are not occurring

at regular time intervals. This evidence is consistent with our hypothesis since the I2S word clock allows

for 32 bits of serial data per channel; whereas we only send 16 bits of data per channel. Thus, incoming

packets can only audibly interfere with the I2S sent to the CODEC on half of the total bits sent.

In order to solve this problem, we would have to implement multi-threading on our Pi. The I2S writing

must have its own thread in order to send unimpeded data.

Revisiting our audio board, we demonstrate that it supports high-fidelity audio; However, modular

testing found that the frequency response of our analog filters do not meet all the requirements we

placed on it. For accurate representation of sound across the entire audible spectrum, we required a

maximum 1 dB gain deviation within the range of 20 Hz to 20 kHz. While simulation on our filters passed

this requirement, bench testing did not, and the reason for the discrepancy is likely non-ideal op amps

and passive component value tolerances.

15

To test our filters, we input a sinusoid of frequencies swept from 1 Hz to 30 kHz over a ten second

interval. We record the output on an oscilloscope and average the frequency response of ten such

sweeps in MATLAB. Figure 10 shows the response over this full sweep. The outlying values near DC

compelled us to get another sweep at low frequency--frequencies below 70 Hz, as seen in figure 11.

These figures confirm validation of our requirements on attenuation outside the audible range.

Figure 10. Full sweep frequency response

Figure 11. Low-frequency response

The full-sweep plot suggests that our passband attenuates by more than 1 dB between 17 kHz and 20

kHz. Figure 12 shows a zoomed-in view of the frequency response in this range. Here we see that our

16

filter response attenuates by 1 dB around 18.5 kHz. We failed to achieve 1 dB pass-band flatness up to

20 kHz, but as we alluded to previously, the result was inaudible in demonstration.

Figure 12. High-frequency response

17

4. Costs Our total costs were $16,408 including parts ($208) and labor ($16,200).

4.1 Parts Table 2. Parts costs

Part # Source Description Qnt. Unit cost

Total cost

1138 Adafruit RGB 60-LED strip 1 25 24.95

2385 Adafruit Raspberry Pi 2 - Model B - ARMv7 with 1G RAM

1 41.6 41.57

Spotify Spotify Premium Account 3 10 30

603-BLED112 Mouser BLED112 Bluetooth Dongle 1 10.9 10.9

EW-7811Un Edimax USB Wi-Fi Adapter 1 9.99 9.99

777-CS4272-CZZ Mouser CODECs Stereo Audio CODEC 114 dB 192 kHz

1 9.1 9.1

SDC4/8GBET Kingston 16 GB Micro SDHC 1 9.94 9.94

658 Adafruit 5V 10A Power supply 1 25 25

Amazon micro USB cable pack (3 count) 1 6.99 6.99

Amazon Micro USB cable with switch 1 5.98 5.98

Amazon 40P M-F Dupont Cable pack 1 4.8 4.8

1208 Adafruit SMT Breakout PCB for SOIC-28 or TSSOP-28 - 3 Pack

1 4.95 4.95

568-NC3MBH Mouser Male XLR connector 4 2.53 10.12

ECE Supply

24.576MHz crystal oscillator 1 0 0

OPA1664AIDR TI Dual Low-power low-noise audio op amp

2 2.75 5.5

667-ERJ-6ENF5111V Mouser 5.11 kOhm 0805 SMD 1% 24 0.03 0.696

71-CRCW0805-1.5K-E3 Mouser 1.5 kOhm 0805 SMD .1% 15 0.05 0.735

667-ERJ-6ENF5100V Mouser 510 Ohm 0805 SMD 1% 15 0.03 0.435

81-GCM2165C1H132JA6D

Mouser 1300 pF 0805 SMD 5% 15 0.08 1.14

77-VJ0805Y562KXBPBC

Mouser 5600 pF 0805 SMD 10% 15 0.1 1.5

581-08055C102J Mouser 1000 pF 0805 SMD 5% 12 0.1 1.2

74-293D336X96R3A2TE3

Mouser 33 uF 1206 SMD 10% 15 0.22 3.3

667-ERJ-6GEYJ473V Mouser 47 kOhm 0805 SMD 5% 15 0.02 0.27

520-245.7-20-3XENT Mouser 24.576 MHz 20pF 50ppm XTAL 6 0.6 3.6

581-06031A400KAT2A Mouser 40 pF 0603 SMD 10% C0G 9 0.23 2.07

77-VJ0805Y105KXQTBC

Mouser 1 uF 0805 SMD 10% 30 0.05 1.5

18

74-293D476X96R3A2TE3

Mouser 47 uF 1206 SMD 10% 6 0.18 1.08

843-0805J0500104KJT Mouser .1 uF 0805 SMD 10% 33 0.06 1.98

588-AS08J1002ET Mouser 10 kOhm 0805 SMD 5% 6 0.06 0.36

863-MMBT2907ALT1G Mouser PNP BJT SMD 6 0.1 0.6

863-MMBT3904LT1G Mouser NPN BJT SMD 10 0.09 0.89

588-AS08J1002ET Mouser 10 kOhm 0805 SMD 5% 15 0.05 0.72

667-ERJ-6GEYJ202V Mouser 2 kOhm 0805 SMD 5% 10 0.02 0.2

667-ERJ-6GEYJ561V Mouser 560 Ohm 0805 SMD 5% 1/8W 10 0.02 0.2

Total 208.8

4.2 Labor Table 3. Labor costs

Name Hourly Rate Hours / week Num. weeks Total Hours Total Pay

Sam Sagan 30 15 12 180 5,400

Nikhil Sancheti 30 15 12 180 5,400

James Lang 30 15 12 180 5,400

Machine Shop n/a n/a n/a 5 n/a

Electronics Shop n/a n/a n/a 2 n/a

Total 16,200

19

5. Conclusion In conclusion, we successfully created a modern jukebox. We built a high-end audio board and an

elegant user-interface around a Raspberry Pi with proximity detection. The iOS apps are fully-featured

and make an excellent platform for future add-ons. The LED enclosure adds a nice visual touch.

While we were successful during the scope of this course, there are some uncertainties for our jukebox’s

future. The use of the Spotify API is an uncertainty. The terms and conditions of this service could

change very easily which make it hard to provide the service reliably. Further, the API for web

applications such as ours is deprecated.

5.1 Ethical considerations There is a concern with respect to payments. Once the service receives payments, there is a concern as

to who could get portions of the money. It might seem unfair for content from artists to not receive

portions of the payment. A possible spin off would be to provide other services which are paid or go for

an ad based model.

5.2 Future work Better threading in pyspotify would have improved audio quality. There was a blocking operation in

PortAudio which could be improved to prevent audio jitters. Buffer underflows also were an issue.

Research into this issue came up with limited results and Raspberry Pi’s seem to run into this issue

frequently. Changing PortAudio configurations could alleviate this issue.

Scaling this device from a single to multiple devices is a challenge that remains in this project. Doing that

could help convert this from a project to a business. Scalability challenges include mainly include

software and hardware challenges.

The current device is not very far from being a plug and play device. Adding a few boot scripts could

make this happen. Additional functionality to add more value to the device could be to control the LED

lights from the owner app and app statistics on the owner app.

5.3 Market Analysis Our target markets are music venues, bars and the audiophile community. Appendix I shows a

comparison of competitors in these markets. Based on this comparison, our device fits in perfectly

between the ultra expensive devices and the chromecast. The market opportunity for this device is ripe

since it seems complex to buy several of these devices. The way we see this device is a 199$ device

along with app services based on the iBeacon. Advertisements could also be a possible route for extra

revenue. The Spotify integration gives users a better sense for song availability. This device also has a

similar feel to products that Kickstarter promotes. This could potentially be a very successful

Kickstarter/Indiegogo campaign. This would also give insights into how users want to use this product.

20

References 1. 24-bit, 192kHz Stereo Audio CODEC, datasheet, Cirrus Logic, 2005. Available at:

http://www.cirrus.com/en/pubs/proDatasheet/CS4272_F1.pdf

2. Audio Operational Amplifiers, datasheet, Texas Instrument, 2011. Available at:

http://www.ti.com/lit/ds/symlink/opa1664.pdf

3. Quad 3-State Noninverting Buffers, datasheet, ON Semiconductor, 2013. Available at:

http://www.mouser.com/ds/2/308/mc74hc125a-d-302550.pdf

4. AES standard method for digital audio engineering--Measurement of digital audio equipment,

web page. Available at: https://www.ak.tu-berlin.de/fileadmin/a0135/Unterrichtsmaterial/KT-

Labor_WS0809/1_ADDA/aes17.pdf. Accessed Oct 2015.

5. Teensy Super Audio Board, web page. Available at: https://hackaday.io/project/5912-teensy-

super-audio-board. Accessed Dec 2015.

6. Active Low-Pass Filter Design, web page. Available at:

http://www.ti.com/lit/an/sloa049b/sloa049b.pdf. Accessed Nov 2015.

7. pyspotify, web page. Available at: https://pyspotify.mopidy.com/en/latest/. Accessed Dec 2015.

8. Trifork iBeacon Demo Lunch Talk, web page. Available at:

http://www.slideshare.net/ChristianMelchior/trifork-ibeacon-demo-lunch-talk. Accessed Nov

2015.

9. zerorpc, web page. Available at: http://www.zerorpc.io/. Accessed Dec 2015.

10. iBeacon for Developers, web page. Available at: https://developer.apple.com/ibeacon/.

Accessed Nov 2015.

11. Adafruit NeoPixel Uberguide, web page. Available at: https://learn.adafruit.com/adafruit-

neopixel-uberguide/overview. Accessed Nov 2015.

12. Braintree, web page. Available at: https://www.braintreepayments.com/. Accessed Oct 2015.

13. Firebase, web page. Available at: https://www.firebase.com/. Accessed Oct 2015.

14. Chromecast Audio, web page. Available at: https://www.google.com/chromecast/speakers/.

Accessed Dec 2015.

15. Rockbot, web page. Available at: https://rockbot.com/. Accessed Dec 2015.

16. Virtual Jukebox, web page. Available at: https://www.vjukebox.com/. Accessed Dec 2015.

17. TouchTunes, web page. Available at: http://touchtunes.com/. Accessed Dec 2015.

18. CONNECT, web page. Available at: http://www.sonos.com/shop/connect?r=1. Accessed Oct

2015.

19. Whollender’s SuperAudioBoard Linux Kernel Source, repository. Available at:

https://github.com/whollender/linux. Accessed Nov 2015.

20. BCM 2835 ARM Peripherals, datasheet. Available at: https://www.raspberrypi.org/wp-

content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf. Accessed Sept 2015.

21. Raspberry Pi Device Tree Documentation, webpage. Available at:

https://www.raspberrypi.org/documentation/configuration/device-tree.md. Accessed Oct 2015.

22. I2S topic on Raspberry Pi Forum, webpage. Available at:

https://www.raspberrypi.org/forums/viewtopic.php?t=8496. Accessed Oct 2015.

21

Appendix A Requirement and Verification Table Table 4. Requirements and Verification

Control Module

Raspberry Pi 2

1. The Raspberry Pi outputs 5V ± 0.25V and 3.3V ± .2V on respective power output pins.

2. Raspberry Pi can connect to the internet.

3. GPIO pin 21 outputs serial digital audio data at the clock frequency inputted on GPIO pin 18.

4. Sets CODEC in master mode with I2S digital audio format using I2C output clock and data during initialization.

5. Sets CODEC to run by driving the active-low reset CODEC pin 14 on GPIO pin 26 high during initialization.

6. Sets LED strip colors according to software.

1. Connect a voltmeter across pins 2 (+) and 6 (-); output should be 5V ± .25V. Connect a voltmeter across pins 1 (+) and 6 (-); output should be 3.3V ± .2V.

2. $ ping google.com should show packets being received. Ctrl-C to return.

3. Use oscilloscope with digital decoding to insure that valid I2S data is sent from GPIO pin 40, given the word and bit clocks on CODEC pins 4 and 5 respectively.

4. Use oscilloscope to insure that the CODEC outputs a 48kHz word-clock on CODEC pin 4 and a 3.072MHz bit-clock on CODEC pin 5.

5. Use oscilloscope to insure that the CODEC pin 14 is low before initialization and high (3.3V ± .2V) afterward.

6. Run LED test program and observe a rainbow of colors rotating through the strip.

YES

CODEC and DAC

1. Outputs 48kHz word-clock on CODEC pin 4 and 3.072MHz bit-clock on CODEC pin 5 after initialization.

2. Outputs analog audio signals with 2.5V DC offset and no more than 2.5V amplitude.

3. The Raspberry Pi reads the CODEC as an audio device.

4. The mute circuitry grounds the analog output to under 50mV whenever the mute signal is low.

1. Use oscilloscope to measure clock frequencies on CODEC pins 4 and 5.

2. Use oscilloscope to measure the output on CODEC pins 24, 25, 26, and 27.

3. Command ‘$ aplay -l’ in the terminal lists ‘superaudioboard’ as a valid device.

4. For each channel, while the mute signal is low, read the output of the channel.

YES

Power Module

22

Power Supply

1. Power supply draws power from 120V, 60Hz wall socket and converts it to 5V ± .25V DC.

2. Must provide up to 4A at 5V.

1. Use a multimeter to probe the voltage on Raspberry Pi pin 2 relative to the voltage on Raspberry Pi pin 6.

2. We do not have a definitive and safe way to test this; however, we use a supply that is rated for up to 10A to allow significant room for error.

YES

Filter Module

Filter

1. Gain varies no more than .99dB from the magnitude at 1kHz within the frequency range 20Hz to 20kHz.

2. Attenuation at 30kHz must be at least 6dB down (½ of fundamental volume)

3. Attenuation at DC must be at least 12dB down (¼ of fundamental volume)

1. Input a frequency swept sinusoidal with 2.5Vpp and 2.5V offset from 1Hz to 30kHz over 10 seconds. Record 10 sweeps worth of filter output data on an oscilloscope. Perform FFT on on each of the 10 sweeps and average the 10 frequency responses.

2. Same as 1 3. Same as 1

NO

User Interface Module

Audio Out Ports

1. Analog signals on the leads are reproduced on pins of male XLR connector.

1. Apply a test voltage ramp waveform to the input pins individually and read the output with an oscilloscope.

YES

LEDs

1. Visible colors correspond to the software-defined color

2. MC74HC125 line buffer outputs 5V logic when given 3.3V logic and output is enabled.

3. Line buffer outputs logical lows when the output is disabled.

1. Run the LED test program and observe rainbow of colors rotating through strip

2. Tie the active-low output enable to ground and input a square wave that oscillates between 0 and 3.3V from a function generator on pin 2 of the buffer. Probe the output on pin 3 with an oscilloscope.

3. Tie the active-low output enable to 5V and input a square wave that oscillates between 0 and 3.3V from a function generator on pin 2 of the buffer. Probe the output on pin 3 with an oscilloscope.

YES

23

Sensors

Photosensor

1. In full light, output voltage must be at least 3.5V

2. In dim to no light, output voltage must be no more than 1.5V

1. Use multimeter to read output signal voltage from photosensor with photoresistor exposed to full light.

2. Use multimeter to read output signal voltage from photosensor with photoresistor shaded or covered

YES

Software

Owner App

1. Upon login with valid Spotify premium account, user gains access to Spotify’s library through the App

1. After inputting valid credentials, check terminal for “Spotify logged in” message

YES

Server

1. Sends username and password to spotify server and sends results back

2. Streams the current song

1. After inputting valid credentials, check terminal for “Spotify logged in” message

2. Select a song on phone and play audio through speakers

YES

Guest App

1. Detects iBeacon, and thus uniquely identified jukebox by UUID

2. Allows user to select jukebox by UUID

3. Deauthenticates when out of range

4. Visualizes player queue on demand

1. After initialization, the UUID and RSSI values are displayed in app

2. Clicking on UUID sends user to song search screen 3. While logged in and in range, walk away until the app

logs out of song search screen 4. Clicking the ‘Queue’ button sends user to queue

visualization screen

YES

iBeacon

1. Transmits UUID over BLE

1. Open app and confirm that RSSI values displayed decrease as you move the phone away from the jukebox until deauthenticating at around 40ft

YES

24

Appendix B – Audio Board Schematic Here we have the overall audio board schematic followed by a zoomed in image of the CODEC portion

and the filter portion separately. This allows for an understanding of the top-level connections in

addition to component-level details.

Figure 13. Full audio board schematic

25

Figure 14. CODEC schematic

26

Figure 15. Filter schematic

27

Appendix C - Raspberry Pi Connections Table 5. Raspberry Pi Connections

Name # Function Connection

SCLK 12 I2S Bit Clock CODEC pin 5

LRCK 35 I2S Frame Clock CODEC pin 4

SDATA 40 I2S Serial Audio Data Output CODEC pin 7

SCL 5 I2C Clock CODEC pin 11

SDA 3 I2C Data CODEC pin 12

RST 37 CODEC Reset CODEC pin 14

LED_DATA 32 PWM LED Control LED Module DIN

28

Appendix D - Filter Test Code This matlab code breaks a single CSV oscilloscope output file into 10 individual frequency sweeps and

averages the frequency response of each. The code does this for a sweep from 1 Hz to 30 kHz and a

sweep from 1 Hz to 70 Hz. There is a main function called filter_analysis that calls spectral_analysis

defined below.

filter_analysis.m

spectral_analysis.m

29

Appendix E - Raspberry Pi Configuration Connecting to the Internet

A USB Wi-Fi adapter plugs into our Raspberry Pi. On boot, the kernel brings up network interfaces

specified in the configuration file located at /etc/network/interfaces. In order to set up a Wi-Fi interface

(wlan0), we must add an entry for it in the file displayed in the following figure.

We supply network information, including ssid, password and network settings, in the file located at

/etc/wpa_supplicant/wpa_supplicant.conf to complete the setup of our network connection.

Device Tree

On boot, the loader passes a description of the system hardware in a Device Tree Blob (DTB) to the

kernel. The hardware embedded on the Raspberry Pi is supplied in a default, compiled blob, forming

the root of the device tree. In order to provide information about our external hardware, we must

provide a Device Tree Overlay to the loader after the root has been formed. In the configuration file

located at /boot/config.txt, we can specify additional overlays to be supplied. The loader will search for

the listed overlays in the /boot/overlays/ directory, so we should make sure our compiled DTB is located

there as well.

Additionally, we must enable I2S and I2C hardware interfaces in the boot configuration file. The I2S and

I2C modules are disabled by default in order to leave their respective GPIO pins free unless they are

needed. The kernel is already aware of these hardware interfaces since they are included in the root

DTB. Therefore, we don’t need another new device tree overlay, but we still must enable the

corresponding device tree parameters.

30

31

Appendix F – iOS Screenshots

Figure 16. Entry screen

Figure 17. Search Screen

32

Figure 18. Queue screen

33

Appendix H – iBeacon The iBeacon helps identify the class of iBeacons(eg Walmart vs Jukeboxes). The Major and Minor values

shown in the show which Jukebox is picked(eg Murphys vs Legends). The core features provided by the

iBeacon is as follows.

Proximity based detection RSSI

UUIDs to detect class of iBeacons

Major and Minor identifiers to detect Jukebox

34

Appendix I – Market Analysis Competitive analysis

Chromecast Audio

Wifi based music streaming

Integration with the home wifi

Small, Low Power device

Supports RCA, 3.5mm and Optical outputs

Player Queue functionality does not exist.

Sold as an add on to speakers

35$ in price

Rockbot

Music for Businesses

iBeacon functionality

Targets enterprise integrations

Limited information about the audio devices itself

Cannot be bought off the shelf

Limited information on pricing

TouchTunes

Music + Karaoke + Photo Booths for Venues

Expensive (web forums vary on pricing)

Big Screen

Plenty of artists

Cannot be bought off the shelf

Virtual Jukebox

Cannot be bought off the shelf

Unclear Objective of the box

Hardware powered by external vendor

Audio out does not seem like high quality

Limited information on the hardware and software integrations + artists