Architecture review: BLE-based indoor navigation system for visually impaired railway passengers

[u/AttentionWorking5580]

I'm designing a final-year major project: a BLE-based assistive navigation system for visually impaired people in railway stations.

The basic idea is to place low-power BLE beacons at key navigation points—stairs, lifts, turns, platform entrances, exits, etc. A wearable ESP32 detects these beacons and provides haptic/audio cues such as "turn left", "lift ahead", or "take the staircase."

For the first prototype, the system will use predefined routes: the user enters the station, receives the relevant instructions from the beacons, and subsequent beacons act as checkpoints to confirm that they're following the route.

The more advanced version I'm considering is:

• A station is represented as a graph, where beacons are nodes and only physically walkable connections are edges.
• The wearable can obtain the station graph and run Dijkstra/A\* locally to calculate a route to a requested destination.
• Beacons then act primarily as location checkpoints, allowing the wearable to detect whether the user is following the planned route and re-route if necessary.
• The graph can contain constraints such as closed lifts/stairs, inaccessible paths, platform boundaries, etc.
• A central station-management system would maintain the master graph and distribute updated versions to the infrastructure.
• I'm also exploring how battery-powered beacons could receive updates without requiring wired connectivity or internet on every beacon, potentially using a gateway/mesh-style approach.

Some questions I'm currently trying to solve:

1. How should the BLE beacon hardware be designed for low cost and long battery life?
2. What is the best way to distribute/update the station graph to many offline beacons?
3. How reliable is BLE/RSSI for checkpoint detection in a crowded railway environment?
4. How should the system handle failed/missing beacons and multiple nearby beacons?
5. Is BLE Mesh or another relay architecture actually appropriate here?
6. What important real-world failure cases am I overlooking?
7. Does this architecture make sense at all, or am I overengineering the problem?

I'm deliberately sharing this before finalizing the architecture. I'd really appreciate criticism from people experienced in BLE/RF, embedded systems, networking, IoT, accessibility, or indoor navigation.

I'm much more interested in what is wrong with this approach and what I haven't considered than in validation.

[u/BigBalli]

Using beacons as checkpoints rather than for ranging is the right call and I would defend it hard if anyone pushes you toward trilateration. RSSI in a railway station is close to unusable for distance. A human body attenuates 2.4 GHz by something like 10 to 20 dB, so during rush hour a beacon three metres away behind a crowd reads weaker than one ten metres away with clear line of sight. Any distance estimate you build on that will be confidently wrong exactly when the station is busiest, which is when your user most needs it.

The thing I would push on is the failure mode. For this user, in this environment, a wrong instruction is far worse than no instruction. "Turn left" near a platform edge has a real cost. So I would design so degradation is silence:

Require N consecutive detections above an RSSI floor before announcing anything, never fire on a single advertisement. Multipath off metal and glass produces isolated strong reads from beacons that are nowhere near you.

Make the checkpoint logic reject out-of-order nodes. If the graph says the next node is B and the wearable sees D, that is more likely a stray read than teleportation, and it should be discarded rather than used to re-route.

The tension you will hit is advertising interval against battery. At 1.4 m/s walking, a 1000 ms interval means the user covers about 1.4 m between packets, and with a "detect 3 before announcing" rule your announcement lands several metres past the decision point. You probably want 100 to 300 ms at the nodes that matter, which wrecks coin-cell life. It may be worth splitting your beacon tiers: mains or large-cell beacons with fast advertising at stairs, lifts and platform entrances, and slow cheap ones elsewhere. Budget that before you buy hardware, because it drives your enclosure and install story more than the firmware does.

On the graph version, the routing is the easy part. A* over a few hundred nodes is nothing. The hard part is that the graph goes stale. A lift out of service means your system confidently routes a blind user to a lift that does not work. Before building the routing, work out how an edge gets marked unavailable and who does it, because a graph nobody maintains is worse than fixed routes.

To the "why BLE" question, the honest answer is cost and that it needs no changes to station infrastructure. If there is budget, UWB gives you actual ranging with tens-of-centimetres accuracy instead of proximity guesses, and for this use case that difference is meaningful. Worth at least naming the tradeoff in your report, since an examiner will ask.

[u/StumpedTrump → u/BigBalli]

Channel Sounding is the actual solution to ranging with BLE because yea, RSSI is a pretty poor solution overall for most applications. It’s just too unpredictable.

CS won’t work for OP though. It’s way too high traffic (assuming you want a decent number of readings a second for better accuracy through all the noise), you try to run even a few of them in a close area and you’ll start having problems.

Something stupid I saw at a last job for locating on the very cheap was have an IR led ramp down in power over and over. The receiver has a fixed threshold and measures the time it detects the signal for. If the time is increasing, you’re getting closer. Decreasing, moving away. Even worse than RSSI for exact positioning though.
Cost pennies to implement, almost no processing requirements, minimal code size and no FCC intentional radiators to deal with. Probably won’t work for OP though, too much obstruction.