Re: A Few iOS Peripheral Advertising Rate Questions
Re: A Few iOS Peripheral Advertising Rate Questions
- Subject: Re: A Few iOS Peripheral Advertising Rate Questions
- From: Etan Kissling <email@hidden>
- Date: Fri, 18 Jan 2013 10:24:59 +0000
- Thread-topic: A Few iOS Peripheral Advertising Rate Questions
Steve,
what you observe is a concept called "Limited Discoverable Mode".
(see Bluetooth Core Spec V4.0 Vol 3 Part C 9.2.3).
What happens is that a different flag is set in the advertising packets, telling that
the peripheral has been recently switched on, or that a user action happened (like
pressing a connect button). Normally, you may scan only for packets with that flag
set, or at least examine the flags to put such peripherals on the top of a peripheral
picker view because it is likely that a user wants to connect to a device with which
he/she has recently interacted. This is not possible using CoreBluetooth, though.
Another aspect of "limited discoverable mode" is that advertisements are sent
with a high frequency. Note that connections can only be established in response
to an advertisement. Therefore, this helps in reducing the latency required to connect
to the peripheral.
This mode comes with the downside that the advertising channels are flooded, and
that power consumption is increased. Therefore, one common practice is to limit
such high-frequency advertisements to a certain time span - typically around 30 seconds.
After this time, the advertising frequency is slowed down. This matches your observations
about the advertising rate ramping down over time. On iOS, you cannot modify the
advertising interval with the available public APIs. I have not tested it but it may be
worth a try to call the startAdvertising method an additional time if you want to switch
back to the "Limited Discoverable Mode".
While in background, you notice that the advertising rate is inconsistent. On iOS
devices, the radio that is used by BLE is also shared with classic BT and WiFi. Also,
since the app is backgrounded, it's considered to be less important. The Bluetooth
Spec defines that the advertising rate can be varied depending on other connections
that have to be maintained - so it's no bug here either :-)
Regarding your third question: can't tell, but feel free to share your results.
Etan
On 17.01.2013, at 20:58, Steve Jabs <email@hidden>
wrote:
> Hi All,
>
> I'm currently developing an application where the iOS device is in a peripheral mode. So far everything has been pretty straight forward. I have it running fine in the foreground and background. However, I've noticed a few issues that I wanted to bring up and see if there was anyone who may be able to shed some light on them:
>
> 1.) In the foreground, my app acting as the peripheral advertises extremely fast on startup. This is great, but it seems that after a little bit those advertisements tend to slow down (even while still in the foreground). Should I make the assumption that iOS ramps the advertisement rate up and down? If so, is there a set amount of time that an app will advertise at it's max rate before ramping down? Can I set this without being connected to a central?
>
> 2.) In the background the app immediately goes to a slower advertising rate. However, it's extremely inconsistent. While the majority of advertisements are sent out at what seems to be a second or less there are a few that can take up to 3 or 4 seconds to advertise. Can I assume, like the first question that the advertising rate varies as it's controlled by iOS?
>
> 3.) How long can I expect my device to advertise in the background under normal usage? Right now, we've exceeded 3 hours advertising in the background with nothing else running. I'm curious if anyone has done tests that have exceded 24 hours in the background with normal usage. Our use case will likely be 12 or less hours in the background.
>
> (In all situations this was performed on a latest generation iPod Touch running iOS 6 and not connected to a central)
>
> Thanks everyone,
>
> Steve Jablonski
> _______________________________________________
> 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