A decentralized communication network for travelers during connectivity outages
VuelingConnect is a Flutter application that enables users to share critical information during network outages using Bluetooth Low Energy (BLE) technology. The app creates an ad-hoc mesh network between devices, allowing information to propagate without requiring internet connectivity.
- Decentralized Communication: Share events without internet connectivity, with other devices acting as relays for messages.
- Battery Efficient: Uses BLE broadcasting instead of connections to minimize power consumption
- Prioritized Updates: Critical information propagates first based on timestamp and hop count
- Gamification: Rewards users for contributing to the network
- User-Friendly Interface: Simple design for ease of use during stressful situations
- Arduino Scanner: Arduino BLE scanner for seeing active devices and signal stregth
- Notifications: Custom notification system with priority handling
The inspiration for VuelingConnect came from the Vueling prompt at HackUPC2025. After the recent blackout in Spain, which highlighted the vulnerability of communication systems during power outages, we wanted to create a solution that would allow travelers to stay informed about their flights even when traditional communication channels are unavailable.
BLE devices either advertise (as peripherals) or scan/connect (as centrals).
Peripherals broadcast short ADV_* packets on 3 channels (37, 38, 39).
Optionally, a scanner may reply with SCAN_REQ, triggering a SCAN_RSP response (another 31-byte payload). This can be useful for showing more info without connecting.
If a central wants to connect, it sends a CONNECT_REQ. Both devices then switch to a private data channel set and begin exchanging data using the BLE protocol stack.
BLE 5 adds extended advertising with bigger packets (~255 bytes) and new channels, but not all devices support it yet.
In our case messages are embedded into the ManufacturerSpecificData and broadcasted as part of the advertising step:
The id is used to recognice devices in that are part of our network. Data is kept under 26 bytes as to preserve compatibility with as many devices as possible, though newer devices can usually use up to 250.
At the moment this is not using SCAN_RSP as to reduce the number of packets sent and maximize compatibility, so there is no confirmation if any other device has received one of your broadcasted packets. Because of that it's important to have careful queue managment to avoid redundancies in the network and ensure important messages are always relayed.
Binary Format:
[1 byte] msg_type:
- FlightStatus (0)
- Alert (1)
[1 byte] hopCount: Number of times this message has been relayed
If msgType == FlightStatus:
[8 bytes] flightNumber: ASCII encoded, padded with zeros
[1 byte] status:
- Scheduled (0)
- Departed (1)
- Arrived (2)
- Delayed (3)
- Cancelled (4)
[4 bytes] eta: Estimated Time of Arrival in epoch seconds, big-endian (0 if not available)
[3 bytes] destination: IATA airport code, ASCII encoded, padded with zeros
[4 bytes] timestamp: Epoch seconds, big-endian
If msgType == Alert:
[1 byte] alertType:
- Evacuation (0)
- Fire (1)
- Medical (2)
- Aliens (3)
[4 bytes] timestamp: Epoch seconds, big-endian
- Msg Type: Alerts have priority over flight updates.
- Timestamp (Newest First): Ensures the most recent information propagates first
- Hop Count (Lowest First): Prioritizes messages that haven't traveled as far
- Rotation: Round-robin scheduling for all eligible messages
flowchart TD
%% Main components
subgraph Mobile["Mobile App (Flutter)"]
direction TB
App[Main App]
subgraph Services["BLE Services"]
direction LR
Central[BLE Central Service]
Peripheral[BLE Peripheral Service]
MessageStore[Message Store]
end
subgraph UI["User Interface"]
direction LR
FlightView[Flight Status View]
AlertView[Alert Messages View]
BluetoothSettings[Bluetooth Settings]
end
Decoder[BLE Message Decoder]
%% Internal mobile app connections
App --> Central
App --> Peripheral
App --> MessageStore
App --> UI
Central --> Decoder
Peripheral --> Decoder
MessageStore --> Peripheral
end
subgraph Arduino["Arduino Scanner"]
Scanner[BLE Scanner]
SerialOut[Serial Output]
Scanner --> SerialOut
end
subgraph Server["Backend Server"]
direction TB
FastAPI[FastAPI Server]
FlightAPI[Flight Status API]
AlertAPI[Alert Messages API]
FastAPI --> FlightAPI
FastAPI --> AlertAPI
end
%% External connections
Central <-.-> Scanner
OtherDevices[Other Mobile Devices]
Central <-.-> OtherDevices
Peripheral <-.-> OtherDevices
App <--> FastAPI
- Flutter 3.0+
- Dart 2.17+
- Android Studio / VS Code
- Android device with BLE support or iOS device
-
Clone the repository
git clone https://github.com/yourusername/vuelingconnect.git
-
Navigate to the project directory
cd vuelingconnect -
Install dependencies
flutter pub get
-
Run the app
flutter run
|
|
|
|
|
|
|
|
|
This project is licensed under the MIT License - see the LICENSE file for details.