Inspiration
Picture a storm hitting campus at night. The power cuts out, the cell towers go down, and the Wi-Fi disappears. Within minutes, every phone is a glowing rectangle that can't reach anyone.
Now picture what's happening inside the dark buildings. A student is stuck in an elevator. Another needs a fridge to keep their insulin cold. Someone else has fallen on a stairwell and can't get up. Each of them is holding a phone that says No Service.
That scenario is what we couldn't stop thinking about. The people who need help most are often the ones who can't ask for it, because the tools we rely on all depend on the same fragile infrastructure. We wanted to build something that works exactly when everything else stops. So we built Tether.
What it does
Tether helps people request assistance when a building loses its internet or cellular connection. A person nearby opens a lightweight webpage on their phone—no app download or account needed—chooses what kind of help they need, and adds a short description and room if they know it. The page measures its connection to the nearby help point to provide responders with a rough distance estimate; it does not depend on GPS or promise exact indoor positioning.
The request travels from the phone to a laptop acting as the local help point, then across a LoRa radio link to a second laptop. There, it appears on a live responder dashboard alongside its category, message, priority, and available location context. Responders can scan incoming requests, use the floor plan as a guide, and focus on the requests that need attention first. An SOS request is made especially visible and can trigger an audible and spoken alert.
Tether is designed to make the exchange two-way. From the dashboard, a responder can acknowledge a request, say they are on the way, or resolve it, optionally including a short note. Those updates travel back over LoRa. The person who sent the request sees a live status page with a pulsing heart and a simple progress line—Sent, Heard, On the way—so they have a clearer sense of what is happening instead of being left to guess whether anyone received their message.
The system keeps its core communication local: the pages and data run on the laptops, requests are stored locally, and LoRa carries messages between help points. It is not a replacement for emergency services or a guarantee that every radio message will get through; it is a practical fallback intended to help people and responders stay coordinated when ordinary networks are unavailable.
How we built it
We built Tether around two laptops, browser-based pages, Python and Flask, SQLite, and Wio-E5 LoRa radios. One laptop serves the request form and sends messages over the radio; the other receives and stores them, then presents them on a live dashboard. The pages use lightweight, local assets so the experience doesn’t depend on external websites or services.
We kept the request format short and practical, and added a return path for responder updates. The dashboard groups requests by priority and provides a map view to help responders make sense of the situation. On the sender side, a person can follow the request’s progress and see a short note from the responder.
Challenges we ran into
Everything had to work without the internet. That sounds simple until you realize how much we normally lean on the cloud: online maps, location APIs, hosted services. None of it was an option, so we kept things local, small, and focused on what actually matters in an emergency.
LoRa only lets you say a little. We couldn’t send long descriptions or fancy location data, so we had to decide what a responder truly needs to know. That’s why we ended up with clear categories, a short note, and a cleaned-up message format.
We didn’t want to just send a message into the void. If you’re scared and waiting, “did anyone get that?” is the worst feeling. So we worked on status updates going both ways, so the sender can see whether their request was sent, heard, or being acted on, and the phone page still makes sense while they wait.
Accomplishments that we're proud of
We’re proud that Tether brings together the pieces of an emergency request that are often treated separately: asking for help, getting that request to responders without relying on the internet, and letting the sender know what happens next. The result is a working end-to-end flow—from a phone browser, through a local help point and LoRa radio link, to a responder dashboard and back again.
We built the sender experience so it doesn’t require an app, account, or cellular data. A person can submit a short request and then follow its status through clear updates: sent, heard, and on the way. That feedback may seem small, but in an uncertain situation, knowing that someone received the request can matter.
We’re also proud of the two-way radio workflow. Responders can acknowledge, send an “On my way” update with a note, or resolve a request, while the dashboard keeps incoming requests organized by priority and provides location context through a floor plan. For SOS requests, the dashboard can make the alert harder to miss with sound and voice.
Most of all, we're particularly pleased that we kept the project centered on a real constraint: communication can fail during an outage, so essential coordination should not depend entirely on the systems that may be down. Tether is a prototype, and it still needs more real-world radio and location testing, but it gave us a tangible foundation to learn from and improve.
What we learned
We learned that “offline” is not a single switch. A phone may still reach a nearby laptop over local Wi‑Fi even when the internet is unavailable, while the laptops use LoRa to carry requests between help points. Building around that distinction helped us separate the local web experience from the longer-range radio link and avoid making the cloud part of the critical path.
We learned to treat message delivery as a sequence of states, not a yes-or-no event. Submitting a form only tells us the phone sent something to the local server; it does not prove that the radio transmitted it or that a responder saw it. That is why the project distinguishes sending, sent, heard, and on-the-way, and why the responder acknowledgement matters as much as the original request.
We also learned that radio limits influence the whole product. LoRa can carry messages over a useful distance with little infrastructure, but messages must stay short and radio conditions can be unpredictable indoors. That shaped the request format, the short responder notes, and our approach to retrying and displaying status rather than assuming every transmission succeeds immediately.
Working on location taught us to be careful about precision. Indoor positioning is difficult, and a floor plan or estimated distance is context—not proof of someone’s exact location. We learned that asking for a room when someone knows it, while offering a nearby help-point reference, is more honest and useful than suggesting the system can locate a person precisely.
Finally, we learned that an emergency interface should reduce uncertainty without promising more than the system can deliver. Clear labels, short choices, and visible updates help both senders and responders understand what has happened and what remains unknown. Our next step is to validate these lessons with more testing in real buildings and with the people who may rely on the system.
What's next for Tether
Next, we want to take Tether beyond a two-laptop prototype and test it across a larger area. One idea is to add LoRa relay nodes in strategic locations so a request can travel around obstacles or reach a help point farther away. We’d test different placements and message paths to learn where coverage drops and how the system should behave when a relay is unavailable.
We’d also like to put QR codes at entrances, stairwells, and designated help points. Scanning one could open the local request page and show a useful starting location such as the building, floor, or nearest help desk without asking the person to explain where they are from memory. We would need to make sure the QR flow still works when the phone is connected only to the local network.
Another direction is safe check-ins. People could let responders know that they are safe, or check in at a designated location, helping responders distinguish those who still need assistance from those who have already found help. We’d design this carefully so check-ins don’t create false reassurance or expose more personal information than necessary.
Before expanding the feature set, we want to test the radios in real buildings, measure how reliably messages and acknowledgements travel, and improve indoor location cues. The goal is to make Tether more dependable through practical testing—not simply add features, but learn what people and responders actually need when normal communication is down.
