Kind BLE experts,
Here's some background that you might find interesting. I'm working with a consortium of International teams working on creating IOS and Android apps for Contact Tracing for fighting the spread of COVID-19.
Lots of efforts worldwide on this problem. FYI, here are two that are collaborating with each other, with which I'm working and which have quite a bit of traction:
- Large, well-organized effort, centered around Stanford: https://covid-watch.org
- Deep technical team, lots of work on cloud-based backend and crypto, etc., techniques for preserving privacy: https://www.coepi.org
In my particular case, I'm focusing on BLE techniques for sensing physical proximity between two smartphone users and communicating as unobtrusively as possible. Both the Android OS and iOS present problems in achieving this, especially if the tracking app is in background mode. The minimal communication requirement between phones is the sharing of a 128-bit (16B) token, determined by the app. It would be ideal if this could be achieved using just Advertising Packets(AP). The currently developed apps have to use a combination of just scanning for APs and establishing full connections.
I'm hopeful that we can improve this situation by using an Advertising/Scanning/Scan-Request/Scan-Response sequence, especially in the problematic case of iOS apps running in the background. The relevant Apple Core Bluetooth documentation on Background BLE processing is somewhat ambiguous, especially about how much control the app has over the specifying the app (as a peripheral) has over the contents of the AP. It offers the tantalizing hint of a special “overflow” area, which might be accessible to the scanning central by issuing a scan request. That, at least, is the hope.
Since the open Apple documentation on this subject is not definitive, I propose to test iOS's behavior with the following test setup:
- An iPhone running iOS 13.4 and an app acting as a peripheral, emitting Advertising Packets with a specific 16-bit Service UUID, and running in background mode. (Already have this.).
- A Nordic nRF52-DK running a modified sample app as a central, scanning for APs with the specified UUID, which can:
- Send a Scan Request in response,
- Receive a subsequent Scan Response from the iPhone and report the results (e.g., via serial over USB)
- Another Nordic board setup as an nrf Sniffer with Wireshark to document the actual bits in all packets.
So, to avoid reinventing the wheel, my specific request here is for code for a Nordic nRF52 app (SES preferred) that accomplishes #2 (or a starting point for it). Failing that, I'll start with the standard Nordic SDK BLE central-UART example and proceed from there.
Requests for additional expertise and help:
On a more general note, our team would appreciate participation from individuals who have practical experience on either iOS or Android BLE background processing, and in what you can pack into an Advertising Packet in those environments. There are also sub-teams working on practical techniques to use BLE signal strength, etc., to determine distance between phones. If you're interested, let me know.
Mike
PS: Haven't
