The GPS Mirage: Why Satellite Signals Die Indoors and What Really Locates People

I once spent three days troubleshooting a "rogue beacon" in a 200,000 sqft hospital. The system was reporting a critical patient transport vehicle was stuck in a utility closet. Turns out, it wasn't the beacon. It was the fact that the GPS signal, the one we implicitly trust for outdoor navigation, was about as useful as a paper umbrella in a hurricane.

Why this matters in 2026

Indoor positioning isn't a luxury anymore. For large venues like hospitals, airports, and massive retail spaces, precise location data is core to operational efficiency, safety, and customer experience. Think about emergency response in a sprawling medical center, directing lost travelers in a busy terminal, or even just finding an available fitting room in a department store. Relying on GPS indoors is a fool's errand, a fundamental misunderstanding of radio physics that leads to wasted time and money.

Three things I learned shipping this in production

The False Gods of GPS and Wi-Fi Triangulation

We've all been trained to think of GPS as the gold standard. But satellite signals are weak, easily attenuated by concrete and steel. A signal strength of -100 dBm is already pretty bad outdoors. Indoors, you're lucky to get -120 dBm, and that's before accounting for multipath interference. I saw a system in a mid-sized airport terminal that tried to use Wi-Fi triangulation for its primary indoor location. It was a disaster. Users would get "located" in the middle of a runway, or worse, in a secure baggage handling area. The RSSI (Received Signal Strength Indicator) values fluctuated wildly due to people walking by, doors opening, and even the microwave oven in the break room. We spent months tuning it, trying to filter out noise, and the best we could achieve was a 15-meter accuracy, which is frankly useless for wayfinding or asset tracking. The constant re-calibration and the sheer number of access points required to get even that level of accuracy meant significant infrastructure costs that never paid off. We eventually ripped it out and replaced it with something that actually worked.

Bluetooth Beacons: Ubiquitous, Cheap, and Fragile

Bluetooth Low Energy (BLE) beacons are the workhorses for many indoor positioning systems. Vendors like Estimote and Kontakt.io offer them, and they're relatively inexpensive to deploy. You can get a decent pack of 50 for under $1000. The concept is simple: beacons broadcast a unique identifier (UUID, Major, Minor) at a set interval. A mobile device, or a dedicated gateway, picks these up. By measuring the RSSI from multiple beacons, you can estimate your position. This is called trilateration.

Here's the catch: RSSI is notoriously unreliable. It's affected by orientation, battery level, and the infamous "handheld effect" where holding your phone can block signals. I remember deploying a system in a 40-floor commercial tower. We had hundreds of beacons. For the first week, it seemed to work okay. Then, during a busy Monday morning, the system started reporting wildly inaccurate locations for employees. People were showing up as being on the wrong floor, or even in stairwells. We discovered that the sheer density of people in the building, all with their phones broadcasting and receiving, was creating a fog of BLE signals. The RSSI values were all over the place. The average accuracy dropped from 3 meters to over 10 meters. We had to implement a probabilistic filtering layer that looked at signal strength over time and across multiple devices to smooth out the readings, but it was a constant battle.

Here's a simplified Python snippet showing how you might process beacon data, though this doesn't include the complex filtering needed for production:

def estimate_position(beacons):
    # beacons is a list of dictionaries: [{'id': 'beacon_1', 'rssi': -70}, ...]
    # This is a highly simplified example and doesn't account for beacon positions
    # or complex filtering.
    if not beacons:
        return None, "No beacons detected"
    total_rssi = sum(b['rssi'] for b in beacons)
    avg_rssi = total_rssi / len(beacons)
    # A very crude mapping from RSSI to distance (highly inaccurate in reality)
    # This assumes a reference RSSI at 1 meter and a path loss exponent.
    # For example, if RSSI at 1 meter is -60 dBm, and path loss is 2.
    # distance = 10^((reference_rssi - rssi) / (10 * path_loss_exponent))
    # This is a gross oversimplification.
    try:
        # Let's assume a reference RSSI of -60dBm at 1 meter and path loss of 2.
        reference_rssi = -60
        path_loss_exponent = 2
        estimated_distance_meters = 10*((reference_rssi - avg_rssi) / (10  path_loss_exponent))
        return estimated_distance_meters, "Estimated distance based on average RSSI"
    except Exception as e:
        return None, f"Error estimating distance: {e}"
Example usage:
detected_beacons = [{'id': 'beacon_A', 'rssi': -75}, {'id': 'beacon_B', 'rssi': -80}]
distance, message = estimate_position(detected_beacons)
print(f"Estimated distance: {distance} meters. Message: {message}")

Ultra-Wideband (UWB): The Precision Dream, The Deployment Nightmare

When you absolutely need sub-meter accuracy, UWB is the answer. Technologies like Apple's U1 chip and dedicated UWB anchors enable Time-of-Flight (ToF) measurements, which are far more accurate than RSSI. I worked on a project in a large manufacturing facility where tracking tools and high-value assets was critical. We deployed a UWB system. The accuracy was phenomenal – consistently under 30cm. This allowed us to pinpoint a specific workbench where a tool was left, saving hours of searching.

However, UWB has its challenges. The infrastructure is more expensive. You need dedicated UWB anchors, which can cost several hundred dollars each, and they need to be networked and precisely surveyed. For a 500,000 sqft warehouse, that's a significant capital expenditure. Furthermore, UWB signals have a shorter range than BLE, meaning you need more anchors for coverage. We also ran into interference issues with other high-frequency radio devices on site. The setup and calibration process is also far more involved. It's not plug-and-play. You're talking about significant installation costs and specialized knowledge to get it running optimally.

What I would do differently if I started today

I'd bypass the "best of both worlds" trap of trying to combine BLE and Wi-Fi for a single system. Instead, I'd embrace a hybrid approach that uses different technologies for different purposes. For general location awareness and asset tracking where 2-5 meter accuracy is sufficient, BLE with intelligent filtering and perhaps some strategic placement of UWB "hot zones" for critical areas would be my go-to. For applications demanding sub-meter precision, like robotic navigation or intricate tool tracking, I'd go straight to UWB, but I'd plan the anchor deployment with military precision, understanding the signal propagation characteristics intimately. I'd also look at sensor fusion more aggressively, combining IMU data from devices with location fixes to smooth out trajectories and predict movement between fixes, especially when signal quality degrades.

What this looks like for your team

1. Audit your current location needs: What exactly do you need to locate, and with what precision? Is it people, assets, or vehicles? Do you need 10-meter accuracy for general zone presence, or sub-meter for specific process control? Don't over-engineer. 2. Experiment with BLE beacons in a small area: Buy a few beacons from a vendor like Estimote or Kontakt.io, and use their SDKs on a couple of test phones. See how accurately you can track devices in a controlled environment. Understand the limitations firsthand before committing to a large deployment. 3. Investigate UWB for critical zones: If sub-meter accuracy is non-negotiable, start researching UWB anchor placement strategies and potential vendors. Look at reference designs and understand the installation complexity and cost implications for your specific venue size.

I write about engineering decisions and production systems at devwithzach.com — drop me a line if any of this rings true.