Drone BLE Scanning for Search and Rescue: Commercial Hardware, DIY Raspberry Pi Builds, and Real-World Tradeoffs
Yes, this works — and someone already shipped a commercial version
The concept is validated. A drone flying a systematic grid while logging Bluetooth Low Energy advertising packets and their received signal strength can meaningfully narrow a search area — especially in rough terrain where ground teams are slow or can’t safely operate. The bigger surprise for anyone researching this right now is that there is already a commercial product built around exactly this idea: Parsons Corporation, through their QRC subsidiary, launched a drone-mounted payload called BlueFly in mid-2025. Knowing that changes the decision tree for any agency considering this capability.
That said, understanding how aerial BLE detection actually works matters whether you go commercial or DIY, because the physics are the same either way.
How aerial BLE detection works
Every Bluetooth Low Energy device broadcasts short advertising packets at regular intervals. Smartphones, smartwatches, AirTags, fitness trackers, glucose monitors — they all do it, even when locked or sleeping. These packets announce the device’s presence without requiring pairing. A scanner just listens passively, collects device identifiers, and logs an RSSI value (Received Signal Strength Indicator) with each packet.
From the air, you are not triangulating in a single pass. You are building a heat map. As the drone covers a grid, it collects RSSI readings from the same device at many different GPS positions. The cluster of readings with the highest signal strength points toward the device on the ground. Tighter grid spacing and more passes make that cluster smaller and more precise.
Standard BLE has a practical open-air range of around 10 to 50 meters. Bluetooth 5.0 introduced a long-range mode called Coded PHY that can push detection distances well beyond 1 km — but support is inconsistent across consumer devices. Many older smartphones don’t advertise on Coded PHY. The important operational note: when a phone dies, other devices on the victim often keep broadcasting for days. AirTags, smartwatches, and wireless earbuds advertise continuously and some use Coded PHY by default.
The commercial option: Parsons BlueFly
BlueFly is a self-contained payload that runs independently of the host drone’s power and communications systems. It detects classic Bluetooth, BLE, and Wi-Fi signals from up to 200 meters line of sight, then streams detections to TAK-enabled Android devices in real time as a heat map overlay. Because it is drone-agnostic, it can mount on almost any commercial or government UAS platform without custom integration work.
Detectable device classes include smartphones, smartwatches, fitness trackers, Apple AirTags, wireless earbuds, hearing aids, glucose monitors, and other BLE or Wi-Fi emitting devices. The TAK integration is a significant operational advantage — it fits directly into existing public safety workflows without additional software infrastructure.
One detail from QRC’s team worth keeping in mind: a dead phone is not the end of the detection window. As a phone loses power, nearby devices that were paired to it start broadcasting more aggressively while searching for a connection. BlueFly is designed to catch those secondary signals. No pricing is listed publicly; contacting QRC directly is the right first step for agency procurement.
The DIY path: Raspberry Pi and Python
If budget constraints or procurement timelines push you toward building your own, the core is genuinely approachable. A Raspberry Pi Zero 2 W — weighing about 13 grams — running Python with the bleak library can scan for nearby BLE devices, collect device addresses, names, and RSSI values, and timestamp each reading with GPS coordinates from an attached USB GPS dongle. The bleak library is cross-platform, actively maintained, and runs cleanly on Raspberry Pi OS.
A minimal scanning loop looks like this:
import asyncio
from bleak import BleakScanner
async def scan():
devices = await BleakScanner.discover(timeout=5.0)
for d in devices:
print(d.address, d.name, d.rssi)
asyncio.run(scan())In practice you add GPS logging, write to a timestamped CSV, and then post-process that file against your drone’s flight log to produce a signal map. The drone mission itself can be planned as a standard grid survey in any common ground control software.
For hardware, a Pi Zero 2 W plus a small USB BLE adapter (if the drone’s chassis blocks the onboard radio), a USB GPS module, a compact LiPo battery pack, and a lightweight enclosure typically comes in under 100 grams — manageable for most mid-size drones. The older bluepy library is an alternative on Linux, though bleak has broader active development and better Python 3 support.
Antenna selection
Standard BLE antennas are omnidirectional. For a grid survey, that is actually what you want: you catch signals from all directions beneath the drone as you fly, which is ideal for RSSI heat-mapping. A directional patch antenna narrows the beam, which increases gain in one axis but shrinks your coverage width per pass — you end up needing tighter row spacing to cover the same area.
In most survey scenarios, a high-gain omnidirectional antenna oriented vertically gives better area coverage per flight minute than a patch. The patch becomes more useful in a second phase: once you have a rough area from the initial grid, hovering with a directional antenna and slowly rotating can help you confirm the bearing to a device from a fixed position. Two such bearings from different positions give you a fix.
Altitude and range — where most DIY builds run into trouble
This tradeoff catches people off guard. Flying higher covers more ground per pass, but standard BLE from a consumer smartphone is rated for 10 to 50 meters open-air. At 30 meters AGL, a DIY scanner with reasonable sensitivity will catch most active BLE devices below it. At 80 meters, you will miss a large fraction of standard-power BLE advertisements unless the device supports Coded PHY or you are using a high-sensitivity external radio.
The practical sweet spot for DIY hardware is roughly 20 to 40 meters AGL for reliable detection of common BLE devices. To avoid coverage gaps at that altitude, plan grid passes with row spacing of around 30 to 40 meters. That means more passes over a given search area than a visual survey — so budget battery capacity accordingly and keep grid cells manageable per flight.
What devices are detectable
- Smartphones running iOS or Android with Bluetooth enabled — both platforms broadcast BLE advertising packets even when the phone is locked
- Apple AirTags — advertise continuously by design
- Tile, Chipolo, and other Bluetooth key finders
- Smartwatches and fitness trackers
- Wireless earbuds (AirPods, Galaxy Buds, and similar)
- Medical devices including some glucose monitors, hearing aids, and insulin pumps
Wi-Fi probe requests — broadcast by smartphones even when not connected to a network — are also detectable, but they require separate hardware: a Wi-Fi adapter running in monitor mode rather than a BLE radio. BlueFly handles both signals from a single payload. A DIY Pi build can add this capability with a compatible USB Wi-Fi adapter and airodump-ng or a custom packet capture script, though adding Wi-Fi scanning also adds weight and power draw.
Limitations to plan around
BLE RSSI is noisy. The same device scanned twice from the same position can return readings more than 10 dBm apart. Dense vegetation absorbs and scatters the signal. Water reflects it unpredictably. RF noise from the drone’s own electronics can interfere if the antenna placement is not carefully thought out. None of this makes the approach useless — but it means your location estimate from a grid pass will be approximate. Useful for narrowing a large search area down to a few hundred meters. Not useful for pinpointing a location from the air alone.
Privacy regulations may also be a factor. BLE advertising packets contain device MAC addresses, which some jurisdictions treat as personally identifiable information. Before operational deployment, your agency’s legal counsel should review how the collected data is stored, retained, and used.
And the hard limit: BLE detection only works when the target has a powered, broadcasting device on their person. No electronics means nothing to detect.
Regulatory considerations
US law enforcement agencies have access to the FAA’s Public Safety Toolkit, which includes Certificate of Authorization pathways and Part 107 waiver processes for public safety UAS operations. The FAA’s forthcoming Part 108 rule, expected to take shape in 2026, will replace the COA framework with a Certificate of Waiver model specifically designed for drone-as-first-responder operations. Requirements are moving, so verifying the current pathway with your agency’s aviation coordinator before any field deployment is worth doing early rather than late.
Sources