We are reaching out to discuss an issue we have encountered with our app's activation process while running in the background. Currently, we are employing an iBeacon-based activation scheme, but we have noticed that after the app is activated, it is unable to receive UUID data from the scan-response while in the background. We are considering the possibility of embedding the UUID data into the advertisement so that the app can receive it once activated by the iBeacon. Additionally, we are preparing to use both Core Bluetooth’s “Performing Long-Term Actions in the Background” feature and the iBeacon scheme simultaneously for app activation. We would like to know if these two methods can coexist without any mutual interference. Currently, we are utilizing a method of updating the beacon advertisement after connection and disconnection to enhance the app's activation capability. However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated and will not be reactivated by the same beacon after going into sleep mode. Our current approach is to update the beacon advertisement every 10 seconds to improve this capability. We have outlined our proposed changes and would appreciate your confirmation on whether they could lead to better optimization:
1.Embedding the UUID from the scan-response into the advertisement. 2.Updating the iBeacon advertisement content every 10 seconds. 3. Simultaneously using Core Bluetooth's "Performing Long-Term Actions in the Background" feature along with the iBeacon scheme for app activation.
Additionally, we would like to know if these changes could potentially cause any other issues. Thank you for your assistance, and I look forward to your insights on this matter.
iBeacon is a specific protocol, and any kind of changes you try to make to it like you describe will make your device not compatible with the specifications, and may effect the performance of the iBeacon functionality using the Region Monitoring APIs. We have seen many solutions like you are considering with varying degrees of success - considering we become aware of those because we are asked questions when the solutions do not work.
Specifically:
1- iBeacon protocol dictates the advertisement is not scannable. So, you cannot expect the iBeacon scans by the system to read and process, let alone pass to your app the data in the scan response. There is also no way to add additional data than the beacon ID, major and minor IDs to the advertisement packet.
1a- even if your app is using GATT scans, when the app is in the background/the device screen is off, the device can switch to what we call a "passive scan" mode, where it will no longer send SCAN_REQ. So, if you have changing data in the SCAN_RSP, that may not be read, and would be ignored
2- iBeacon protocol is meant to be used for determining the proximity of a said iBeacon based on its ID. There will be various caching mechanisms that will recognize an iBeacon by it's Bluetooth address and it's ID, and by continually changing the ID, this can adversely effect the algorithms on the iOS side and this off-label use may or may not cause issues in your use case. This is not a supported use of iBeacons, and if it creates issues or simply not work, there is nothing we can do for you.
3- by this you mean have the same device send both GATT and iBeacon advertisements, whether by interlacing them, or by some sort of switching back and forth. This, also will cause issues with our caching algorithms if you are using the same Bluetooth address. For this to work at all, your Bluetooth accessory must use one of the following methods:
- change its Bluetooth address as well as the advertisement payload between GATT and iBeacon advertisements.
- use BLE 5 advertising sets and send each advertising on a different set
- use two separate radios
If you simply switch advertising patterns back and forth, this may effect the performance of both the iBeacon and the GATT scanning. And you are more likely to run into issues in the field than not.
Currently, we are utilizing a method of updating the beacon advertisement after connection and disconnection to enhance the app's activation capability. However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated and will not be reactivated by the same beacon after going into sleep mode.
This is simply inviting trouble. iBeacon protocol, by definition, is non-connectable. Any deviation from the specifications may adversely effect the performance of the entry/exit events from the iBeacon.
However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated
Part of iBeacon detection requires the signal to be steady for a while to avoid false positives, and also there is a built-in delay after signal loss to avoid false negatives. When the signal is weak, at the edge of detection, these conditions may not be getting satisfied to trigger an entry/exit event. Like I said, this is designed for the purpose of determining proximity to an iBeacon, and may not be suitable for an alternate use case.
and will not be reactivated by the same beacon after going into sleep mode. Our current approach is to update the beacon advertisement every 10 seconds to improve this capability.
This is likely because your scheme of changing IDs and advertisements is confusing our algorithms.
Each method, be it iBeacon or GATT (long term actions) have their limitations by design. I suspect you are trying to work around these limitations by using both techniques at the same time, which is more likely to use issues like you are seeing. My recommendation is to decide which technique is best suited for your use case, and make the best of it, and not try to patch the functionality of one to the other.
Argun Tekant / DTS Engineer / Core Technologies
