RE3 | Devpost

RE3(Our App Logo)
On IOS view
Alerts being sent out are seen
Details of alerts

📡 No Signal. No Problem.

🌍 About the Project In emergencies, communication is the first thing we lose — and the thing we need most. Natural disasters, power outages, infrastructure failures, or even large public gatherings can overload or shut down internet and cellular networks. Yet during these moments, timely alerts can save lives. This project was inspired by a simple question:

What if alerts didn’t depend on the internet at all?

Instead of relying on centralized infrastructure, we built a decentralized Bluetooth Low Energy (BLE) mesh-style alert system where devices relay alerts to nearby devices — spreading messages like a chain reaction.

Think of it as epidemic propagation, but for safety signals. Here comes RE3, a decentralized alert system that uses Bluetooth to spread emergency messages device-to-device — no internet required.

⚙️ How It Works The Raspberry Pi (which we call "Relay"): Send out the alerts to all nearby Android and iOS devices

Each Device that has the app RE3(which we call "Echo") acts as both:

A receiver (listens for nearby alerts) A relay node (rebroadcasts unseen alerts) A sender (authorized device can initiate alerts.

So essentially, alerts are hopped from one device to another using BLE tech. No Internet needed!!!

We modeled it similarly to a disease spreading from one host to nearby people. However, in our case, the alerts could save thousands of lives.

This is not a full epidemiological model, but it captures the core idea: alerts spread through proximity, not servers.

🛠️ How We Built It

We started with Android-first for the MVP due to the BLE background limitations on iOS. Then we scale it up to IOS.

🛠️Tech Stack Flutter (Dart) – App framework & UI Streamlit - For simplified UI Andriod-Studio - For Android app development Bluetooth Low Energy (BLE) for device-to-device communication Unique message IDs to prevent rebroadcast loops

Each device: Scans for BLE advertisements. Parses incoming alert packets. Checks if the alert ID is already stored. Rebroadcasts only if unseen. This prevents infinite loops while preserving decentralized propagation.

🧠 What We Learned

BLE Is Powerful — But Constrained BLE has strict payload size limits (~31 bytes for advertisements). We had to compress alerts into minimal packets containing: Alert ID Timestamp Priority flag Designing within hardware constraints forced us to think efficiently.
iOS Has Background Restrictions We learned that iOS severely limits BLE scanning in the background unless specific service UUIDs are used. For a 24-hour hackathon MVP, Android was the pragmatic choice.
Decentralization Changes Architecture Without a central server: There is no global state. Devices must maintain local memory of seen alerts. Conflict resolution must happen peer-to-peer. This required careful state management and duplicate filtering.
Power & Latency Tradeoffs Continuous BLE scanning increases battery usage. We experimented with balancing: Scan interval Broadcast frequency Alert urgency There is a direct tradeoff: Lower Latency ⇒ Higher Power Consumption

Optimizing this was one of our biggest engineering considerations.

🚧 Challenges We Faced 🔹 Background Execution Limits

Keeping BLE active when the app is not in the foreground required working around Android’s and IOS's background service policies.

🔹 Loop Prevention

If every device rebroadcasts blindly, alerts could loop infinitely. We solved this using unique identifiers and local cache filtering.

🔹 Time Constraints

Building decentralized communication logic in under 24 hours forced us to prioritize: Core relay logic Stability Minimal UI We intentionally deferred advanced encryption and multi-hop optimization for future iterations.

🔹 Effective Range The range was a huge problem, but our latest demo could send out alerts up to 1 heafy hall length, from one entrance to the other.

🌱 Future Improvements

-iOS compatibility using constrained BLE service UUID strategies -Lightweight encryption for message authenticity -TTL (Time-To-Live) propagation limits -Hardware node integration (Raspberry Pi or LoRa gateway bridge) -Adaptive scan intervals based on alert severity

💡 Why This Matters In disaster zones, protests, remote areas, or infrastructure collapse, centralized communication fails. This project explores a different model: Communication powered by proximity. Safety powered by people.

Not cloud-dependent. Not infrastructure-bound. Just devices — helping devices.