Cwa-documentation: Is it possible to manually initiate a scan?

[rmetzler]

Your Question

• Documentation File: https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md#limitations Figure 13
• Question:

The listen window of 2s seems to be very short and spaced far apart so that not every encounter is registered.

From personal experience where people cough or sneeze while passing on the street, something like this is impossible to dodge. In a case like this it might be interesting to be able to initiate a scan manually. Would this be technical possible or is this something Google and Apple don't allow through their APIs?

The last paragraph sounds like you consider events like these corner cases, but from personal experience these happen often enough. Especially since you would try to not be in the same room as someone coughing.

[MikeJayDee]

The Google/Apple documentation of the framework state that scans should be done opportunistically (presumably when BT is receiving anyway), but at least every 5 minutes: "The scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 minutes. "

This suggests that you may be able to trigger a scan by starting a Bluetooth scan as if trying to add a new device.

I also wonder whether the scan happens (much) more often than every 5 minutes when using a BT peripheral such as a smartwatch or headset.

Those questions need to be addressed to Google and Apple, though.

[tklingbeil]

So far, the API does not allow to trigger scans manually. The app does not even get any information when/how a scan was performed or how many other devices have been detected. That all stays hidden to the app within the framework.

But as you can see, this is definitely something we have on our radar.

[kbobrowski]

That's an interesting problem, I was also concerned that scanning is running only for 2-4s and only every couple of minutes. Run some experiments and just putting phone in the back pocket increases distance 10-fold:
https://www.youtube.com/watch?v=SAi24ctpyZQ

this did not bother me too much since in a longer encounter someone will always change position, check something on the phone etc., but if the scanning window is so short we might not be registering contact events properly. The solution architecture document states that:

The duration and interval of scanning needs to be balanced by Apple and Google against battery life, as more frequent scanning consumes more energy.

Is this the only reason for such a short scanning window? I'd be happy to scan much longer and just charge phone often, perhaps it's possible to ask Google to include a feature which would allow user to increase scanning window on the expense of battery life?

[mh-]

Yes I think that’s the only reason - battery power.

I also did some experiments, using Raspberry Pis (https://github.com/mh-/exposure-notification-ble-python). Orientation of the antennas changes the RSSI a lot, so I would try to at least scan each beacon multiple times and use the maximum RSSI.
Another improvement, especially when scanning for longer durations, would be to not stop advertising while scanning, but let the BLE stack interleave RX and TX.

But I believe that Apple and Google are also still working on this, trying to improve it.

[tkowark]

As @tklingbeil answered the initial question, I hope it's ok to close this issue for now. If that possibility becomes available, we're happy to reopen the discussion regarding how to best make use of it.