-
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.)
-
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.
-
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.
- 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).
-
FTM RTT ranging requests are ignored when an app is in the background.
-
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),
the more recent
Google Nest WiFi (as of May 2020)
and the new
Google Nest WiFi Pro.
See Android Developer's
list of access points that support FTM RTT.
-
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).
Presently, Compulab
Wi-Fi Indoor Location Device (WILD).
provides a way of setting up the capability of an AP to provide its
own position
to a requestor
(using -lci=... and -civic=... lines in the
hostapd.conf file).
Recently, Aruba's Open Locate initiative has made location
information available in their APs. See
Self-locating Wireless Access Points.
-
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.
-
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.
-
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”.
-
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).
-
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