I have an iBeacon device I'm working on and am wondering how often iOS monitors/checks/scans for iBeacons when asked to do so via a CoreLocation app? I'm wondering so I know how long to broadcast for my iBeacon is designed to not always be on.
I'm surprised I haven't been able to find this on the web (and of course Apple won't tell us)
Edit: I mean when the app itself is not running because the phone has been restart or the app is shut down.
There is no Apple documentation for this, but the following is what I have learned from lots of testing on iOS 7 and iOS 8 devices:
If the app gets one of the limited (30) bluetooth hardware detection slots, the Bluetooth chip will always be scanning for the beacon pattern. In theory one packet could trigger the detection, but in practice you may need several seconds of transmission to guarantee detection.
If the app does not get a hardware acceleration slot, the OS will perform a full scan every 15 minutes.
If you want to target phones that have hardware detection slots, the beacon could transmit for 5 seconds at any time appropriate for the use case. If you want to target apps without hardware acceleration slots, the beacon must transmit for 15 minutes to guarantee detection.
Related
I built a custom ARM device based on the nRF52 SOC that handles BLE 5. I wrote a custom app in SWIFT/X-Code/IB using Core Bluetooth framework and am unable to stream data from the ARM device any faster than about 12 kbs. Using packet sniffers I can see that the ARM device sent all of the packets in realtime, but the iPhone doesn't read them any faster than a few times per second. On rare occasion the iPhone reads everything quickly. The Bluetooth connection negotiates to a 12-24 ms latency. I am using Nordic nRF52 SDK version 16. The iPhone is not connected to any other BLE devices at the time.
Has anyone else had this issue? If it is helpful, I can post the code used on the ARM device and the XCode code.
As your using the nordic board there are several things to check to "speed up the process". Firstly I assume you are sending via notifications. Secondly you need to know what forms your data rate. They are:
Number of bits per notification
Connection interval
Events per connection interval
Data communication type
Also you can queue up-several packets to store until they are sent via the notification(filling a buffer).
So some useful settings. First and foremost maximise the data you are sending per packet. E.g if you are sending 10 bytes of data send more, this will be limited to the maximum data size on the nordic board (247). Then increase the GAP length. So some settings I recommend to start are:
Go to sdk_config.h
Change NRF_SDH_BLE_GAP_EVENT_LENGTH to 400(think the default is 6)
Increase the MTU size to 247
Then run on the board, you will probably get an error saying change ram and start location. This will be printed to a terminal. You can do this by going:
Project
Options
Common
Press up arrow till under project
Linker
Section placement macros.
From there change your ram start and allocation variables to what is printed in the terminal / putty / debugger. Also not sure about the APIs for iphone apps but android has a function to set the bluetooth hardware into high power mode, this increased my throughput whilst transferring data, just disable it after data transfer. The APIs your using may have a similar function.
For reference code there is an example called maximum_throughput in the sdk, this should be a good reference point.
I am working with ibeacon. I created an application for tracking devices. But I am facing a problem with the application. The app works well in the terminated state for iPhone SE whereas it is not working (in the locked state) for iPhone 7+.In the unlocked state it is working for 7+ also but still it is very slow compared to iPhone SE. Is there any specific reason for this problem. If it can be solved, what could be the possible solution to this problem.
I am really helpless and clueless about this issue.Please do help me and assist me with your knowledge Sir. Thank you in advance.
When an iOS app is in the background, it relies on two different mechanisms to detect beacons:
Hardware filters. These are byte patterns stored on the Bluetooth chip that alert the OS when a BLE advertising packet is received that matches your beacon region. This mechanism is very fast and delivers results within a second, but it is a limited resource. Once all slots are full, it will no longer work. There is no documentation about the number of slots available on each iPhone model, but experiments suggest the number is ~30.
Software scans. A full BLE scan is performed to find all beacons even if they are not stored in a hardware filter. In the foreground with ranging active, software scans are constant. In the background they are periodic to save battery, so detections based on software scans are much slower. The rate is undocumented, but experiments suggest software scans are performed every ~10 minutes in the background in the typical phone state. An additiona softwarel scan is also performed when the screen is unlocked.
The problem description is consistent with hardware filters (1) not working on the iPhone 7+. This may not be a problem with the phone model, it could be a problem with the specific device, or more likely the software state on the phone. A typical cause is the installation of multiple beacon apps that use up all the slots. Each beacon app can register up to 20 beacon regions for monitoring, so just two apps could use up all the slots!. The first apps to run and register slots may hold them forever.
A few troubleshooting tips:
Uninstall any other apps you think may. be detecting beacons, then re-install yours.
Restart your device.
If the above does not help, you may have a hardware problem with your device. Try another iPhone 7+ to see if you can reproduce.
I've a iOS 10 device in my work place and I got curious about it's bluetooth's weird behaviour. So.. I was playing around with my Android's Beacon simulator App and I noticed that every time I unlocked my IPhone and enabled the Bluetooth a new entry was immediately created in my android's near by beacon's list. Is there a reason for that?
UPDATE 1
- handoff disabled
- AirDrop disabled
- No open apps.
= still got a mysterious broadcast on my Beacon Simulator App.
UPDATE 2
Ok, I was digging into the subject and noticed that the iOS device is not being able to find near by devices in a standard bluetooth discovery.
In the other hand, near-by devices can detected the iPhone and when clicking on his entry in their result's list a popup for pairing shows up on Iphone's screen and as if it was magic the name of the device trying to pair shows up on the iphone's list that is always empty, in this case Huawei P9 but tested with a note 4.
I am the developer of Beacon Simulator. I just want to warn that the app is a Beacon simulator before all, not really a Beacon scanner. I added the scanning part because it was easier to do some tests, for the beacon copy feature and also for future developments.
What the scanner will show you is not necessarily a beacon, but any scannable Bluetooth Low Energy devices, connectable or not. Unfortunately, it is difficult to know if a device is connectable or not with the Android API, so the app lists everything.
Since the icon represents a standard Bluetooth logo, it means it is a signal not recognized by the app (here, it isn't an iBeacon nor AltBeacon nor Eddystone beacon). So either it is a non standard beacon, or simply a signal to advertise a possible connection to the device. When a connectable device broadcast its presence, the signal uses the same channel and protocol than the one used by beacons. A connectable device will advert itself as connectable, but as said, the Android API erase this difference, unfortunately.
So what you see is not necessarily a beacon, but maybe simply your iPhone broadcasting its presence as a connectable device. Maybe I should add some disclaimers in the app.
I'm using a nordic nrf51822 device and trying to communicate to it via an iOS app with BLE.
When the device sampling rate is set high - I'm able to read data at that frequency for about 5 to 7 seconds. After that time period, it samples at that frequency but doesn't update as often.
I tested the device with my app as well as the nordic tool-box HRM iOS app. It acts the same way in both the applications.
So my question is: Does this have to do anything with the CB framework or iOS environment?
or Does it have to do something with the sensor/device?
or Does connection interval in iOS BLE change by any chance?
We have an existing iPad app that we are adding iBeacon transmitting capabilities to. I am unable to transmit an iBeacon signal. I won't provide the code at this point because I've also tested the Apple AirLocate example and the Radius Networks Locate iB app as a transmitter and in both cases the iPad won't transmit a beacon.
We tested with iPhone 5 devices and they can both transmit and range beacons.
What could be the issue with our iPad test device that it won't transmit? It can range beacons from the iPhones just fine.
BT is enabled. Location Services are enabled and approved for the apps in question.
Two likely causes:
The Proximity UUID of the iBeacon transmitter is not configured with Locate for iBeacon or Air Locate. Locate cannot see new iBeacons with unknown Proximity UUIDs. Even if the configuration is off by only a single digit, the iBeacon will be invisible.
Many users have reported recently that their phones are getting into a state where they cannot see iBeacons, and a reboot solves the problem. See here for more details.
How do you detect the iBeacon, actually?
I once encountered the problem that CLLocationManager#startMonitoringForRegion: did require a certain period of time, until the regions were updated and a region was ranged. So CLLocationManager#requestStateForRegion:...
In either way. What I first did to validate that beacons were emitting/sending correctly (not receiving): I downloaded a common Bluetooth Scanning-App and checked, whether the App is able to range the emitted beacon. Could you verify this at first? Maybe the iPad Air is sending correctly, but the receives do not range the beacon yet.