Project

# Title Team Members TA Documents Sponsor
11 Wireless Speaker Sharing System (WSSS)
 Bernard Lyu
Haimo Chen
Michael Chen
 AJ Schroeder design_document1.pdf
final_paper1.pdf
other1.pdf
presentation1.pdf
proposal1.pdf
Members: Michael Chen (yuxuanc5) (Section ONL), Hammer Chen (haimoc2) (Section H), Bingheng Lyu (blyu3) (Section H)

# Problem
Have you ever been to a party where it's deafening standing beside the speaker but not loud enough further from the speaker? Did you think purchasing a large and decent speaker for occasional parties is too expensive? Have you ever stared at a pile of small personal speakers, wondering how can I easily sync them up for a song? We propose the WSSS (Wireless Speaker Sharing System), allowing you to gather the power of your small speakers and host a great party.

# Solution Overview
We want to create a standalone offline wireless audio sharing system that interfaces with the standard 3.5mm audio jack. There will be one broadcasting dongle and multiple receivers. Users can plug the broadcaster to any of their music players (phones, computers, or even game consoles), and plug in the receivers to an arbitrary amount of playback devices in proximity without pairing or registration. All audio signals will be in sync, so users can enjoy this immersive experience.

# Solution Components

## Power subsystem
This subsystem will provide power to the whole system. It will consist of a lithium-ion battery, a battery charging circuit, a DC-DC voltage regulation circuit, and a USB port used for charging.

## Signal processing subsystem
On the transmitter side, this subsystem amplifies the analog signals from the audio jack, converts it to a digital signal suitable to be sent over the nRF24 module. On the receiver side, the system recovers the original sound signal from the digital signal received. The process is similar if we choose to use LoRa modules for wireless communication.
If we choose to use FM for transmission instead, this subsystem will be generating appropriate FM waves from audio signals on the transmitter side and recovering the audio signal on the receiver side.

## Wireless transmission subsystem
We are planning to use the nRF24 module to transmit and receive signals between dongles. Other options include FM and LoRa. We will choose the best performing transmission system.

## I/O subsystem
5mm audio jack interface, L/R channel switch, and a USB port for microcontroller programming & charging.

## Optional software subsystem
A mobile app to control the transmission rate and some other control signals. (Frequency tuning if FM signals is used for wireless transmissions)

# Criterion for Success
1. The power subsystem should consistently power the whole system.
2. The signal processing subsystem should properly convert and amplify the audio signals.
3. The wireless transmission subsystem should transmit the signals with certain fidelity within a proper range (10m).
4. Users should be able to successfully play music through our WSSS with a few speakers. The audio signals from different speakers should be in sync, with indiscernible latencies among them.
5. Both the transmitter and the receiver should be plug-and-play devices.

# Difference with existing products
1. **Chromecast audio** requires online registration and WiFi connection. Thus it can't be used in the wild. Our proposed solution is an entirely standalone audio sharing system.
2. **Qualcomm broadcast audio/Apple Airpods audio share** requires expensive new devices and needs Bluetooth pairing with individual speakers. (The constant pairing/unpairing process can be a headache for party hoppers)
3. Products like **Anker Soundsync A3352 Bluetooth Receiver** have device count limits and still require Bluetooth pairing.
4. Prior Projects like **Project 6 from Spring 2020: Bluetooth audio splitter** is different from ours in following ways:
1. We would connect to the playing and playback devices using the 3.5mm audio jack and is a plug-and-play device while the Bluetooth audio splitter uses Bluetooth that requires Bluetooth pairing setup.
2. The project from last semester can only play on two devices while our proposed device can broadcast to multiple receivers, presumably much greater than 2.
3. We are planning on using RF or FM signals to broadcast the audio signal. Such wireless transmission medium is not present in the design of Bluetooth audio splitter.


# Call for suggestions
We are thinking about using RF(nRF24) or FM signals to broadcast the audio. Any comments/suggestions are welcomed.

# Contingency plan
We already have plenty of lab equipment available including the soldering iron, multimeter, etc. If the course transfers fully online, we are planning to continue working on the project, purchasing necessary tools as needed. They might not be as fine as the ones in the lab but should do the job.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.