Question is as title describes.
I have two apps, one CBPeripheralDelegate and one CBCentralManagerDelegate. The peripheral advertises when it is in the foreground (I think, I have no other BTLE devices to test it), but if I run the Central app in the foreground on the phone and the peripheral in the background, neither seems to see the other.
I have enabled UIBackgroundModes:bluetooth-peripheral in the peripherals info.plist as per the documentation for CoreBluetooth background execution.
I've found a few people trying to advertise in the background on here, but none to an app on the same device.
Let's say for the sake of my question that my code works perfectly... Can the bluetooth signal be 'looped' back into the same iPhone?
In short, no it cannot.
Although two different apps may be advertising and searching for their own services, at the end of the day they are still accessing the same chipset. Apple just masks away all the gritty details to streamline bluetooth dev.
Browse around the following link, if you want to break into some of the more underlying details involving Bluetooth Core System Architecture
Related
I have a BLE peripheral running on Raspberry Pi with gobbledegook.
In parallel, I have an iOS app working as BLE central which does a scanForPeripheralsWithServices with nil in order to detect all the devices around.
I'm able to detect a few devices, but not the one running on Raspberry Pi.
However, when scanning with the nRF Connect app on iOS, I'm able to see it.
How is that possible? (I assume that nRF Connect is also using Core Bluetooth...)
You're likely doing something (such as using the nRF Connect app) to connect to the device, causing it to stop advertising. Most BLE platforms stop advertising when they are connected to.
Use retrieveConnectedPeripherals(withServices:) to detect devices that are already connected. You must provide a list of services; there is no way to detect all devices currently connected.
Since this is on a Pi, you can also verify on that side whether the system is really currently advertising and whether it has any connections. Core Bluetooth does extensive caching, which can lead to things appearing to be happen that actually are coming out of cache. I haven't recently dug into the nRF app to verify how much it relies on the cache. I recommend also testing with LightBlue, and testing with multiple devices simultaneously (I typically use multiple apps on iOS, Android, and Mac, and occasionally an Ubertooth, to verify what I'm seeing is true).
Note also that once you've seen an advertisement from a device once, you won't see any more during that scan unless you set CBCentralManagerScanOptionAllowDuplicatesKey to true in you scan options. That flag is ignored in the background. This probably isn't the issue in this case, but often trips people up who are used to other platforms. Similarly it is almost always faster and more reliable to scan for specific services rather than nil unless you're building a generic BLE scanner. (Again, I doubt that's the problem in this case.)
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.
First: I have an iPad Air 2, and an iPhone 7. For further reading we estimate that the app is active and open on iPad and in background mode on iPhone. The app is exactly the same, even with same Bluetooth Service UUIDs and same DataLocalNameKey.
I want to write an app that can advertise a bluetooth service in background and is able to discover this service (optimal in background too). As I already read I can't use apples beacon technology cause there it's only possible to get scanning/notified by beacons in near in background (I tested this, works fine) but not to advertise. So I started to use CoreBluetooth as described in the mentioned SO answer cause there it's possible to advertise in background.
My app calls didDiscoverPeripheral method in CBCentralManagerDelegate on the iPhone (app in background), so it detected the iPad. The isAdvertising property of CBPeripheralManager on iPhone is true. But didDiscoverPeripheral is not called on iPad. I'm a little bit confused. One option is my iPad is not able to detect the iPhone anymore for some reasons or my iPhone is lying and it's not advertising.
So i thought I'm just a little bit of dumb and googled for "CoreBluetooth debug apps". I found Vicinity and AltBeacon. And with both apps the behavior is the same! If you background (press home/sleep button) the advertising app, the browsing app is not able to discover it anymore. If you open the backgrounded the app it will instant discover it. Both apps mention that its possible with them to broadcast in background.
Am I doing something wrong; is this behavior expected? Did I misunderstood the framework? Can you confirm this behavior?
To confirm this, the fastest way is to install Vicinity on two devices (you have to add the NSBluetoothPeripheralUsageDescription key to Info.plist) set one device to broadcast and press the home button.
This isn't anything specific to iOS 10 -- it's always been this way on iOS. On iOS, apps simply cannot send out standard Bluetooth LE advertisements when they are in the background. They have to be in the foreground to do this.
That said, there is limited support in iOS for apps advertising GATT Services in the background. This uses a proprietary technique that only works with other iOS devices that are looking for those services. (Because it uses a non-standard proprietary scheme, the same technique won't work for beacon advertisements, for example.)
Here's how Apple describes it:
...you should be aware that advertising while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is advertising while in the background:
The CBAdvertisementDataLocalNameKey advertisement key is ignored, and the local name of peripheral is not advertised.
All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
If all apps that are advertising are in the background, the frequency at which your peripheral device sends advertising packets may decrease.
Read more here: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html
it was a bug in ios 10.0.(1) and partially fixed in ios 10.1
src: https://forums.developer.apple.com/thread/51309
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.
I understand that the iOS App "PKPKT" is using BLE (Bluetooth Low Enery). But what I am curious about it is, is it purely using BLE only? Or does it switching between BLE and Classic Bluetooth?
I tested with a iPhone 5 and a iPhone 5s with both installed the app. I turned on bluetooth on both devices. And then i checked the "DEVICES" list to see if the other iPhone is paired with one another, I found that they are not. Until i launched the PKPKT on one of the device, and the i check the "DEVICE" list again, now they are paired and connected. So, i'm thinking is this pairing done by the BLE pairing? Meaning one of "Just works", "Out of Band", or "Passkey entry" methods.
There is also a "Chat" functionality in that app. This make me curious if the chatting function using BLE or Classic Bluetooth?
So my question is actually "Is switching between BLE and Classic bluetooth possible?". This is part of the study on this BLE technology. Hopefully someone could help me and other newbie on this new technology.
Thanks in advance!
I wrote PKPKT. I only use BLE. No classic. iBeacon is cool but doesn't have the background scanning needed to discover other players. I use game center, but only for scores, no sessions. It's optional in the app to enable game center (those banners can be distracting!)
The chat is also over BLE.
Because the connections are not encrypted, you don't need to manually pair the devices, and "just works"
I think you might find this link helpful. It implements something that looks to be a simpler version of PKPKT. I believe the app uses a combination of GameKit/iBeacon. The app requires iOS7.0+ and states, "PKPKT does the hard work of finding other players by detecting them using Bluetooth Low Energy (BLE) in the background." iBeacon would be the most battery-efficient way of accomplishing this and is a new feature in iOS 7. There is a wealth of information online(particularly on SO) about peer to peer bluetooth gaming using GameKit, if you are interested.
We can't say for sure unless the developer lets us know. If one were to attempt to recreate the application, GameKit and iBeacon would be the technologies that I believe most would recommend.
You might find this project helpful as an overview of how to use Bluetooth LE to communicate between two devices. You don't need to pair the devices, and unlike iBeacons, it works when the app is in the background.
SimpleShare - Easy Proximity-based Sharing for iOS
You can use the delegate methods of the SimpleShare project to easily share arrays of strings between nearby users running your app, such as user IDs, which you could then use to get more info, photos, etc, about that user from a web service.