Re: Scanning for specific service IDs in the background
Re: Scanning for specific service IDs in the background
- Subject: Re: Scanning for specific service IDs in the background
- From: Andras Kovi <email@hidden>
- Date: Fri, 19 Oct 2012 22:53:23 +0200
Hi Zsombor,
I'm glad your case solved. Yes, the peripheral stops sending the advertisement data in background and thus, the central will not return it if it is filtering by services.
The rest is my thinking based on the observations:
1. The central caches the advertised peripheral without the services (since those are not listed in the packets). This means it assigns a UUID to it.
2. The peripheral comes back and starts advertising the services.
3. The central does not list the peripheral as it does not distinguish it from the already cached one, which it thinks does not fulfill the filtering criteria.
4. As a result, no callback is invoked on the central, and this is a problem.
Bottom line: I think the central evaluates the peripheral only once in a single scan "campaign". Therefore, if scanning is restarted, the peripheral will be reevaluated and changes in the advertised services will be sensed.
Solution:
1. the central needs to check if the advertisement changes over time
2. iOS devices in the peripheral role should keep on sending the advertisement packets
3. Scanning needs to be restarted every so often to fight this phenomenon. However, doing it from the background may be problematic.
PS: I guess the assumption on the central side, that the peripheral should be evaluated only once, is correct in any normal case. There aren't many accessories that could change services in a short time. However, the design decision that was made for the peripheral role in iOS straightly invalidates this condition.
Regards,
Andras
On 2012.10.19., at 21:40, Zsombor Papp <email@hidden> wrote:
> Hi Andras,
>
> I did see your message to Joakim. It seemed to me that you were describing a scenario that was different from mine, in that in your case the peripheral is in the background. Is that correct?
>
> My observation, and what's described in that stackoverflow post, was that the central running in the background won't discover the peripheral even if the peripheral advertises the service UUIDs.
>
> However, I just tried this again and now I do get the didDiscoverPeripheral message. Also, I tried the scenario I believe you are describing (start advertising on the peripheral, send it to the background, and then start scanning on the central), and that works, too. So maybe this is not broken per se, just unreliable...?
>
> By the way, I wasn't quite sure what you meant by this: "the peripheral will be found but callback not happens". How do you know without the callback that the peripheral was discovered?
>
> Thanks,
> Zsombor
>
>
> On 10/17/12 1:09 PM, Andras Kovi wrote:
>> Hi Zsombor,
>>
>> I described this issue a few weeks ago and haven't got any response yet. Here's my observation and I think you bumped in this issue:
>>
>>
>> Begin forwarded message:
>>
>>> On 2012.09.28., at 22:14, Andras Kovi <email@hidden> wrote:
>>>
>>>> Hi Joakim,
>>>>
>>>> I just helped debugging an issue for Frederic and found a really interesting behavior. Please confirm or correct me.
>>>>
>>>> Observation: if the app is sent to background, the advertising continues but the advertisement data is not sent in the packages
>>>>
>>>> Effect 1: Backgrounded apps cannot be discovered by clients that filter for services. When a client uses scanForPeripheralsWithServices, the peripheral will be found but callback not happens in the app as the service filtering criteria will not be satisfied
>>>>
>>>> Effect 2: Backgrounded apps will never be discovered by clients that started scanning while the app was in background. If a client starts scanning while the app is in the background, CoreBluetooth finds the peripheral but callback does not happen. Then when the app comes to foreground and advertisement data is sent again, CoreBluetooth will not invoke the callback as it thinks it already provided the callback for that. (Discovery may happen only when the BLE address is changed (every 15 minutes or so))
>>>>
>>>> I think this phenomenon can explain many recently reported issues too.
>>>>
>>>> Your help is much appreciated.
>>>>
>>>> Regards,
>>>> Andras
>>
>> On 2012.10.17., at 21:25, Zsombor Papp <email@hidden> wrote:
>>
>>> Hi,
>>>
>>> I am finding that if I invoke scanForPeripheralsWithServices with a nil parameter for services, it works fine in the background, but if I specify a service UUID then it won't discover the service. This same behavior is mentioned here:
>>>
>>> http://stackoverflow.com/questions/9896562/what-exactly-can-corebluetooth-applications-do-whilst-in-the-background
>>>
>>> although that post is more than 6 months old now and describes iOS 5.0.1 behavior. Can anyone confirm that the same behavior/limitation still applies to iOS6?
>>>
>>> Thanks,
>>> Zsombor
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Bluetooth-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden