From BLE clocks to indoor navigation
Our new PToB-IPS research explores turning inexpensive BLE clocks into a local navigation reference for robots and drones, using shared time and hardware they may already have.
A small robot can carry a camera, an inertial sensor and wheel encoders, yet still benefit from a fixed reference that helps it place itself within a building. An indoor drone faces the same opportunity in three dimensions. For affordable machines, adding another radio, antenna and positioning system is a meaningful design decision.
We already have inexpensive clocks sharing time over Bluetooth Low Energy. Could several of those clocks, placed at known locations, also help a machine work out where it is?
That is the question behind PToB-IPS, our new research into an indoor positioning system built around surveyed BLE timing beacons. The ambition is a navigation aid that reuses suitable MCU radios and complements the sensors a robot or drone already carries, without requiring a dedicated ranging radio in the baseline design.
The new paper develops the architecture and its limits. It is a theoretical research draft: we have measured relative clock timing on existing PToB paths, but have not yet demonstrated indoor ranging or a position fix from this constellation.
A local constellation of clocks
Imagine placing several PToB devices around a workshop and measuring their antenna locations. Each beacon shares a common time coordinate and repeatedly broadcasts an identifiable radio event. A mobile receiver records when each event arrives and obtains the corrected time at which it was transmitted.
The travel time contains distance information. With observations from enough well-placed beacons, a solver could estimate the receiver’s position and its own clock offset together. This is the useful part of the GNSS analogy: known transmitters, measured arrival times and a joint position-and-clock calculation. Fixed antenna coordinates take the place of satellite positions.
The receiver would not need accurate UTC before it starts. The constellation needs a consistent local time reference. In a simple static model, known-height positioning needs at least three independent observations; three-dimensional positioning with an unknown clock offset needs at least four. Those are minimum counts, subject to geometry and ambiguity checks. Motion and unknown clock drift add further requirements.
Broadcasting a clock value alone does not supply that measurement. We need the physical transmit event, its matching receive capture and the delays between those events and the antennas. Recovering those relationships is the central engineering problem.
How it could help a robot or drone
The most useful first role may be a coarse external position reference. A robot could combine a beacon observation with wheel motion and visual tracking. A drone could combine it with inertial measurements, optical flow and a height estimate. Between beacon updates, those onboard sensors would continue tracking motion.
If the beacon measurements prove reliable, they could help constrain accumulated drift or check whether a vehicle’s local estimate agrees with the room’s coordinate system. How much they help must be measured against the same vehicle using its existing sensors alone. A coarse room-scale result could be useful for some tasks while remaining inadequate for a doorway, landing point or obstacle avoidance.
Navigation software already combines observations with different uncertainties; PX4’s navigation filter is one example. PToB-IPS would need its own integration, including observation time, coordinate frame, uncertainty and freshness. We have not implemented that interface.
Shared time has another possible use: relating camera frames, inertial samples and other observations to the same instant. That requires timestamping the actual sensor acquisition and measuring its clock relationship. A well-synchronized MCU clock does not automatically timestamp an exposure hidden behind a driver queue.
One broadcast infrastructure, many listeners
Passive reception is an attractive part of the proposal. A fixed set of beacons could serve many mobile receivers without a separate ranging exchange for every receiver and anchor. The baseline broadcast workload would follow the beacon schedule, rather than growing with every listening robot. Admission, telemetry and other fleet traffic would still have their own costs.
One receiver radio also needs a workable listening schedule. Our paper proposes coordinated periodic advertising, with beacons assigned different time offsets. An illustrative plan mixes 16, 8 and 4 broadcasts per second, repeating over a 250 ms cycle. A receiver would follow the relevant trains and tune to each predicted channel in its reserved window.
Periodic advertising provides repeated events and the information needed to follow a train. Aligning several transmitters into this proposed schedule requires additional controller work. Updating a software clock does not move the physical advertising timer.
The receiver would hear these packets at separate times. Ordinary BLE packets do not become separable GNSS signals when they overlap. Actual airtime, switching delays, missed packets and follow-up corrections all have to fit the schedule. The rates above are an analytical example, not an implemented PToB-IPS mode or a guaranteed position-update rate.
Clock precision is only the starting point
Radio signals travel about 30 centimetres in one nanosecond. That makes very small timing errors significant at room scale.
| One-way timing error | Equivalent distance |
|---|---|
| 100 ns | About 30 m |
| 10 ns | About 3 m |
| 1 ns | About 0.30 m |
These are physical conversions, not predictions of PToB position accuracy. Geometry, clock correlations and endpoint delays determine how measurement errors affect a position solution.
Our latest published W12 baseline recorded 60.3 ns RMS relative timing error across 522 usable observations out of 600 logged, with a 180 ns largest usable error. The remaining 78 observations were unavailable during a source transition. That is encouraging evidence for inexpensive shared clocks. It measures a delivered clock against captured PPS, however, and does not establish beacon-to-beacon RF delay calibration or pseudorange noise. We cannot insert that RMS into a localization formula and call the answer achieved accuracy.
Finer capture could help. Our ESP32-S3 receive path uses an 80 MHz counter with 12.5 ns ticks. One tick corresponds to about 3.75 m of one-way travel. That describes the measuring grid; the radio detector and its delays remain part of the measurement. Raising CPU frequency or printing finer timestamp units cannot recover missing radio timing information.
Why averaging helps until it stops
Fixed, powered beacons can spend time learning their clock rates and tracking slow changes. A stationary receiver can also average repeated observations. Independent random noise can shrink as more samples accumulate.
Persistent errors behave differently. An antenna delay, a reflection or a beacon-specific clock offset can remain stable through every repetition. Averaging can then make the answer look more consistent while leaving it wrong.
The paper illustrates this with eight ideally surveyed anchors around a 10 × 8 × 3 m room. Under an explicitly hypothetical model of 30 ns independent observation noise, averaging 256 complete epochs reduces calculated horizontal RMS from about 6.70 m to 0.42 m. Add a hypothetical 5 ns persistent error per anchor and the corresponding result is about 1.19 m. These are analytical sensitivity examples at the room centre, not measured positions or forecasts from our PPS results.
There is also a time cost. This room calculation separately assumes 16 complete eight-anchor epochs per second, rather than the mixed-rate schedule above. Collecting 256 epochs takes 16 seconds. A drone moving at 5 m/s travels 80 m in that interval. Its observations cannot be averaged as though they describe one stationary point. Long-term beacon-clock estimation and a moving receiver’s short navigation window solve different problems.
The room is part of the instrument
The first challenge is calibration. A delay inside a transmitter or receiver can masquerade as extra distance. We need to characterize the physical event convention and how its delay changes with board, channel, signal level and operating conditions. Calibration learned at one position must then work at other, independently measured positions.
Indoor propagation adds another difficulty. Metal shelving, walls, people and the vehicle itself can obstruct a direct path or produce reflections. NIST’s indoor localization research describes how multipath makes direct-path isolation difficult even for dedicated ranging systems. A faster counter alone cannot identify which part of a received signal followed the shortest path.
Placement matters too. Beacons spread around a room and across different heights provide different information from a row along one wall. Poor vertical geometry is especially consequential for a drone. More beacons provide useful redundancy only when their geometry, errors and availability support the solve.
Finally, every observation has an age. A mobile receiver changes position while it listens to successive beacons, and its oscillator continues drifting. The estimator must account for both. Missing corrections, source changes and expired clock models must produce visible uncertainty or unavailable output. A plausible coordinate made from stale inputs would be a poor navigation aid.
What reusing existing hardware really means
Our baseline goal is to use suitable BLE MCU hardware without adding a dedicated UWB radio or an antenna array. Existing PToB clocks give us candidate infrastructure and experience with event capture, clock maps and source validity. They are a starting point for the proposed navigation service.
Compatibility depends on what a target actually exposes: native receive captures, a defined or calibrated transmit event, sufficient timers and memory, and control of the required advertising and listening schedules. An application that only sees packet-delivery callbacks may lack the timing information. A robot having Bluetooth on its specification sheet does not establish a firmware-only upgrade path.
Future radios may offer additional measurements. Bluetooth Channel Sounding supports phase-based ranging and round-trip timing on controllers that implement it. Those capabilities cannot be assumed on older BLE parts. UWB could also provide a reference or an intermediate service during development; it is optional in this research, rather than a prerequisite for the proposed BLE baseline.
The budget case includes installation
Reusing a radio could reduce incremental hardware cost, especially when the same surveyed infrastructure serves several machines. That is a compelling hypothesis for small robots, educational platforms and indoor drone experiments working within tight budgets.
The comparison has to include the whole installation: beacon placement and power, survey, firmware integration, calibration, maintenance and the coverage needed for the task. A cheap board can become an expensive system if it needs frequent specialist attention. We have no measured price advantage to claim yet.
The economic test is whether reuse delivers the required accuracy, availability and latency at a lower total cost than the alternatives. That question belongs alongside the radio experiment from the beginning.
What a useful first experiment looks like
We would start with the simplest physical question: do calibrated arrival-time differences track known changes in distance? Freeze the corrections, move a receiver between surveyed locations and retain the misses and large errors alongside successful observations.
Then test a constellation with more than the minimum anchor set, initially using a stationary or slowly moving receiver. Hold entire locations out of calibration. Report position error, false room assignments, delivered-fix availability, latency and the longest outage. Repeat across boards, boots and RF conditions. A solver converging on a coordinate is only the beginning of that evidence.
Motion comes next, followed by comparison with the robot’s or drone’s existing sensor system. The practical question is how much useful navigation information the beacons add under the same conditions and budget.
We began PToB by asking how much timing precision was already available in inexpensive radio boards. PToB-IPS takes that question into space: whether those clocks can also become affordable fixed references for machines moving indoors. There is substantial work between shared time and dependable navigation, and a concrete set of experiments can now tell us how far the idea goes.