Skip to content

802.11mc FTM Reconnaissance Report

Private Positioning System Integration for UTLP

mlehaptics Project — December 2025

Integrates parallel research from Gemini (Google)

Executive Summary

802.11mc Fine Time Measurement (FTM) provides nanosecond-level timestamping for WiFi Round-Trip Time (RTT) ranging, enabling 1-2 meter indoor positioning. Google has deeply invested in this technology across Android (since API 28), Pixel phones, Nest WiFi routers, and the new TrustedTime API. ESP32 series chips (S2, S3, C3, C6) have FTM support in ESP-IDF, though ESP32-C6 has a hardware errata affecting initiator mode in earlier chip revisions.

Key Finding: The same nanosecond-precision timestamping infrastructure that enables 802.11mc ranging could potentially be leveraged for UTLP time synchronization, giving us sub-microsecond precision "for free" on $5 hardware.

Critical Insight (Gemini): Google effectively "wrote the book" on consumer 802.11mc but hid the privacy-preserving capability behind a Location Services wall. The protocol is inherently client-side only — the AP never learns your distance, only your phone does. By building an offline-first swarm, we're utilizing Google's standardized hardware capability while stripping away the OS-level data tether. We're building the "Private Mode" that Android could have had.

1. Google's Hidden Play: The "Open Secret"

1.1 Indoor Live View

Google has been heavily investing in 802.11mc (Wi-Fi RTT) since Android 9 (Pie). Their use case is straightforward: fix the "Blue Dot" problem in airports and malls. GPS gets you to the building; RTT gets you to the Cinnabon.

The feature is called Wi-Fi RTT in Android developer docs, accessible via WifiRttManager.

1.2 The Privacy Architecture (That Google Buried)

The protocol is inherently privacy-preserving: - The Access Point (AP) does not know your distance - Only your phone calculates position - This is baked into 802.11mc by design

The Catch: To access the API on Android, Google forces the user to enable System-Wide Location, which usually implies sending data to Google. The hardware is private; the OS layer is not.

1.3 Our Novelty

By building an offline-first swarm with UTLP + FTM, we're: - Utilizing Google's standardized hardware capability - Stripping away the OS-level data tether - Building the "Private Mode" that Android could have had

This is prior art for privacy-preserving indoor positioning on commodity hardware.

2. What 802.11mc FTM Actually Does

2.1 The Protocol

FTM measures round-trip time between two WiFi devices using four timestamps (T1-T4), identical to our UTLP sync mechanism:

RTT = (T4 - T1) - (T3 - T2)
Distance = RTT × c / 2

Where: - T1: Initiator transmit timestamp - T2: Responder receive timestamp
- T3: Responder transmit timestamp (ACK) - T4: Initiator receive timestamp

Critical insight: This is exactly our PTP-inspired offset calculation. The hardware timestamping that enables ~3.3 nanoseconds/meter ranging precision could provide sub-microsecond time sync.

2.2 Precision Numbers

Bandwidth Ranging Accuracy (90th percentile) Time Precision
80 MHz ±2 meters ~6.6 ns
40 MHz ±4 meters ~13 ns
20 MHz ±8 meters ~26 ns

Radio waves travel at ~29.98 cm/nanosecond. The 2-meter accuracy at 80 MHz implies timing precision of approximately ±6.6 nanoseconds — three orders of magnitude better than our current ±30μs BLE sync.

3. Google's Investment

3.1 Android Integration Timeline

Version Year Feature
Android 9 (API 28) 2018 WifiRttManager API, initiator support
Android 10 (API 29) 2019 ResponderLocation (LCI/LCR data)
Android 12 2021 One-sided RTT for legacy APs
Android 15 (API 35) 2024 IEEE 802.11az Next Generation Positioning

3.2 Hardware Support

Google Devices with FTM: - Google Pixel 2, 3, 4, 4a, 5, 6, 7 (initiator mode) - Google WiFi (original) — responder mode - Google Nest WiFi — responder mode - Google Nest WiFi Pro — responder mode

Implications: Any recent Pixel phone can serve as a high-precision time reference for nearby UTLP devices via 802.11mc ranging.

3.3 TrustedTime API (February 2025)

Google's newest API provides: - Tamper-resistant timestamps from Google's NTP infrastructure - Clock drift estimation between syncs - Millisecond precision with error bounds - Sources: GPS, NTP, carrier networks

Integration opportunity: TrustedTime → Phone → 802.11mc FTM → ESP32 devices could create a GPS-traceable timing chain to consumer IoT hardware.

4. ESP32 FTM Support

4.1 Supported Chips

Chip FTM Initiator FTM Responder Notes
ESP32 (original) ❌ ❌ No support, use CSI instead
ESP32-S2 ✅ ✅ Supported since 2021
ESP32-S3 ✅ ✅ Full support
ESP32-C3 ✅ ✅ Full support
ESP32-C6 v0.0/v0.1 ❌ ✅ Errata WIFI-9686
ESP32-C6 v0.2+ ✅ ✅ Fixed in latest silicon

4.2 The ESP32-C6 Advantage (Gemini)

Most "Wi-Fi 6" chips support RTT, but few expose the raw FTM Initiator mode to developers.

Device FTM Initiator FTM Responder
Google Wifi / Nest Wifi ❌ ✅
Android Phones ✅ ❌
ESP32-C6 ✅ ✅

This is significant: You can configure ESP32-C6 as: - FTM Responder (acting like a Google Router) - FTM Initiator (acting like an Android Phone)

Most consumer hardware only does one or the other. ESP32-C6 does both — enabling peer-to-peer ranging within your swarm without needing phones or routers.

4.3 ESP32-C6 Errata (Critical for mlehaptics)

[WIFI-9686]: "The time of T3 (time of departure of ACK from Initiator) cannot be acquired correctly" in chip revisions v0.0 and v0.1.

Impact: Early ESP32-C6 chips can be FTM Responders (APs) but not Initiators (stations).

Solution: Fixed in chip revision v0.2. Check your silicon revision.

4.4 ESP-IDF Implementation

FTM is available via examples/wifi/ftm/ with: - Initiator and Responder modes - Configurable burst count (default 32 frames) - RTT calculation with automatic averaging - Kconfig options: CONFIG_ESP_WIFI_FTM_INITIATOR_SUPPORT, CONFIG_ESP_WIFI_FTM_RESPONDER_SUPPORT

Arduino support: Added in ESP32 Arduino 2.0.0 (October 2021) via WiFi/examples/FTM/.

5. LCI/LCR: Self-Locating Access Points

5.1 What It Is

Location Configuration Information (LCI) and Location Civic Report (LCR) allow APs to broadcast their GPS coordinates. Android 10+ can retrieve: - Latitude, longitude, altitude - Uncertainty radius - Floor number - Civic address (building name, room, etc.)

5.2 NMEA-Like Location Data

LCI provides GPS-style coordinates that can be formatted as NMEA sentences:

$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68

An ESP32 configured as an FTM responder with LCI could broadcast: - Its own GPS-derived position (from initial config or connected phone) - A "Private GPS" signal for devices that can't see satellites

Use case: Indoor EMDR therapy device knows its room-level location for session logging without requiring GPS hardware.

6. Timing Precision: The Hidden Goldmine

6.1 From Ranging to Sync

The FTM protocol timestamps packets at nanosecond resolution. While the API exposes distance, the underlying mechanism provides time offset — exactly what UTLP needs.

Current UTLP over BLE: ±30μs precision Theoretical FTM precision: ±10-100ns (hardware timestamping)

That's a 300-1000x improvement if we can access the raw timestamps.

5.2 Implementation Approach

Two paths to explore:

  1. Use FTM for time sync directly: Instead of ranging, extract T2-T1 and T4-T3 as clock offset measurements.

  2. Use FTM alongside BLE: WiFi FTM for initial high-precision sync, BLE for ongoing low-power maintenance.

5.3 ESP-IDF FTM Report Data

The ESP-IDF FTM example exposes raw timing:

I (393564) ftm_station: | Diag | RTT | T1 | T2 | T3 | T4 | RSSI |
I (393574) ftm_station: | 5| 193750 | 6168893584375 | 6018054264062 | ...

Those T1-T4 values in picoseconds are the raw material for sub-microsecond UTLP sync.

7. Private Positioning System Architecture

7.1 Concept

Create a GPS-like positioning system using UTLP time + 802.11mc ranging:

┌─────────────────────────────────────────────────────────────┐
│                    UTLP Private GPS                          │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────┐    802.11mc     ┌──────────┐                  │
│  │  Phone   │◄───FTM/RTT────►│  ESP32   │                   │
│  │  GPS +   │    + LCI        │ Responder│                   │
│  │TrustedTime│                │ (AP Mode)│                   │
│  └──────────┘                 └──────────┘                   │
│       │                            │                         │
│       │ UTLP Stratum 1            │ UTLP Stratum 2          │
│       │ (GPS-locked)               │ (Phone-synced)          │
│       ▼                            ▼                         │
│  ┌──────────┐    BLE/WiFi    ┌──────────┐                   │
│  │  EMDR    │◄──UTLP Sync───►│  EMDR    │                   │
│  │  Left    │                │  Right   │                    │
│  └──────────┘                └──────────┘                    │
│                                                              │
│  All devices share: Time (±100ns), Position (±2m)           │
└─────────────────────────────────────────────────────────────┘

7.2 Stratum Enhancement

Stratum Source Precision Example
0 GPS/Atomic <1μs Lab reference
1 TrustedTime API ~1ms Pixel phone
1a FTM from Stratum 1 ~100ns NEW: WiFi RTT
2 UTLP from Stratum 1 ~30μs BLE beacon
255 Crystal free-run ~1ms/min drift Standalone

FTM creates a new sub-stratum (1a) that's better than BLE (Stratum 2) but doesn't require GPS hardware.

8. Private Maps: The "Marauder's Map" Application

8.1 NMEA-Compatible Local Coordinates

If you feed your (x, y) coordinates into a standard NMEA parser, you can trick existing mapping software into working offline. The LCI/LCR data structure already uses WGS84 coordinates.

Project Concept — "The Marauder's Map": - A swarm of 3+ UTLP beacons in a field creates a local coordinate system - A tablet running your app displays the location of every device in real-time - Zero internet connection, zero GPS required

You're effectively rebuilding the Google Maps Indoor Stack for the "Air-Gapped" world.

8.2 Use Cases

Application Description
EMDR Session Logging Therapist tablet shows device positions in room
Warehouse Asset Tracking Offline inventory location
Event Coordination Festival/conference device tracking
Search & Rescue Swarm-based positioning without cellular
Sensitive Facilities Indoor positioning without data exfiltration

8.3 The Privacy Proposition

What Google's Indoor Live View does: - GPS → Google → Phone → Local Position Display

What UTLP + FTM Private Maps does: - Local FTM Ranging → Local Position Calculation → Local Display - No cloud, no GPS, no data leaves the premises

9. Hybrid UTLP + RTT Protocol Design

9.1 The Integration Challenge

Standard 802.11mc requires "negotiation" via Action Frames — it's not passive like UTLP beacons. We need a hybrid approach that preserves UTLP's broadcast simplicity while enabling on-demand ranging.

9.2 Proposed Flow

1. PASSIVE: Client hears UTLP Beacon → Syncs Time
2. DECISION: Client sees RTT_CAPABLE flag in beacon
3. ACTIVE: Client pauses "Listening", initiates FTM Burst with Master
4. RESULT: Client gets Distance (Space) + resumes Time sync

9.3 Hybrid Advertisement Structure

Extends the existing UTLP payload with RTT capability flags:

// utlp_hybrid.h

// Extended UTLP Beacon with RTT capability advertisement
typedef struct __attribute__((packed)) {
    uint8_t  magic[2];       // 0xFE, 0xFE (UTLP identifier)
    uint8_t  flags;          // Bit 0: IS_TIME_MASTER
                             // Bit 1: IS_RTT_RESPONDER (Supports 802.11mc)
                             // Bit 2: HAS_LCI (Can provide GPS coordinates)
    uint8_t  stratum;        // 0 = GPS, 255 = Free Run
    uint8_t  quality;        // 0-100 (Battery/Oscillator confidence)
    uint8_t  hops;           // Distance from Master (loop prevention)
    uint64_t epoch_us;       // Microseconds since epoch
    int32_t  drift_rate;     // Estimated drift in ppb
    // Optional LCI data follows if HAS_LCI flag set
} utlp_hybrid_payload_t;

// Flag definitions
#define UTLP_FLAG_TIME_MASTER    (1 << 0)
#define UTLP_FLAG_RTT_RESPONDER  (1 << 1)
#define UTLP_FLAG_HAS_LCI        (1 << 2)

9.4 The Key Insight

The FTM Action Frame exchange is handled by the ESP32-C6 WiFi driver — we don't write that packet structure. IEEE 802.11-2016 defines it. Our job is to:

  1. Advertise capability via UTLP beacon flags
  2. Configure ESP32 as FTM Responder (AP mode)
  3. Let clients initiate FTM when they need ranging

This preserves UTLP's "Time is a Public Utility" philosophy while adding opt-in spatial awareness.

10. Technical Risks and Open Questions

10.1 Confirmed Issues

  1. ESP32-C6 errata: Earlier silicon can't be FTM initiator. Check chip revision.
  2. Single-core contention: FTM uses WiFi stack; may conflict with BLE on ESP32-C6.
  3. Indoor accuracy degrades: Multipath and NLOS cause 6-8m errors in cluttered environments.

10.2 Unknown / Needs Testing

  1. Can we access raw T1-T4 timestamps? ESP-IDF exposes them in debug output; need to verify API access.
  2. Power consumption of FTM: WiFi is power-hungry vs BLE. Hybrid approach needed?
  3. FTM + ESP-NOW coexistence: Can we run both simultaneously?
  4. 802.11 LR + FTM: Does Espressif's Long Range mode support FTM?

10.3 Deeper Dive Topics

Topic Priority Rationale
Raw timestamp API access HIGH Core enabler for UTLP-FTM integration
ESP32-C6 v0.2 validation HIGH Confirms initiator mode works
Power profiling MEDIUM Battery life impact assessment
WiFi/BLE coexistence MEDIUM Needed for hybrid approach
LCI/LCR implementation LOW Nice-to-have for location services

11.1 Immediate (This Week)

  1. Check ESP32-C6 chip revision: Run esptool.py to identify silicon version
  2. Build ESP-IDF FTM example: Confirm basic ranging works
  3. Capture raw timestamp data: Analyze T1-T4 values for sync potential

11.2 Short-Term (This Month)

  1. Prototype FTM time sync: Extract offset from FTM exchange
  2. Compare precision: FTM sync vs current BLE sync
  3. Test with Pixel phone: Validate Android WifiRttManager interop

11.3 Medium-Term (Q1 2026)

  1. Hybrid UTLP transport: BLE for low-power, FTM for high-precision
  2. Private positioning demo: Indoor location without GPS
  3. Document as UTLP extension: Prior art for FTM-enhanced sync

12. Key Takeaways

  1. The timestamp hardware is already there. 802.11mc's ranging precision implies nanosecond-level timing capability that could upgrade UTLP from ±30μs to ±100ns.

  2. Google is all-in. Android API, Pixel support, Nest hardware, TrustedTime API — this is strategic infrastructure, not abandoned experiment. Roy Want (Google) publicly frames 802.11az as "critical infrastructure pillar."

  3. ESP32-C6 works, with caveats. Responder mode is fine; initiator mode needs v0.2 silicon. Other ESP32 variants (S2, S3, C3) have full support.

  4. The privacy story is ours to tell. Google built privacy-preserving hardware but buried it under Location Services data collection. We're exposing the "Private Mode" that could have existed all along.

  5. Private positioning is achievable. FTM + LCI enables GPS-like indoor location from $5 hardware — a differentiator for assistive tech applications. "Marauder's Map" for the air-gapped world.

  6. Prior art opportunity. UTLP + FTM integration is novel. The hybrid beacon structure with RTT_CAPABLE flags is documentable prior art.

References

Report prepared for targeted feedback and deeper investigation.