AnchorMesh

Turns every smartphone into a rescue Beacon that works without Internet

Comment

Inspiration

Whether it's forest fires or major disasters like earthquakes and hurricanes, response time is critical to saving lives. With smartphones and modern connectivity, the world is more connected than ever, enabling faster alerts and allowing first responders to act quickly.

But what happens when phones have no signal?

That's why we created AnchorMesh: a solution that enables park rangers, firefighters, and field teams to perform their most critical work in areas where LTE coverage is limited, such as canyons, ridgelines, backcountry trails, remote survey sites, and fire zones with damaged or nonexistent infrastructure.

It also empowers people in cities to reach rescue professionals when cell towers are destroyed, like during Hurricane Katrina's devastation of New Orleans. In those moments, most apps become useless icons on a home screen.

AnchorMesh answers a simple but vital question: What if your phone could still get a message out, even without internet access? Not by hoping for Wi-Fi, but by leveraging the one thing disasters can't stop: people moving through the area.

What it does

Anchor Mesh is a disaster response application that enables smartphones to form a Bluetooth mesh network for transmitting emergency signals without any internet connectivity.

When someone is trapped or injured in a disaster zone, they activate an SOS through the app. Their phone begins broadcasting this distress signal via Bluetooth Low Energy. Any nearby phone running AnchorMesh, even if it's locked in someone's pocket, receives and stores this signal. That person continues moving, and their phone keeps rebroadcasting the message. Eventually, someone in the chain reaches an area with connectivity, and the signal automatically uploads to a rescue coordination dashboard.

Users can indicate their status using a simple color-coded system: Red for critical emergencies, Yellow for injured, and Green for lower priority rescue. This allows rescue teams to prioritize responses effectively. The app doesn't drain battery by running constantly. It monitors official disaster APIs in the background, and only activates mesh mode when an earthquake, hurricane, or other major event is detected in the user's area or when internet connectivity is lost for an extended period.

Even if you're not in danger yourself, your phone can serve as a relay node. We designed the system around the idea that simply having the app installed and your phone in your pocket means you're potentially saving lives.

How we built it

We developed Anchor Mesh using Flutter and Dart, enabling cross-platform deployment to both Android and iOS from a single codebase. The architecture breaks down into several interconnected systems:

Bluetooth Low Energy Implementation: We built a sophisticated BLE advertising and scanning system that operates differently depending on platform constraints. The app broadcasts customized data packets containing compressed location coordinates, user IDs, status codes, and timestamps, which are all within the tight byte limits imposed by Bluetooth specifications.

Data Compression Strategy: GPS coordinates typically require 40 bytes as plain text. We compress them to just 8 bytes using integer encoding, which provides sufficient precision for rescue operations (approximately 1 centimeter accuracy). This allows us to fit complete SOS packets within even legacy Bluetooth's 31-byte advertising limit.

Epidemic Routing Protocol: We implemented a store-and-forward system inspired by research in delay-tolerant networking. Each phone maintains a local SQLite database of received signals, rebroadcasts them to nearby devices, and only deletes records after receiving confirmation from the rescue server.

Background Operation: Significant engineering went into keeping the app functional when phones are locked or in pockets. We leverage platform-specific background modes, including WorkManager for Android and Background Fetch with silent push notifications for iOS.

Deduplication and Loop Prevention: To prevent signals from bouncing infinitely through the network, we implemented sequence counters and timestamp-based expiration. Packets older than 24 hours are automatically dropped.

Dashboard: Created a separate dashboard for first responders to receive alerts from users, allowing them to view the incident's location on a map to locate it.

Challenges we ran into

iOS Background Limitations: Apple places strict restrictions on background Bluetooth operation. When an iOS app moves to the background, it can no longer broadcast standard BLE messages. Instead, the UUID gets "hidden" in an overflow area that only other iOS devices specifically scanning for it can detect. We had to architect around this by ensuring Android devices use specialized scan filters to catch these hidden iOS signals.

Cross-Platform Compatibility: Android and iOS handle Bluetooth differently at almost every level: MTU negotiation, background permissions, and power management. Creating a unified experience that actually works across both platforms required constant testing and platform-specific code paths.

Battery Optimization: Modern smartphones aggressively kill background processes to save battery. On Android, we had to guide users through disabling battery optimization for our app. On iOS, we can only detect Low Power Mode and warn users, but we can't programmatically override it.

Preventing Network Flooding: When multiple phones receive an SOS simultaneously and all immediately rebroadcast, radio interference can jam the signal. We implemented random delays before rebroadcasting to stagger transmissions and prevent collisions.

Moving Targets: If a trapped person moves while waiting for rescue, their location updates must propagate through the network, while older, outdated positions must be discarded. Our sequence counter system ensures only the most recent information survives.

Accomplishments that we're proud of

True Offline Functionality: We achieved what most emergency apps fail to deliver: real offline communication. No cell towers, no WiFi, no internet required, just Bluetooth.

Minimal Battery Impact: Through careful power management, the app can run for 24+ hours in efficient mode while still maintaining mesh connectivity. During active rescue operations, we extend battery life through intelligent scan/sleep cycling.

Compressed Protocol Design: Fitting meaningful emergency data into Bluetooth's restrictive packet sizes required careful protocol engineering. We're transmitting complete location data, user identification, status codes, and timestamps in just 20 bytes.

Background Relay Capability: The technical achievement we're most proud of is enabling phones to relay SOS signals even when locked and in pockets. This transforms passive bystanders into active rescue infrastructure.

Smart Activation System: Rather than requiring manual activation, Anchor Mesh monitors disaster APIs and automatically enters emergency mode when threats are detected. This means the network activates precisely when needed.

What we learned

We went in expecting the biggest challenges to be the obvious technical ones, such as achieving a reliable Bluetooth range in tough terrain or preventing the app from draining batteries too quickly. Those turned out to be solvable. What really consumed months of our time was far more frustrating: operating system restrictions designed for excellent reasons (protecting user privacy and battery life) that unintentionally blocked the exact emergency capabilities we needed most. It often felt like the platforms were working against the very scenarios they ought to support.

We also came to love Flutter for its cross-platform development capabilities. It's powerful and elegant in so many ways. But when we needed deeper system access, its abstractions started to feel like barriers, and we had to accept that some platform differences simply can't be smoothed over.

Bluetooth Low Energy is marketed as a simple and efficient protocol; yet, Android and iOS implement it so differently that we essentially built two separate systems under the same codebase. That taught us a hard but valuable lesson about how "standards" don't always translate to consistent real-world behavior.

As we dug deeper, we gained a whole new respect for foundational concepts in distributed systems. Things we'd only encountered in textbooks, like preventing infinite message loops, handling network partitions, and managing eventual consistency, suddenly became vividly real. In a disaster zone, they could mean the difference between a critical message reaching help or vanishing entirely.

The insight that has stayed with us most, though, is the importance of designing for someone's absolute worst moment. If a person is trapped under rubble after an earthquake, they won't have the patience or ability to navigate complicated menus or troubleshoot connections. They need an interface that just works with one tap, one clear action, and zero extra thought. That guiding principle influenced every choice we made and ultimately made us better designers.

What's next for AnchorMesh

Integration with Official Systems: Our goal is to partner with California fire departments, park ranger services, and emergency management agencies to integrate Anchor Mesh into official disaster response protocols. The rescue dashboard we've built is designed to complement existing emergency coordination tools.

Hardware Partnerships: While our current implementation works with any modern smartphone, purpose-built hardware with extended Bluetooth range and longer battery life could serve as permanent mesh nodes in high-risk areas.

Community Carrier Network: We envision a future where millions of phones form a latent emergency network, dormant during normal times, but ready to activate instantly when disaster strikes. Every installation enhances the network's strength and resilience.

Built With

Share this project:

Updates