Some Issues, Problems and Limitations

  1. A system with working API for FTM RTT is needed on the mobile device. Android 9 (API Level 28) and later support FTM RTT. Google Pixel (and Pixel 2, Pixel 3, Pixel 4, Pixel 4a (5G), Pixel 5, Pixel 6) run Android 9, 10, 11, 12 or 13. These versions of Android are now available on some other phones as well (although some do not have Wi-Fi modems that supports FTM RTT).

    Samsung Note 10+, Samsung A9 Pro, and LG V30 support FTM RTT — as do over 50 other phones at this point. See Android Developer's list of phones that support FTM RTT.

    By the way, Windows 10 has no API for FTM RTT. Nor does Apple iOS.

  2. Some important aspects of FTM RTT are not in the official Android API and so have to be accessed via Java Reflection. Update: starting in Android 12, access to some of these features is in the official API.

  3. Some of the required class methods and fields are “grey listed,” meaning that they may be removed in future releases. As a prime example, the very much needed WifiManager.startScan() is “deprecated” as of API level 28.

  4. Android API Level 28 (Android 9) introduced a limitation on how often Wi-Fi scans to find APs can occur — no more than 4 per 2 minutes in foreground mode (i.e. one scan per 30 seconds on average). At a comfortable walking speed of 1.4 m/sec, that means once every 42 meters. At that rate one will be out the other end of a building by the time one gets a chance to check on what Wi-Fi APs are nearby! (Fortunately this does not affect FTM RTT ranging directly).

    Note: On recent updates of Android 10 (4th QTR 2019) it is easy to override this: just disable “Wi-Fi scan throttling” from the “Developer Options” menu (assuming you have enabled “Developer Options”).

    This way it is possible to scan about every 3.8 seconds on Google Pixel 2, and about once every 2.5 seconds on Google Pixel 3 (for comparison, “Settings > Wi-Fi” scans every 10 seconds).

  5. FTM RTT ranging requests are ignored when an app is in the background.

  6. Currently, many installed Wi-Fi access points (APs) do not support FTM RTT (see Which Wi-Fi access points support the IEEE 802.11mc FTM RTT protocol?).

    One Wi-Fi RTT enabled access-point that is commercially available is Compulab's Wi-Fi Indoor Location Device (WILD). Another is Google WiFi (original) and the more recent Google Nest WiFi (as of May 2020). See Android Developer's list of access points that support FTM RTT.

  7. An AP can provide information about its position and location (LCI and LCR data structures), which can be retrieved (in Android 10 – API level 29) using RangingResult.getResponderLocation(). Without this, an indoor positioning app has to get AP position information “out of channel” (e.g. a file with the BSSIDs and coordinates of all of the APs). Currently only Compulab Wi-Fi Indoor Location Device (WILD). provides a way of setting up the capability of an AP to provide position information to a requestor (using -lci=... and -civic=... lines in the hostapd.conf file).

  8. While there appear to be over a dozen Wi-Fi chips that have been certified for Wi-Fi location, Wi-Fi APs using those chip sets mostly don't advertize support of IEEE 802.11mc FTM RTT in the beacon frame.

  9. FTM RTT signalling between Wi-Fi chips is affected by differences in bandwidth - 20, 40, or 80 MHz, and the type of preamble - LEGACY, HT, VHT, or HE. This can introduce timing offsets, which, in some cases, can translate into reported distance measurements that are as much as 6 to 8 meter too small or too large. FTM RTT connections between Wi-Fi chip sets may work well for certain experimentally determined combinations of bandwidth and preamble, but not others.

  10. Measurement errors do not follow a simple noise model. Errors in measurement are not Gaussian, not always unimodal, have outliers and, perhaps most importantly, are position dependent.

  11. Building materials have relative permittivity significantly larger than 1 (e.g. very roughly 4 to 16 for concrete). As a result, measured “distances” indoors can be much larger than the actual (Euclidean) distances between initiator and responder (this may often be more of a problem than multi-path propagation, which FTM RTT should be relatively immune to).

  12. The accuracy of position determination is not equal to the error of distance measurement, because of “dilution of precision”, which depends on the geometric arrangement of responders with respect to the intiator. Here an accuracy of a meter or two is more common (ignoring the occasional complete outlier). See also: Where to place the responders and Recovering position from distance measurements


Click here to go back to main article on FTM RTT.
Berthold K.P. Horn, bkph@ai.mit.edu

Accessibility