This document describes how Exposure Notifications Bluetooth Low Energy (BLE) correction values are computed for individual Android devices. We do this by computing the received signal strength indicator (RSSI) correction and the transmit power for each Android device, as follows:
- The RSSI correction is computed such that the received strength is equal to what a typical iPhone device would report for the same transmitter at the same distance.
- The transmit power is computed to report for each Android device equivalent to what a typical iPhone would report if transmitting at the same power.
For details on how these values are then used by the Exposure Notifications framework, see Attenuations as distance proxy.
Data collection
The calibration corrections rely on manual data collection covered in the BLE RSSI calibration procedure.
RSSI Correction and transmission power calculation
We compute the RSSI Correction and the transmit power using separate equations that rely on similar calculations.
RSSI Correction calculation
The RSSI Correction is a single bias number for each Android device. We compute the RSSI Correction as follows, where ref1 and ref2 represent reference transmitters.
rssi_correction(device) = AVG_RSSI(ref1 -> iphone) - AVG_RSSI(ref1 -> pixel4) + AVG_RSSI(ref2 -> pixel4) - AVG_RSSI(ref2 -> device)
Computation of RSSIs
We compute RSSIs relying on measurements of ref1 and ref2 taken from different sources. As for computing the RSSIs that rely on a common reference transmitter, we compute under conditions where the test setup remains as constant as possible.
The following is a partial list of test setup parameters that must be held constant for RSSI measurements sharing a common reference transmitter:
- Physical transmitting device and its orientation
- Distance between transmitter and receiver
- Transmit power
- Test environment (all measurements should be collected at roughly the same place and time)
Computation of average values
Each RSSI value represents an average taken across multiple variations of situations to capture the range of values that could be experienced by a user. We repeat each of the RSSI values described above under each of these situations, with each yielding an additional RSSI value that is averaged with the others.
The following is a partial list of variations of situations we try to collect:
- Rotations of the receiving device. This ensures we are not computing a biased correction due to having the receive device oriented in a particularly strong or weak direction. The BLE RSSI calibration procedure outlines the orientations we plan to collect.
- Receiving iPhone type. We are attempting to measure an offset between an Android device and a “typical” iPhone, so we compute the RSSI of several iPhone models and average them together.
To average RSSI values, we first convert to power, then convert back to dB. This
ensures that any noise or biases from multipath affects each test configuration
equally in the average (instead of adding an extra boost to weakly received
signals). We compute the AVG_RSSI as follows:
Figure 1. Calculation for AVG_RSSI
Transmission power computations
To determine the transmission power for an Android device that best reflects what an iPhone would report when transmitting at the same power, we use the following calculation:
tx_power(device) = AVG_IPHONE_TX + AVG_RSSI(pixel4->ref1) - AVG_RSSI(iphone->ref1) + AVG_RSSI(device -> ref2) - AVG_RSSI(pixel4->ref2)
Because the Exposure Notifications framework uses the
ADVERTISE_TX_POWER_LOW
setting, we perform those calibrations with the Android devices set to that same
setting.
We compute RSSIs as described in Computation of RSSIs (with the caveat that transmission power has already been computed).
We compute average values using the equation shown in figure 1. The
AVG_IPHONE_TX is the average advertised TX value from each transmitting iPhone
(corresponding to the AVG_RSSI(iphone->ref1) term).
Calibrating untested devices
Using a Supported-devices list, we can extend calibrations measured directly on devices to other unmeasured devices based on associated device or OEM names. We average corrections at the finest granularity possible.
For example, if an Android model shares a device name with a directly-measured model that appears in the “Device” column, we average all directly-measured corrections that share that device name. As a fallback, we average all directly-measured corrections that share the device name appearing in the “Marketing Name” column. If there are no “Marketing Name” matches, we average all directly-measured corrections that share the same OEM. If there are no direct measurements with the same OEM, we average all corrections across all devices.
While we understand that this is a very coarse method of calibration, we use it as a stopgap measure until we have more data from devices that are directly measured and provided by our partners.
Device calibration list
This Device calibration list is a comma-separated value (CSV) file that provides the values calculated for supported Android devices. The following list includes additional information about the list:
- The “manufacturer”, "device", and “model” columns list the manufacturer,
device, and model of each Android device, as specified in
android.os.Build. - The “rssi correction...” column lists the RSSI correction (as calculated by the RSSI Correction calculation).
- The “tx...” column lists the transmit power (as calculated by the RSSI Correction and transmission power calculation).
- The "calibration confidence" column describes our confidence in the given
calibration values ranked from 1 to 3, defined as follows:
- 1: Low confidence. Calibrations are averaged over measurements taken from other models with the same manufacturer.
- 2: Medium confidence. Calibrations are computed from measurements of this model but only using a single antenna orientation.
- 3: High confidence: Calibrations are computed from measurements of this model using significant calibration data including a range of antenna orientations.
Device calibration list version history
2020-12-14: This file added the results calibrated by Google partners (Samsung, Motorola, Oneplus, Sony, Asus, and others) by collecting RSSI values at 12 different relative rotation angles and averaging the results.
2020-09-18: This file added the results calibrated by Google partners (HMD, Motorola, Oppo, Samsung, and so on.) by collecting RSSI values at 12 different relative rotation angles and averaging the results.
2020-08-12: This file presents the results of a recalibration on about 300 Android devices by collecting RSSI values at 12 different relative rotation angles and averaging the results.
2020-06-13: This file is an initial calibration performed on about 300 Android devices at a fixed angle between pairs of devices (portrait mode, back-to-back).