search

corona-warn-app / cwa-wishlist

Central repository to collect community feature requests and improvements. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
105 stars 14 forks source link

Display currently received beacons with distance #19

Open BudickDa opened 4 years ago

BudickDa commented 4 years ago

Suggested Enhancement

Implement a debug view that shows the user's ID and a list of IDs and distances of the beacons nearby.

Expected Benefits

According to this issue and also my measurements the measured distance varies a lot from the real distance. Having feedback on their own devices accuracy would empower users to make up their mind about this app. Also it would provide important feedback about the accuracy of this app under real world circumstances.

Proposed solution for false distance

If necessary another feature could be implemented, where additional data (e.g. rotation, which bt antenna) could be used to calibrate the sensor (logic of the distance measurement). Calibrating the sensor could be even done by the users themself, by having a fixed distance to another device and rotation their device. A neural network could be trained on the device with the signal and rotation as features and the real world distance as label. The problem: Not everyone has a second device, but according to Frau Bär those people are lazy and can totally afford a new one.

Internal Tracking ID: EXPOSUREAPP-2175

tklingbeil commented 4 years ago

Thank you for your comment!

TL;DR: There is currently no possibility for live debugging the correlation between attenuation and distance, because the data can't be accessed.

The kind of data required for this, is not provided to us by the API. The received Rolling Proximity Identifiers are kept within the Exposure Notification Framework by Apple and Google.

In addition to that, the attenuation can only be calculated, if transmission power (specified by the sending device) and received signal strength (determined by the receiving device) are known. The transmission power is stored within the Associated Encrypted Metadata of the BLE Advertisement. For the decryption (by the framework), the AEM Key is required. This can only be derived from the Diagnosis Key, which is only available, once other users have submitted theirs to the server (because they have been tested positive).

w-flo commented 4 years ago

There are apps available in Google Play store to scan for BLE devices, and track RSSI. So I'm not sure if that feature alone would be very useful for the CWA.

Personally I'd love to be able to calibrate the RSSI<->meters mapping. I'm not sure which of the 2 devices I have access to is at fault, but I can hardly get RSSI "closer" / greater than -80 on my phone, even when there's only ~50cm between both devices (holding my device in my hand, other device in pocket). It only ever dips into the -70 to -80 range when it's really close to the pocket. I guess you get what you pay for when it comes to bluetooth hardware and firmware.

So I guess in my case, the app is only useful to warn others if I become infected, unless I can change it to register anything that crosses -90 or even -95 as a close contact. The -73 threshold is almost impossible to cross for me.

I know this is not something that can be implemented in the CWA right now, but maybe Google could come up with something that improves the situation in the Exposure Notification API.

tkowark commented 4 years ago

While currently not possible, this idea might deserve more discussion from a wider audience in the wishlist repository.

tklingbeil commented 4 years ago

That's a big misunderstanding. RSSI and attenuation are two different things!

You should look at it from another perspective: The transmission power varies (partly very much) from device to device. But the devices know their own transmission power, encrypt it and add it to the AEM (as described above).

So it is incorrect to just look at the RSSI with the tools you mentioned - you are missing the transmission power to be able to compare values.

If you would compare the attenuations (which is not possible due to TX power being encrypted), you would probably get values that are very close to each other.

yanosz commented 4 years ago

Distance estimation based on path loss models is error prone. It cannot take various environments into account (reflection, human body shilding, etc.). IMHO it makes hardly any sense to discard contacts due to low RSSI values. The distance of a BLE beacon is either "1" if you got one, or "0" if you don't get it. There's hardly anything in between, especially not in meters.

C.f. peridic deep fades in http://morse.colorado.edu/~tlen5510/text/classwebch3.html#x11-560093, for instance.