I want to know in regards to iOS what is the typical advertising rate for peripherals running in the background. I know that it will vary depending on what you are doing in the foreground , but I do not know to what degree. I have read it changes only by 10's of ms but then i have also read it can change by up to 4 seconds between advertisement packets. I can fit all of my data needed into 1 packet. I would like to know between advertising this one packet in the background and nominal iphone usage how likely is it that my advertising rate will still be in the ms range?
Also i have read that i can change this interval programatically, but the examples are only for 30 seconds. (im guessing due to limited discoverability mode?) Is there a way I could keep recalling this advertising boost? OR Maybe I could start as a central scanning in the background instead and when i scan a certain packet i could switch to peripheral mode (since you can only do one or the other in the background) and my advertising boost could happen then. Then when that thirty second boost is over i could switch back to central mode until i scan that certain packet again right? This way i would only have a small window of poor advertising rate every 30 seconds. Is that probable?
Related
I am looking at speeding up the connection time between my iOS application and the peripheral.
I have looked up Apples Documentation on the subject: https://developer.apple.com/library/content/qa/qa1931/_index.html
Originally (prior to reading the doc above) I had the advertising interval set to 2 seconds to, what I had thought would be, a good compromise between power consumption and connection time. Having read the documentation further I have changed the interval to 1285 ms.
#define ADVERTISING_INTERVAL 2056 ble_obj.setAdvertisingInterval(ADVERTISING_INTERVAL);
The device is always discovered quickly by the app but the problem comes when trying to connect.
However, I have seen no increase in speed in connection time between my application and the peripheral device. Connections between the devices can take anything from 3-4 seconds up to 30+ seconds.
Is there something I am missing? Either on the peripheral or the central side?
Peripheral BT chip is the Nordic Semiconductor NRF51822.
On examining the devices advertisement packet on the Nordic Semiconductor app I can see that the advertisement interval normally varies from 1275 ms to about 1295 ms (as expected? due to the random time added to the advertisement packet)
NOTE
Have also tried with an advertising interval of 152.5 ms and am still not seeing any major improvement in connection speed. I am , obviously, seeing a marked improvement in speed of discovery
What you observe is normal. Don't expect fast connection setup with an advertising interval of more than a second.
Core Bluetooth uses a high duty scan window/interval for the initiation the first seconds. If it doesn't connect then it continues to scan with much more power restrictive parameters.
since Android 5.0 start to support the peripheral device which allow apps to broadcast advertisements. In my app case, I need broadcast every 20ms to 30ms,but I can't find anyway to change the advertising interval. And the default advertising interval is between 20ms to 600ms, which totally can't accept in my case.
You can't have control over the exact millisecond frequency, but you can experiment with using different settings from https://developer.android.com/reference/android/bluetooth/le/AdvertiseSettings.html such as https://developer.android.com/reference/android/bluetooth/le/AdvertiseSettings.html#ADVERTISE_MODE_LOW_LATENCY.
LOW_LATENCY is the best available that sends a packet about 100mS interval.
If you need a "fast" packet transfer, the workaround option is to create multiple advertisers. And if you create 5 such parallel advertisers, eventually it will reach at around 20-30 mS. Yes, it is possible, but remember, you are flooding the environment with a huge data with 5X times.
After spending hours around the web, I cannot find any documentation about the background BLE scanning rules used by IOS.
As it is not possible to set the scan window on IOS, I am looking for the rules defined by Apple when IOS is scanning in background.
Context
I am working on a wearable peripheral which can be disconnected sometimes when it is out of reach with the phone. The goal is to reconnect quickly (less than 5s) when the peripheral is close enough to the phone. The peripheral has battery constraints so I cannot advertise every 20ms forever, so I am looking for a clever way to reconnect my peripheral to the phone.
If I know how the background scanning mode is working, I would be able to define a smart advertising interval in order to save battery.
Use case
If my peripheral advertises every 1285ms, how long does it will take to be discovered by my IOS application in background mode for 10 minutes?
Not sure exactly what your question is.
I suppose you have read Apple's "Bluetooth Accessory Design Guidelines for Apple Products"?
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
In it, they state:
3.5 Advertising Interval
The advertising interval of the accessory should be carefully
considered, because it affects the time to discovery and connect
performance. For a battery-powered accessory, its battery resources
should also be considered.
To be discovered by the Apple product, the accessory should first use
the recommended advertising interval of 20 ms for at least 30 seconds.
If it is not discovered within the initial 30 seconds, Apple
recommends using one of the following longer intervals to increase
chances of discovery by the Apple product:
152.5 ms
211.25 ms
318.75 ms
417.5 ms
546.25 ms
760 ms
852.5 ms
1022.5 ms
1285 ms
Note: Longer advertising intervals usually result in longer discovery and connect times.
Upon discovering the BLE device, iOS will notify apps that are looking for it (based on the advertised service UUID), which will then be able to connect to it.
Apple recommend a 100 ms interval for iBeacons.
This (pretty old, from 2012) discussion states that:
the median discovery time when the phone is in standby is about 60
times the advertising interval. The 95-percentile discovery time when
the phone is in standby mode is about 300 times the advertising
interval
This (slightly more recent, but from Dec 2013) answer states that:
While scanning in the foreground will likely immediately discover a
device advertising next to it, discovery in the background can take up
to ~60 times longer.
There's a problem when (average) advertising interval is near to an integer multiple of the scan interval, then chances are that discovery-time can rise infinitely (, i.e. scanner will never see the advertising, as ADV always occurs outside the scan window).
Probably the ADV-interval list from Apple's design guideline shows optimum values, but it does not tell how to determine discovery-times. That's a mess!
I'd even go further and say: If the Smartphone (Apple or any other) manufacturer does not exactly specify the scan parameters (interval, window, and eventually filter settings) for each power mode, then you're lost and cannot correctly estimate discovery performance.
I want to build and app which can detect other iPhones with my app within 65 feet range. As I understand I have the following choices:
Use Bluetooth to check periodically whether there is device with my app in the range. Send list of found devices to the server. The problem here is battery consumption. Is it true that Bluetooth will be disabled after some period of time automatically?
Can I use BLE technology for this purpose? If so, do you know what devices support BLE?
What is the best option on your opinion? Did I miss some other option?
Thanks
UPDATE
I plan to run search every 20 seconds or even more often.
There is no simple answer to this problem.
Bluetooth has 2 flavors: "Regular" bluetooth, used for hands-free devices, headphones, and the like, and BLE (Bluetooth Low Energy)
Regular bluetooth devices must be paired. (I'm less familiar with regular bluetooth than BLE, so take my explanation of this bit with a grain of salt.) In order to be paired they have to be put into "discoverable" mode, which broadcasts their ID. That is a battery-draining and only done briefly. It's not an "always on" solution.
BLE has a range of up to 60 meters, so it should meet your need in that regard.
BLE devices can "advertise" as a "peripheral" for extended periods. Other Bluetooth devices can act as a "central" and ask to be notified when certain peripheral devices are detected. I'm not sure if you can make an iOS device advertise (broadcast) as a BLE peripheral while it's in the background and/or if the device is locked, but it will certainly advertise while it's running. I'm pretty sure you can register to be notified when you detect a certain BLE peripheral from the background, but not positive.
iBeacons are a specific use of BLE with some extra limitations and some extra abilities. An iBeacon is a dirt-simple transmitter that sends a UUID plus a major and minor value and a signal strength calibration value periodically (usually once a second.) You can't add any other data to an iBeacon transmission. iOS can only act as an iBeacon transmitter when the app is in the foreground. If your app moves to the background, it stops transmitting. Period.
However, you can listen for iBeacon signals even from the background. AND, if you've registered as a listener for an iBeacon and the system terminates your app due to low memory, the system still listens for those beacons on your behalf. If iOS detects a beacon you're listening for, you get re-launched if needed, and notified in the background. You can then post a local notification to get the user's attention.
iBeacons are probably your best bet, but you will need your users to be actively running your app in the foreground in order to transmit a signal. That will drain your user's battery fairly quickly.
One possible solution would to have have every single device send their locations to your server every predetermined time period (more frequent the better but more resource intensive). Then, query the data from the server and get the location of all the devices near you.
Keep in mind, that this probably won't be very useful for real-time data collection. For example, if you want to send data every 30 seconds or so, this isn't a good option.
Use this option if you want to get data every 15-20 minutes or so.
Apologise for the probably use of the wrong word in my question but for the life of me I can't think of the right one.
Anyway, I've been playing about with the Bluetooth Low Energy and I'm trying to create something that is going to use the RSSI signal strength the BLE device emits. For this, I need it to emit its pulse multiple times per second.
Is there a way I can up the amount of times my devices either scan for a signal, or broadcast their signal through code on iOS devices?
No, there is no API for you to change the advertisement speed or radio power.
This aspect is fully controlled by the system. You can only start and stop the advertisement and add some metadata to the packets: device local name, advertised services, etc. Moreover, the contents of the advertisement packets will differ depending on whether your app is in the background or foreground and, additionally, in background it will be slowed down. These effects have been documented in various SO questions and in the header files.
If your clients are iOS applications, then they should use either the RSSI in the advertisement packets (centralManager:didDiscoverPeripheral:advertisementData:RSSI: method) or when connected, the readRSSI method on the peripheral object (just make sure you don't call it too often).