PhanTom Signal

What We Built and Who It's For

The emergency buttons located around campus may seem like thorough protection for people on campus, but they have major practical flaws. Once pressed, they send you directly to the University of Illinois Police Department, activate flashing lights, force users to communicate through a speaker, and send only the button’s location to the dispatcher. When users are at risk of imminent threats, it isn’t ideal for them to make a scene. By the time the button’s location is sent, the user may have already left the scene to keep their distance from the threat. If perpetrators have noticed that they’ve been identified, they may accelerate the situation and act on their plan faster. These emergency buttons try to help in the most unsubtle way by bringing unwanted attention. Even if the user is suffering from a serious physical injury and requires help, the likelihood that they are right next to an emergency button is low.

Alternatives are lacking as well. Phoning 911 requires clear communication and may be difficult for individuals who cannot speak good English, have a speech disability, or are unable to speak at all. Campus blue-light boxes and 911 calls also assume that the user can communicate verbally, while blue-light boxes assume that the user can remain at a stationary location. IlliniAlert sends useful tips to the community, but does not allow individuals to report personal cases. UIUC students, faculty, staff, and community members need a reliable and accessible way to contact UIPD without a scene.

We built PhanTom Signal, an improved emergency button on your phone, in your pocket. Upon opening the app, the user immediately sees a red button on the screen that they can hold down in an emergency while still being discreet. It creates a “walk,” which shares the real-time location of the user with the Division of Public Safety. The user will then be able to send status updates, like “I think someone is following me” or “I need help immediately.” The dispatcher can also send responses to reassure the user, acknowledging that they’ve seen the request and that help is on the way. The dispatcher will be able to see the user’s location in real time as long as the walk is active.

If the user doesn’t immediately want to contact authorities, they can start a walk and create a shared link to send to trusted guardians of their choosing, also with a feature to call for help. This makes PhanTom Signal useful for anyone’s security, but it’s particularly catered to those with difficulties communicating, whether it’s because they’re deaf, mute, in a difficult situation, or aren’t comfortable with English. Instead of relying entirely on a phone call or verbal communication during an emergency, users can communicate through written status updates while still allowing the dispatcher to understand what is happening and where they are.

How we built it

We started by breaking our project, PhanTom Signal, into three connected parts: the student interface, the guardian interface, and the Campus Safety dashboard. We used AI coding tools to help us turn those ideas into working code, then tested and iterated on the generated code as a team.

The interface was built with React and TypeScript, and we used Leaflet with OpenStreetMap for the live maps. We built a backend using Node.js and Express, which acts as the connection between the three interfaces, and SQLite stores active sessions, incidents, and location information. We also used the browser's location system for GPS and Web Push for notifications. GitHub helped us manage and share the code.

One of the first problems we ran into was working with the same version of the project. Our newest prototype was originally on a separate Git branch, so when another team member cloned the repository, it looked like a lot of the project was missing. We figured out that Git branches can contain different versions of the same project, switched to the correct branch, installed the dependencies, and then ran both parts of the application together.

A much bigger challenge was getting a live location to work across actual phones instead of only on our laptops. At first, we assumed a phone could simply open the address running on the laptop, but a phone's localhost refers to itself, not the laptop. We also learned that browsers generally require a secure HTTPS connection before allowing location access. To deal with this, we supported HTTPS for real-device testing and also created a clearly labeled simulated walk. That gave us a reliable way to demonstrate the entire system even when GPS or browser permissions were unreliable.

We then ran into another issue: The live location isn't always truly live. GPS and network delays can make a location appear more recent than it actually is, especially when the app is running in the background. To make the system more reliable, we tracked how fresh each location update was and warned users when the data became stale, while also limiting unnecessary uploads.

Overall, AI helped us build much faster, but our main role was turning the generated code into a system that actually worked reliably across the student, guardian, and dispatcher sides.

Future implementation

To implement this project into a real application that can be used on campus, we’d like to partner with the Division of Public Safety to decide how it can be integrated into already existing security systems, who receives alerts, and how staff respond to alerts in real time.

Furthermore, we’d like to implement a university login system so the dispatchers can identify who needs help and repeated patterns of safety concerns. In addition, once the dispatcher sends out staff to meet the user, the user should be able to see the staff’s location in real time and an estimated time of arrival. Finally, we’d like to deploy our project to a mobile app that anyone could download. This would allow location sharing to continue even when the phone is locked, and notifications when updates are received.