## Inspiration

* Smart homes are taking over the industry
* Current solutions are WAY too expensive(almost $30) for one simple lightbulb
* Can fail from time to time
* Complicated to connect

## What it does

* It simplifies the whole idea of a smart home
* Three part system
	+ App(to control the hub device)
	+ Hub(used to listen to the Firebase database and control all of the devices)
	+ Individual Devices(used to do individual tasks such as turn on lights, locks, etc.)
* It allows as many devices as you want to be controlled through one app
* Can be controlled from anywhere in the world
* Cheap in cost
* Based on usage data, provides feedback on how to be more efficient with trained algorithm

## How I built it

* App built with XCode and Swift
* Individual devices made with Arduino's and Node-MCU's
* Arduino's intercommunicate with RF24 Radio modules
* Main Hub device connects to Firebase with wifi

## Challenges I ran into

* Using RF24 radios to talk between Arduinos
* Communicating Firebase with the Hub device
* Getting live updates from Firebase(constant listening)

## Accomplishments that I'm proud of

* Getting a low latency period, almost instant from anywhere in the world
* Dual way communication(Input and Output Devices)
* Communicating multiple non-native devices with Firebase

## What I learned

* How RF24 radios work at the core
* How to connect Firebase to many devices
* How to keep listening for changes from Firebase
* How to inter-communicate between Arduinos and Wifi modules

## What's next for The Smarter Home

* Create more types of devices
* Decrease latency
* Create more appropriate and suitable covers
## Inspiration

The need for faster and more reliable emergency communication in remote areas inspired the creation of FRED (Fire & Rescue Emergency Dispatch). Whether due to natural disasters, accidents in isolated locations, or a lack of cellular network coverage, emergencies in remote areas often result in delayed response times and first-responders rarely getting the full picture of the emergency at hand. We wanted to bridge this gap by leveraging cutting-edge satellite communication technology to create a reliable, individualized, and automated emergency dispatch system. Our goal was to create a tool that could enhance the quality of information transmitted between users and emergency responders, ensuring swift, better informed rescue operations on a case-by-case basis.

## What it does

FRED is an innovative emergency response system designed for remote areas with limited or no cellular coverage. Using satellite capabilities, an agentic system, and a basic chain of thought FRED allows users to call for help from virtually any location. What sets FRED apart is its ability to transmit critical data to emergency responders, including GPS coordinates, detailed captions of the images taken at the site of the emergency, and voice recordings of the situation. Once this information is collected, the system processes it to help responders assess the situation quickly. FRED streamlines emergency communication in situations where every second matters, offering precise, real-time data that can save lives.

## How we built it

FRED is composed of three main components: a mobile application, a transmitter, and a backend data processing system.

```
1.  Mobile Application: The mobile app is designed to be lightweight and user-friendly. It collects critical data from the user, including their GPS location, images of the scene, and voice recordings.
2.  Transmitter: The app sends this data to the transmitter, which consists of a Raspberry Pi integrated with Skylo’s Satellite/Cellular combo board. The Raspberry Pi performs some local data processing, such as image transcription, to optimize the data size before sending it to the backend. This minimizes the amount of data transmitted via satellite, allowing for faster communication.
3.  Backend: The backend receives the data, performs further processing using a multi-agent system, and routes it to the appropriate emergency responders. The backend system is designed to handle multiple inputs and prioritize critical situations, ensuring responders get the information they need without delay.
   4. Frontend: We built a simple front-end to display the dispatch notifications as well as the source of the SOS message on a live-map feed.

```

## Challenges we ran into

One major challenge was managing image data transmission via satellite. Initially, we underestimated the limitations on data size, which led to our satellite server rejecting the images. Since transmitting images was essential to our product, we needed a quick and efficient solution. To overcome this, we implemented a lightweight machine learning model on the Raspberry Pi that transcribes the images into text descriptions. This drastically reduced the data size while still conveying critical visual information to emergency responders. This solution enabled us to meet satellite data constraints and ensure the smooth transmission of essential data.

## Accomplishments that we’re proud of

We are proud of how our team successfully integrated several complex components—mobile application, hardware, and AI powered backend—into a functional product. Seeing the workflow from data collection to emergency dispatch in action was a gratifying moment for all of us. Each part of the project could stand alone, showcasing the rapid pace and scalability of our development process. Most importantly, we are proud to have built a tool that has the potential to save lives in real-world emergency scenarios, fulfilling our goal of using technology to make a positive impact.

## What we learned

Throughout the development of FRED, we gained valuable experience working with the Raspberry Pi and integrating hardware with the power of Large Language Models to build advanced IOT system. We also learned about the importance of optimizing data transmission in systems with hardware and bandwidth constraints, especially in critical applications like emergency services. Moreover, this project highlighted the power of building modular systems that function independently, akin to a microservice architecture. This approach allowed us to test each component separately and ensure that the system as a whole worked seamlessly.

## What’s next for FRED

Looking ahead, we plan to refine the image transmission process and improve the accuracy and efficiency of our data processing. Our immediate goal is to ensure that image data is captioned with more technical details and that transmission is seamless and reliable, overcoming the constraints we faced during development. In the long term, we aim to connect FRED directly to local emergency departments, allowing us to test the system in real-world scenarios. By establishing communication channels between FRED and official emergency dispatch systems, we can ensure that our product delivers its intended value—saving lives in critical situations.
## Inspiration

This project was heavily inspired by CANBus and its unique network arbitration method for devices on the network. However while CANBus requires a specialised circuit to be a part of the network, Monopoly Bus does not, and moreover only requires a single wire.

## What it does

Monopoly Bus allows devices to broadcast messages, commands and data onto a single wire asynchronous network without any specialized peripherals. Thus, it is built for DIYers and hobbyists and will allow them to build large device networks without any extra parts or lots of wiring.

## How we built it

The protocol uses a "virtual clock" which is essentially a timer that the GPIO uses to send or receive a value every time the timer ticks. The clock is activated once the line has been pulled down, synchronizing all nodes. Thus, the clock translates the digital signal into a stream of bits.

## Challenges we ran into

Currently the protocol is only capable of sending 1 byte in a single frame. It is also quite error prone at higher tick rates/frequencies. A major issue initially was syncing devices on the network together itself.

## Accomplishments that we're proud of

Randomness based networks have been built before (in fact the first wireless packet data network utilized randomness for network arbitration) but I am proud to have developed something unique that hobbyists could use for their projects.

## What we learned

Low level signal processing and synchronization
Network Arbitration Mechanisms
Decimal - Binary Conversions and vice versa

## What's next for Monopoly Bus!

I hope to see this project bloom into a popular open source framework. I also plan on porting this to other MCUs.