Q: What release of Android is required?

FTMRTT currently requires at least Android 10 (i.e. API level 29) (Android 13 — API level 33 — recommended) and the phone needs to support Wi-Fi RTT.

Q: Can the positions of the APs be given in inches instead of meters?

A: Yes, in the bounding box JSON file add
     "units" : "imperial",

Q: Can the positions of the APs be given in geographical coordinates?

A: Yes, in the bounding box JSON file add
     "type" : "geographical",
and give latitude and longitude in degrees.

Q: When specifying the location of the APs, do I need to specify the height (third coordinate)?

A: You will get slightly more accurate results if you include it because the distance in the real world (3-D) is larger than the distance in the ground plane (2-D) by an amount that depends on the vertical separation between the AP and the “user equipment” (UE). This is of importance when near an AP.

Q: How can I specify the relationship between a rectangular coordinate system (used for on-screen display) and the geographical coordinate system?

A: Specify the origin of the local rectangular (Cartesian) coordinate system in the geographical coordinate system using "origin" : [latitude-in-degrees, longitude-in-degrees]. Specify the angle between the local East-West direction and the x-axis of the Cartesian system in degrees using "angle" : angle-in-degrees (measured counter clockwise). For example:
    "origin" : [ 35.0289306, -61.1157309 ], // this corresponds to [ 0, 0 ] in the Cartesian coordinate system,
    "angle" : 24.38, // degrees

Q: An AP advertizes several different BSSIDs. Would it make sense to treat these as separate APs?

A: BSSIDs of an AP on the same frequency use the same WiFi chips and operate in the same way. So measurement obtained by ranging to them will yield similar results (i.e. they are not independent). However, those operating on different frequencies do provide the opportunity to get more information, since the transmission conditions are different. It is, for example, worthwhile treating the 2.4 GHz band and the 5 GHz band separately (i.e. pick one of the BSSIDs in each band and consider each a "responder").

Q: Can one assume that the offset / bias for one-sided RTT is the same for all APs of a certain type and model operating in the same band?

A: The offset / bias (for one-sided RTT) tends to be pretty much the same for APs of the same make and model (i.e. ones with the same “Organizationally Unique Identifier” or OUI). But the offsets in different bands are different. Also, within the 5 GHz band, the “Dynamic Frequency Selection” (DFS) frequencies may in some cases be dealt with using a different WiFi chip and so have a different offset from those operating in the rest of the 5 GHz band. (Use WifiRttScanX to check, if needed). In the responders JSON file, for the relevant APs add
    "offset-one-sided" : ... and
    "offset-DFS" : ....

Q: Can I assume that the frequency assigned to a particular BSSID remains the same?

A: In most home WiFi setups, the APs always operate on the same frequencies. In “enterprise” WiFi systems, on the other hand, the frequencies are often reassigned to maximize throughput and minimise interference. This may happen on a daily basis. FTMRTT will determine the frequencies (as well as bandwidths and preambles) currently in use. When assignments can switch between DFS channels and non-DFS channels, this may affect the offset / bias in one-sided RTT (see previous question).

Q: What is the minimum number of access points for FTMRTT?

A: To avoid any ambiguity: 3 (when operating in 2-D). FTMRTT can be used with two APs, but there then remains a to-way ambiguity (reflection about the line connecting the two APs).

Q: What is the ideal density of access points (APs per 1000 square meter)?

A: Localization becomes near trivial when the responder density is high (just pick the location of the AP with the strongest signal). At the other extreme, FTMRTT needs three or more APs within range (and unobscured) in the area of interest. So, depending on circumstances, densities in the range of 2 to 20 APs per 1000 square meters tend to work well.

Q: Do the access points have to be “on the internet”?

A: No — just powered up (although some types of APs may shut down their WiFi signalling when not connected for a long time).

Q: Is there a way to control where the text next to an AP is shown on screen?

A: Yes, add "code" : position_code to the entry for an AP in the responders file. The position code is 4 for NorthWest, 5 for SouthWest, 6 for NorthEast, and 7 for SouthEast.

Q: How do I specify a “wall color”?

A: A “wall” is considered impenetrable by the Bayesian update rule. Probabilities can't “tunnel” through it. Black pixels in the floorplan image can serve to mark walls. For walls in different colors, an entry can be added to the bounding box file of the form
     "wallcolor" : 0xFFCCB280,
where the hexadecimal number has the form 0xAARRGGBB with AA being the opacity and so on. (Note specification of numbers in hexadecimal is another extension of JSON format supported by the Android JSON parser).

Q: Why can't the APs just announce their locations? Then there would be no need for the responders file.

Compulab WILD allows one to provide this information to the AP (using the hostapd.conf file). Recently, Aruba's Open Locate initiative has made location information available in their APs. See Self-locating Wireless Access Points.

Q: When I rotate about my vertical axis, the heat map of probability density moves around a bit even though I'm still in the same location.

A: In orientations where the body blocks the direct line of sight (LOS) to an AP, signals to and from that AP are attenuated, but more importantly, delayed. Electromagnetic radiation travels through matter at the speed of light divided by the refractive index. Different materials have different refractive index. Those containing a lot of water tend to have a high refractive index. As a result, the measurements to APs taken through the body tend to be a bit larger than they would otherwise be because of this “refractive retardation”. This causes a small displacement of the estimated location.

Q: Can FTMRTT operate in 3-D?

A: Yes, see e.g. 3-D example. Watch this space for a link to a page explaining how to do this.

Q: Why “side loading”?

A: FTMRTT is now available on the Google Play Store. But you can still sideload the latest beta version of FTMRTT.