Radio distance is not spatial distance

[sebastianbuettrich]

Bluetooth distance is radio signal distance -
not identical or even directly relatable to spatial distance
(which in turn is not identical or directly relatable to infection distance).

Bluetooth signals are not suitable for distance measurement.

Consequently, BLE beacons and such do not output distances
(other then rough classifications, "near", "medium", "far").

This fundamental fact has implications on many levels, e.g.

1/ creation of false positives and negatives
-- "two people hug over a metal fence" - negative
-- "two people close, phones in well filled backpacks" - negative
-- "two people distant to each other in front of strong reflection surface" - positive
-- "two people really close but protected by plexi glass shield" (standard shop situation) - positive

2/ error source in areas of high beacon density

3/ opening of attack surfaces
-- assuming prank or hostile motivation, easy to "infection trigger" large groups of people by simple use of strong antennas or super beacons

While this is a well known fact and generally acceptable in systems merely interested in statistics
(e.g. airport queues, shopping center heat maps),
this poses a different challenge when the system seeks to identify and classify individual events.
The "just good enough" of airports and supermarkets is not "good enough" here.
At the very least, the occurrence of false events and its implications needs to be modeled.

(Note: despite Github's note "Similar to existing issues", it is not.)

[gagarine]

This problem is perhaps minimized in two ways:

• social distancing and hygiene measure still apply, nobody should hug.
• the supposition than contact intensity matter. Passing by a person in an outdoor environment is certainly very low risk. Spending some time in a close environment is certainly much riskier.

=> the detection could be more reliable the more you spend time in relatively close proximity.

[cascremers]

Ultimately, one would like to detect potential infections. As you point out, this does not correspond exactly to physical distance either, and depends on many local factors. The design is a complex trade-off between privacy concerns, technical feasibility, simplicity, and many more aspects.

[koenvervloesem]

With regards to the Bluetooth distance calculations, the OpenTrace project has just published its OpenTrace Calibration repository which gives an interesting insight in their methodologies and a table of some devices with their average RSSI levels for a distance of 2 meters.

[sebastianbuettrich]

That s great work, and greater as its shared openly -
however, i wonder if it can address the central issue.

The description of method states correctly that
"RSSI value exhibits significant variation"
and just one of the reasons is differences between devices and OSs,
which are then examined in detail.

you see the essence of the problem in

https://raw.githubusercontent.com/opentrace-community/opentrace-calibration/master/src/images/meeting_results.png

where you see 11 people - and out of these, 4 false positives, 1 false negative.

one may then react by moving measurements into "a more controlled environment" -
however, this is exactly what the real life situation is not.

Professionals in indoor and outdoor tracking have worked with this for years if not decades,
and our lab has had many students battle with this too -
and yes, you can calibrate in somewhat controlled environments -
e.g. one office building, one supermarket, - but each one of these
will be different from others.

i find it entirely possible that one might come to a compromise / least requirement that works somewhat -
but it will be a lot of work.

https://raw.githubusercontent.com/opentrace-community/opentrace-calibration/master/src/images/raw_rssi_chart.png
you see error spans of 5-10 dB -
the graph you would want to add here is those
5 - 10 dB translated into distance.

while i have been writing this, i was constantly shown to be bluetooth-"close" to two devices -
both of these are in a next floor apartment.

[lbarman]

Hi all, thanks for your inputs. @sebastianbuettrich we are aware of the concerns that you are raising. Given that you mentioned some lab experience, do you have any insight to share? It is clear that we need "a lot of work" but if we collect good feedback from the community then we can significantly reduce the amount of useless work and focus on useful work.
If so, I'll put you in contact with the right people.
Thanks !

[DaveMath]

Radio distance RSSI can be measured over time to assume spatial distance. We also have a payload path built for “I see you as X, what do you see me at?” Which can be used to blend the values and infer more details. This distance will be muddled by phones in rear pockets when you are facing someone of if there is metal like a counter top or refrigeration unit in the room. Our NewAer system polls nearby BLE over time to average it, to prevent this spiked high or low data.

…

On Tue, Apr 14, 2020 at 9:32 AM Ludovic Barman ***@***.***> wrote: Hi all, thanks for your inputs. @sebastianbuettrich <https://github.com/sebastianbuettrich> we are aware of the concerns that you are raising. Given that you mentioned some lab experience, do you have any insight to share? It is clear that we need "a lot of work" but if we collect good feedback from the community then we can significantly reduce the amount of useless work and focus on useful work. If so, I'll put you in contact with the right people. Thanks ! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDRZCLF5LYDH5HNNDGLUU3RMRXWTANCNFSM4MBDA6FQ> .

[lbarman]

Thanks, forwarded to the relevant team.

[sebastianbuettrich]

ok - comments did not address the issue, but i see it's closed.
you are welcome to put me in touch with relevant team.

[lbarman]

Sorry I mixed you and @DaveMath ! Same goes for you of course: issue is not solved and is currently tackled by the relevant team, if you have specific comments do not hesitate :)

[sebastianbuettrich]

_

Sorry I mixed you and @DaveMath ! Same goes for you of course: issue is not solved and is currently tackled by the relevant team, if you have specific comments do not hesitate :)

_

/ok, sorry i couldnt respond within < 20 hrs -
working at a university lab in IoT, wireless, incl all the things discussed here, so i m fairly busy ;) -
i ll throw my quick unpolished notes here - pls feel free to forward or delete as appropriate. aware this thread should go silent now.)

@DaveMath - "Radio distance RSSI can be measured over time to assume spatial distance.
We also have a payload path built for “I see you as X, what do you see me
at?” Which can be used to blend the values and infer more details."

Certainly with all respect for your work, and that of others, but imho,
neither one addresses the issue.
The issue is not statistical (or device) fluctuations over time
(which are significant, but solvable) ,
nor is it asymmetry of links.
The issue is real differences in radio path,
real physics underneath

Certainly, you can model specific situations -
and there is ample research in doing just that -
modeling e.g. an office space, a university building, a supermarket, or the scenarios you describe -
phone in pocket, phone through metal counter.
Certainly you can work with beacon environments and the likes.

However, it is in the nature of the project we are talking about
that you have none of these -
there are no controlled/stable/known environments, no references.
The task at hand is fundamentally different from location tracking.

Let me illustrate with two fairly common scenarios:

A cafe, a group of people occupying tables by the windows inside (Group I),
another group occupying the corresponding tables outside the window (Group O).
Group I and O will be shown as being in close proximity,
despite being well divided by a window pane.

At home, user with phone on desk
constantly showing good connection to another device -
which in fact is in an apartment next door,
or apartment one floor up/down.