CrowdCourse

system diagram

Inspiration

Have you even gotten lost or separated from your friends in a dark and crowded room? Whether a house party, concert, night club, or bar, staying close to someone you trust can be essential for both safety and fun when going out in an unfamiliar environment. Yet in all the chaos and dimness, it is easy to lose sight of your people without even realizing. Your friends might not know to check their phones, and you texts and calls will fail to connect. Location sharing services like Find My and Life360 can show broad geographic locations, but within the scope of a building or room, the location is too general to see where a friend really is. Getting separated in a crowd can be scary or even dangerous, if you are alone in a moment of crisis. We created CrowdCourse as a solution to this issue.

What it does

CrowdCourse aims to address this problem by providing a physical, accessible device that allows users to track their friends' relative distance, easily find them in a crowd based off a LED guiding system, and alert their friends immediately in the case of an emergency or urgent need. CrowdCourse is a wearable friend-finding and safety system designed for crowded environments where GPS, cellular service, and simply checking your phone may not be enough. Each user wears an ESP32-based CrowdCourse bracelet, connected to an arm-band device, that communicates directly with their friends' bracelets. Rather than trying to determine an exact GPS location, CrowdCourse measures the strength of the wireless signal between devices and turns it into an intuitive proximity guide that helps users physically navigate back toward one another.

As you move toward the person you are tracking, the bracelet's LED strip changes from blue to red: essentially getting "hotter" as you get closer -- blue to green to yellow to red. A SELECT button allows users to cycle between potential friends with their own bracelet, while an LCD displays information about the person currently being tracked. This means someone searching through a dark or crowded room does not need to continuously stare at a map or phone screen: they can simply move in the direction that makes their bracelet glow "hotter" or more red.

To make proximity measurements more reliable across different environments, CrowdCourse includes a room-specific calibration system. Users first take a "near" measurement while standing together and a "far" measurement while separated. CrowdCourse then smooths incoming RSSI (Received Signal Strength Indicator) measurements and maps them onto a 0–100 closeness score. Because different rooms, obstacles, interference, and RF environments can change received signal strength, this calibration lets the system adapt instead of assuming that a particular dBm value always represents the same distance.

CrowdCourse also distinguishes between changes in signal behavior. A gradual decrease in signal strength can indicate that two users are actually moving apart, while a sudden signal drop despite continued packet reception can indicate temporary obstruction — for example, someone walking between the two users. This helps prevent a momentary RF disturbance from immediately sending someone searching in the wrong direction.

Most importantly, CrowdCourse includes an emergency feature we call Lighthouse. If a user needs immediate help, they can trigger Lighthouse using the physical BEACON button or the connected phone interface. Their friends' bracelets respond with a distinctive LED alert and buzzer and begin directing them toward the person who requested help. CrowdCourse can also generate a tether alert if a friend remains far away or disappears from range for an extended period.

The core friend-finding system is designed to work without the internet, cellular service, an account, or even an installed mobile app. The ESP32 bracelets communicate directly using ESP-NOW, broadcasting lightweight beacon packets approximately ten times per second. Each bracelet also creates its own Wi-Fi network and hosts a local web interface. A phone can simply connect to the bracelet's network to see the live closeness score, calibration controls, tracked friend, and Lighthouse alerts. Even a borrowed phone can access it.

For larger events, we also created an optional CrowdCourse Aid Station. A bracelet can be connected by USB to a laptop or Raspberry Pi, which collects telemetry and powers a dashboard for a friend, organizer, or staff member trying to help. The station can display live signal information, separation events, SOS events, and historical trends — but importantly, the wearable friend-finding system never depends on the aid station to function.

Sponsor integrations

Photon / iMessage: We integrated Photon Spectrum to turn iMessage into another interface for CrowdCourse. A friend or emergency contact can text the CrowdCourse station instead of opening the dashboard. Sending WATCH subscribes the user to alerts such as a friend going out of range, returning to range, or activating Lighthouse, while STOP unsubscribes them. Users can also send natural-language questions such as "Where is Kate?" or "Did she walk away?" and receive a response based on the CrowdCourse data. This makes the system accessible through something users already check constantly — their Messages app — rather than requiring another application.

Tiger Data: CrowdCourse produces a large amount of time-series data: every bracelet can receive roughly ten RSSI measurements per second from each tracked device. We use Tiger Data to store this telemetry as time-series data, along with calibration, lost/found, SOS, acknowledgment, and messaging events. We also create 10-second aggregated signal histories that let the dashboard efficiently visualize how proximity changes over time. SQL analysis helps us pair lost and found events and analyze signal trends before a separation, giving the aid station context about not only whether two people became separated, but how the signal changed leading up to it.

Gemini API: We built Gemini into CrowdCourse as an intelligent interface over this live and historical data. Instead of simply passing raw RSSI values into an LLM, our Gemini agent has tools that query Tiger Data for specific information including closeness history, separation history, signal statistics, and recent events. Gemini can decide which of these tools it needs based on a user's question and then translate the resulting RF telemetry into a short, useful explanation. For example, it can help determine whether someone appears to have walked away, whether a signal drop was likely caused by an obstruction, or whether an SOS is currently active. Gemini responses can be accessed through both the aid-station dashboard and iMessage.

Together, these features create two layers of CrowdCourse: a local, offline safety layer that keeps working in the crowd even when internet connectivity fails, and an optional connected intelligence layer that gives friends, emergency contacts, or event staff more context when help is needed.

How we built it

CrowdCourse combines embedded systems, RF communication, firmware, physical fabrication, web development, time-series data processing, and AI into one system.

Hardware

At the center of each wearable is an ESP32 microcontroller, which gives us both the processing capability and wireless communication needed for the system. We built three physical CrowdCourse devices so that we could test actual device-to-device behavior rather than simulate communication between users.

Our wearable hardware incorporates a 12-LED NeoPixel strip as the primary proximity indicator. The LEDs create the blue-to-red "hotter/colder" interface, allowing users to search for a friend without needing to continuously look at their phone. We also incorporated a 16x2 I2C LCD for status information and a buzzer for tether and emergency alerts.

Two physical controls provide immediate interaction with the system. SELECT cycles through friends to choose who the user wants to locate, while BEACON activates or ends Lighthouse. A long press can temporarily mute a tether alert. We intentionally kept these functions available physically because a safety-oriented wearable should remain useful even when a user's phone is inaccessible.

We soldered the components and LED bands, debugged the ESP32 pin connections, and designed a custom enclosure in CAD. We iterated through multiple enclosure designs and 3D prints before arriving at a form that could house the electronics as a wearable device.

Device-to-device communication

The CrowdCourse bracelets communicate using ESP-NOW, allowing ESP32s to exchange data directly without requiring a conventional Wi-Fi network or internet connection. Each bracelet broadcasts a small beacon packet roughly 10 times per second containing information such as its device ID, sequence information, and Lighthouse status.

On the receiving bracelet, we use the RSSI (Received Signal Strength Indicator) of these packets as our proximity signal. Because raw RSSI fluctuates significantly in real environments, we do not simply display individual measurements. CrowdCourse averages recent samples, rejects stale measurements, and maps the resulting signal against the user's calibrated near and far values.

The resulting value becomes a 0–100 closeness score, which drives the LED behavior, LCD information, and phone interface. We also implemented thresholds and hysteresis so that classifications such as "far," "nearby," and "very close" do not rapidly flicker when the signal sits near a boundary.

This became one of the most interesting parts of the project because CrowdCourse forced us to deal with the physical behavior of RF signals. Wi-Fi and Bluetooth interference, human bodies, antenna orientation, physical barriers, and even covering the ESP32 antenna could noticeably change our readings. We therefore tested and adjusted transmission power, calibration behavior, smoothing, and proximity thresholds rather than assuming ideal wireless propagation.

Local mobile interface

Each ESP32 simultaneously acts as a Wi-Fi access point and local web server. A user connects their phone to a network named for their CrowdCourse device and opens the locally hosted CrowdCourse interface.

The phone and bracelet communicate in real time through WebSockets. The bracelet streams RSSI measurements, tracking status, and SOS information to the browser, while the browser can send calibration values, activate or cancel Lighthouse, and acknowledge another user's SOS.

Because the page itself is served by the ESP32, the core mobile experience requires no internet connection, app download, or external server. We specifically wanted the wearable to remain functional in exactly the environments where normal connectivity may be least reliable.

Calibration and proximity algorithm

A major part of building CrowdCourse was turning noisy RF measurements into something a person could actually use.

During calibration, the devices collect several seconds of measurements while the users are standing close together to determine the near RSSI, followed by measurements while they are separated to determine the far RSSI. We use median measurements during calibration to reduce the influence of individual RF spikes.

During normal operation, CrowdCourse smooths recent measurements before mapping RSSI between these calibrated endpoints. Instead of claiming an unreliable exact distance such as "your friend is 4.2 meters away," we intentionally provide a relative closeness score. For our application, knowing "I'm getting warmer" is more useful and defensible than pretending RSSI provides centimeter-level indoor positioning.

Aid station + Tiger Data

For our optional aid-station architecture, an ESP32 connected to a laptop or Raspberry Pi sends telemetry over USB serial. We wrote a Node.js bridge that parses these events and sends them into Tiger Data.

We store individual RSSI readings as time-series measurements alongside higher-level events such as lost, found, calibration, Lighthouse activation, and Lighthouse acknowledgment. We also use a continuous aggregate to turn the high-frequency measurements into 10-second signal summaries.

From there, our dashboard uses SQL queries and time-series analysis to reconstruct separation events and inspect the behavior leading up to them. For example, a steadily declining signal before a disconnect provides very different context from a strong signal that suddenly disappears.

Gemini API

On top of this data layer, we created a Gemini-powered CrowdCourse navigator.

Rather than asking Gemini to guess what raw sensor data means, we implemented function-calling tools backed by queries to Tiger Data. Gemini can request:

closeness_history — how the pair's proximity changed over time
separations — when users lost and regained contact and how long they were separated
signal_stats — statistics describing the stability and variation of the wireless link
recent_events — SOS, lost/found, calibration, and acknowledgment events

This lets Gemini reason over actual CrowdCourse measurements when answering natural-language questions from the dashboard or iMessage. We also implemented fallback behavior so that if Gemini is unavailable, the underlying CrowdCourse readings can still generate a useful response. AI therefore augments the safety system rather than becoming a single point of failure.

Photon iMessage integration

Using Photon Spectrum, we connected the CrowdCourse station directly to iMessage. The station listens for incoming messages without requiring us to expose a public webhook or tunnel.

Users can subscribe to CrowdCourse alerts by texting WATCH. The station can then proactively send messages when an SOS occurs or when friends move out of and back into range. Other messages are routed into our Gemini/Tiger Data system, effectively allowing someone to query the CrowdCourse network through iMessage.

This creates an especially useful interface for friends, event staff, or emergency contacts who are not physically wearing one of the devices.

Cursor — "Keep it Legendary"

We used Cursor as an AI-assisted development environment throughout the hackathon to move quickly across a codebase spanning embedded C/C++, JavaScript, HTML/CSS, WebSockets, serial communication, databases, APIs, and AI integrations. With only a hackathon-length development window, Cursor helped us iterate and debug across software layers while we focused simultaneously on physical hardware construction, RF testing, soldering, and device verification.

In the spirit of "Keep it Legendary," we used AI not as a substitute for understanding our system, but as a way to dramatically increase the scope of what four first-time hardware hackathon builders could attempt in one weekend. The final project was not just a prototype webpage: we built and tested multiple physical devices, direct wireless communication, a wearable interface, a locally hosted mobile experience, a time-series backend, an AI agent, and an iMessage integration — all working together as one end-to-end system.

Challenges we ran into

We had to iterate a couple times to get our best CAD design for the device case, and we also had to wait on printer access in order to 3d print these cases (which required 3 repeats).
We used an LCD display for this project, but our members had more previous experience with OLED displays and we were originally considering using an OLED. Thus, our original code was incompatible and written with an OLED display in mind, but had to be adapted for an LCD display. This required learning the ports & functions of the LCD display and debugging firmware code.
Similarly, our pins were incorrect and had to be debugged because we were unfamiliar with the pi LCD display to ESP32 interface, which also required learning more about how the ports must connect.
We were unfamiliar with the conventions of the LED bands, so we originally soldered the wires on the wrong side of one of the bands. This flipped the sign of the current, which did not allow current to flow through the LEDs. To fix this, we had to de-solder and re-solder this part.
A major issue was considering things like EMI (electromagnetic interference) and RF signal interfacing. One of the challenges was adjusting the WiFi power of the ESP32 modules as well as verifying and adjusting the RSSI calibration scheme so that the devices could work despite significant interference from other signals like WiFi and Bluetooth, and also distinguish correctly between -dBm levels at near and far distances.
Integrating all of our software components was a challenge because CrowdCourse spans several very different layers: embedded C/C++ firmware on the ESP32s, a locally hosted web interface, WebSockets, a Node.js aid station, Tiger Data, Gemini, and Photon. Each component worked differently on its own, so a major challenge was creating a consistent flow of data from the physical bracelets all the way to the database, AI agent, dashboard, and iMessage interface.
Integrating Tiger Data also made us think carefully about how to handle the amount of data our devices generate. Since each bracelet receives RSSI measurements multiple times per second, simply storing and querying every measurement becomes inefficient very quickly. We learned how to structure time-series data and aggregate high-frequency measurements into more useful windows while still preserving important events such as a device being lost, found, or entering Lighthouse mode.

Accomplishments that we're proud of

For all 4 of our members (Ruby, Kate, Lucia, Svetlana), this was our first ever hardware-based Hackathon project! As ECEs, this was a great way to challenge ourselves and delve deeper into our field of study by building a real project. This was also Lucia and Svetlana's first Hackathon!
Kate and Svetlana soldered for the first time to assemble the CrowdCourse LED bracelet.
The implementation of 3(!) repetitions of our CrowdCourse device, verifying functionality across all three and interfacing with each other. Since it was especially important that these devices be able to communicate, it was definitely an accomplishment that we were able to successfully make multiple and have them work as expected.
The use of the ESP32 and LCD screen, an interface we were unfamiliar with.
The connection of our wearable devices to a mobile site, which allows for more control of the devices, including features like Photon iMessage and Gemini API integration.
The creation and verification of a distance-based RSSI (Received Signal Strength Indicator) calibration technique, which allows for varying room sizes and EMI (electromagnetic interference) to be considered and calibrated for.

What we learned

We learned a lot about building a hardware project on a short timeline! We gained experience with microcontroller units like the ESP32, writing firmware in C/C++, and in particular, recognizing and understanding ports and their meanings on physical hardware -- as well as how to assign ports in firmware code.
We hadn't considered the RF and signal integrity components to the project at first, but this is the core of the project and what introduced a lot of interesting challenges. Interference from other sources like other wireless cellular and bluetooth networks caused disturbances to the connection of the ESP32. Physical barriers also produced interesting results for the signal being sent between the two devices. When someone stood between the devices, the signal still reached as normal -- it simply diverged around the person in the way -- verifying that the device could work with obstacles in its path. However, when you turned around or put a hand directly over the antenna, that's when signal transmission stopped. This actually ended up working well for our project because it helps the user determine what direction to go in easier. However, for a project that seemed so digital at first, with its C/C++ code and microcontroller, we realized that signals/analog/and digital principals are always in conversation!
We learned what it means to really verify functionality of something you build. We realized that testing something is just as, if not more important than building something. With many different features, we had to think carefully about ways to isolate these features and test them individually, to ensure proper functionality.
We learned a lot about designing a system that spans both hardware and software. CrowdCourse started with communication between ESP32s, but eventually grew into a full pipeline from physical RF measurements -> embedded firmware -> a local web interface -> Tiger Data -> Gemini -> Photon/iMessage. Building this taught us that getting individual components working is only part of the problem; designing clean interfaces between them is just as important.

What's next for CrowdCourse

Increasing range, possibly through a higher Wifi power of the microcontroller unit of choice.
Improving wearability - making it so that it is not a bother at all for the user who wears it!
Improving the intuition of the two buttons (BEACON and SELECT), making it more clear which one is which.
We only were able to implement one of the devices with an actual display, although this was because of hardware availability limitations rather than intent. We would like to add these and also build out the functionality of the display to be more involved in the user's experience.
Exploring applications in outdoors, higher distance, daylight settings. Safety is safety no matter where.