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 <stevejabs@gmail.com> 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 (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/kissling%40oberon.ch
This email sent to kissling@oberon.ch
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com