idea: self-calibration and advertisement of Tx levels

[peterboncz]

In order to measure distance, BLE signal strength and model name are the two most important signals, if I understand correctly.

Problem is that different devices transmit at different power levels (source Tx strength). The Singapore app felt with this by calibrating a collection of phone models https://github.com/opentrace-community/opentrace-calibration On issue is this list is not complete (and no static list will ever be complete). Another is that source Tx strength could be different at different device energy levels. A final issue is that source Tx strength might also differ among devices, e.g. because of slight different hardware or device damage.

My proposal is to advertise the own source strength in the bluetooth packets. The observed (via API) vs source s (advertised via BLE packet) max strength could be quite reliable for measuring distance. Better than getting source strength from a static database.

In order to establish the source strength, the app could have a calibration mode. By holding two phones (e.g. of family members) close together in a special calibration mode of the app, the apps can measure the other's actual Tx strength from up close. If the device has multiple power modes, one should cycle through these and measure the various levels (though the Singapore docs state that the mobile phones they observed always were transmitting at the same strength regardless power level -- in which case the "cycling through power modes" would not be a critical feature).

[floe]

In preparation for one of our BTLE-related papers (ShakeCast, https://dl.acm.org/doi/10.1145/3098279.3122131) we also did a couple of experiments regarding distance measuring using BTLE broadcasts. I'd be very cautious to assign any sort of absolute distance measure to signal strength, even with individual calibration, because the simple fact whether you carry your phone in your front or your back pocket will already have a much more pronounced influence on signal strength.

[peterboncz]

Thanks, looking at figure 9 of the Bundeswehr proximity study (by pepp-pt...):

https://github.com/pepp-pt/pepp-pt-documentation/blob/master/12-proximity-measurement/2020-04-09-BW-report-epi-mod.pdf

using perfect knowledge of source Tx strength they get pretty conflictingTx strength readings but still reach 25% False Negatives and 20% False Positives (whether that is good or bad I don't know) but that is also taking into account the length of the encounter.

Is there a DP^3T document that would explain what strategy contact-tracing apps should follow to flag contacts as "dangerous"? I understand from your response that in fact only length of the encounter should be used and not Tx strength.

another option would be to add the app user into the loop, e.g. to ask the user to annotate time intervals (e.g. prompt for feedback when there were many, or lengthy encounters), with their own assessment, maybe based on some questions (dangerous/safe, indoors/outdoors).

so now I changed the topic to the usability question underlying my original issue/idea: how to battle False Positives and False Negatives in BLE encounters?

[floe]

Ah, thanks for the pointer, will read this right now.

[peterboncz]

A related idea on how to battle False Positives and False Negatives is detection of outdoors/indoors; this appears to be possible to do based on the amount of GPS base stations: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5087352/pdf/sensors-16-01563.pdf

the authors there claimed that one can detect categories (outdoors,semi-outdoors,light indoors,deep-indoors) quite reliably. Deep indoors being more dangerous that outdoors.

If you would additionally broadcast your indoor/outdoor status, then we could also potentially filter out certain mismatches, e.g. when waiting on the street, in front of a place full of people inside (because the indoors/outdoors state should match for having close contact).

[carl-binding]

https://support.kontakt.io/hc/en-gb/articles/201621521-Transmission-power-Range-and-RSSI

continuous use of GPS is probably a no-go for reasons of power consumption and privacy.

Also note the default TX power. -12 dBm