# Exposure Notifications BLE calibration calculation

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.

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.

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:

### 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:

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 “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).

[{ "type": "thumb-down", "id": "missingTheInformationINeed", "label":"Missing the information I need" },{ "type": "thumb-down", "id": "tooComplicatedTooManySteps", "label":"Too complicated / too many steps" },{ "type": "thumb-down", "id": "outOfDate", "label":"Out of date" },{ "type": "thumb-down", "id": "samplesCodeIssue", "label":"Samples / code issue" },{ "type": "thumb-down", "id": "otherDown", "label":"Other" }]
[{ "type": "thumb-up", "id": "easyToUnderstand", "label":"Easy to understand" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"Solved my problem" },{ "type": "thumb-up", "id": "otherUp", "label":"Other" }]