iOS CoreBluetooth - Peripheral connect to Central within range - ios

I have a basic BLE App that I am running with Objective-C. I am using PeripheralManager and running my iPhone8 as a peripheral with serivces, characteristics added.
What I would like to do is connect to a central device that I know by Device ID or when it comes within range.
I have written a BLE App for Android that does this now. All I have to do is trigger the device.connectGatt() when onConnectionStateChange() is connected. This is in the BluetoothGattServerCallback() eventHandler.
What is the equivant for this in iOS? Keep in mind I that this is at connected state, not when the central has subscribed for services. This seems obvious in BluetoothGatt on Android but not see anything obvious in iOS PeriphalManager.
Anyone done anything similar? Seems to be a basic question, please help.

In CoreBluetooth it is the central that makes the connection.
If you know the device-specific identifier for a peripheral (ie, you have previously discovered it on this central device) then you can attempt to retrieve a CBPeripheral instance from the central and then issue a connect. This will complete when the device comes into range. If you allow background mode then this connect can be completed when your app is in the background.

Related

Bluetooth Background mode IOS

I was searching for my Bluetooth problem a few days but I did not find any useful solution. I would like reading advertising data more precisely manufacturing data from peripheral devices via ios application when it is in the background. In my case, the peripheral devices are Nordic nrf51822 chips and a central device is ios phone. I have successfully implemented the Bluetooth background mode and it works well on the ios device. The Event handler DiscoveredPeripheral is called when the new peripheral device is discovered. But the problem is that it is called only first-time the peripheral device becomes visible. If I turn off and on the peripheral device the DiscoverdPeripheral event is not called anymore. I know that this is ios restriction, but I do not know how can I handle this ios limitation. In the end, I would like that app in the background starts scanning for peripheral devices with specific UUID periodically, for example, every 10minutes. At this point, I would like to ask if this scenario is possible to implement in ios if so I appreciate for any help.
The Event handler DiscoveredPeripheral is called when the new peripheral device is discovered.
This isn't correct. It will only be called once per call to scanForPeripherals. When the device connects, you should stop scanning. When the device disconnects, which you should see as centralManager(_:didDisconnectPeripheral:error:), you can begin scanning again.
Even better, if you only want to reconnect to the same device, don't scan at all. Just call connect for that peripheral UUID. It will continue running while you're in the background and wake you up when the connect succeeds.
To push this further, implement Bluetooth State Restoration, which will allow you to automatically reconnect even after reboots.

Connect to a backgrounded iOS app acting as a peripheral from a macOS app

I have an iOS and macOS app that make heavy use of Core Bluetooth. The core functionality of the app involves having a central device (CBCentralManager) connect to a peripheral device (CBPeripheralManager), retrieve some data, then disconnect. Either device, whether macOS or iOS can act as either a central or peripheral depending on who needs the data.
At first I thought there was an issue with my code, but after testing the app with two iOS devices, one is able to connect and extract data from the peripheral device even when the peripheral device is locked and the app is in the background. Now according to the docs concerning background advertising on iOS under "The bluetooth-peripheral Background Execution Mode" this is kind of expected:
...they can be discovered only by an iOS device that is explicitly scanning for them.
Is there any way to have a macOS app discover peripherals even when they're backgrounded? I'm sure the code I've written is correct because it's the same across iOS and macOS.
Update 1
I believe that this might be possible just unsure how to approach the issue. Using Apple's Bluetooth Explorer on macOS, I am able to find the desired device AND I'm able to see and read data for my custom service.
This finding is validated from logs from my iOS device about the read requests which are from my peripheralManager(CBPeripheralManager, didReceiveRead: CBATTRequest).

Ios Application connected in Background with device

i have an application that is connected with a chip by bluetooth.
Device and phone are constantly connected to calculate the distance between them by bluetooth delay in reply.
App is working fine in foreground.
When i go background the app is still running, but cannot connect to the device.
I already tried to fix with this guide: Core Bluetooth Programming Guide
but i didnt made it.
Some suggestion?
You need to introduce more detail.
Your app will not run in background mode even bluetooth connection is on.
But your app still have a chance to execute some code in a short time if some bluetooth event happen.
Connection lost.
Notification received.
If your application work like anti-loss bluetooth tag, you need
Enable background in iOS app.
Write your code in core bluetooth delegate.
And One reminder: Calculate distance based on bluetooth relay is not smart. Bluetooth communication is not designed to support this kind of feature.
It work on license free 2.4G band and human body has big impact on it.

Why, sometimes, do I need to restart the iOS Bluetooth (using the system button) to make my central manager able to connect successfully?

I'm developing an application on iOS and OS X Yosemite which is using CoreBluetooth on iOS and IOBluetooth on Mac.
The iOS app plays the "central" role while the Mac app is playing the "peripheral" role.
Basically, the iOS app (the central) starts a scan to find peripherals and when it finds a Mac advertising peripherals data, the central connects to it and can discover its services and characteristics.
My problem is that sometimes, I don't know why, the iOS app starts a scan to find a Mac advertising and when it finds it (this step work all the time), it tries to connect to it but never succeed.
To make it able to connect successfully to the peripheral again, I need to turn off and then turn on the Bluetooth from the iOS button.
Another strange thing is : imagine the central is in the same situation (trying to connect with no success). On OS X if I click on the Network icon (with the Wifi symbol) in the system status bar, then it will display the list of all available Wifi networks, and when it adds to the list my iPhone as a "Personal hotspot", at this time the central (which is on the iPhone) manages to connect to the peripheral (the Mac).
With this problem, the app usage is a lot compromised because randomly the iPhone will not be able to connect to the Mac.
I spent a lot of days on the internet (Google, Stackoverflow, ...) to find similar cases. I read a lot of articles and tried a lot of things like stopping the scan and starting it again if the connection didn't succeed after 10 seconds for example.
Don't hesitate to tell me if my question is not clear. I will update it if needed.
Thanks a lot in advance for your help.
I really need to find a way to fix this.
I don't have an answer (and not enough rep to comment) but I have been experiencing a very similar problem for months now. My iOS app which is playing the central role sometimes fails to discover services on the peripheral (linux) which can only be fixed by power cycling the bluetooth radio on my iOS device via settings/bluetooth. After bouncing the bluetooth radio, peripheral discovery appears to works perfectly.
I've found two reproducible cases: (1) If on my peripheral I completely swap out the service being advertised (i.e. change the service UUID and all characteristics) then the iOS peripheral will detect the peripheral with this new service during the scan, but service discovery fails. I find that peripheral:didDiscoverServices gets invoked, but the list of services is empty for this peripheral. (2) If on my peripheral, I modify the list of characteristics in any way (add a new one, remove one) the iOS app does not notice this change at all. During characteristics discovery, the same list of characteristics (prior to modification) is presented. Again, power-cycling the bluetooth radio on the iOS device appears to be the only thing that fixes this.
It appears as though iOS is caching BTLE peripheral services and characteristics upon discovering a new peripheral and the only way to flush this cache is to power cycle the bluetooth radio.

Core Bluetooth unable to discover peripheral

I am working with hardware that is in the process of being developed. The board uses a TI CC2541 as the bluetooth chip.
Prior to a test the board is discoverable by two devices and I am able to connect to the board and perform a test where I write and read characteristics (GATT). I perform the test again, everything goes fine until I reconnect to the device and attempt to discover its services. At that point, the board is offline and neither lightblue nor my own app can detect the device. I did a factory reset on one of the iOS devices (iPads) and it is still unable to recognize the board.
Should a factory reset remove all corebluetooth caching that has happened on the device, allowing iOS to re-cache and rediscover the board?
Can this possibly be a corebluetooth problem or a problem with my app?
Your problem seems to be related to the external peripheral. Factory reset will remove any cached data from the iOS device so as long as the peripheral behaves correctly, the rediscovery should happen as planned. This is all I can tell from the info you shared.
This issue seems to be related to hanging / adding characteristics on a peripheral during development.
I have had a similar issue and instead of clearing the cache on the iOS device, I change the Bluetooth address of the peripheral. This allows the discovery to work as expected.

Resources