I am writing a Core Bluetooth App for IOS. It is connecting to a TI device With custom firmware. The firmware developer developed it to publish data 12 times a second. I am using the Notify Property to get the data, but it seems that we are grabbing the data 30 times per second. This is causing extra power consumption, and for specific reasons, I can't pull at my own rate I need to pull at the rate of the device is publishing.
The firmware developer created a Windows Application that doesn't have this problem without having a hard coded Read Rate. So it is On me to find the issue.
Does anyone have any recommendations?
For what you are describing, on your system the Swift side is just receiving notifications, so there is no control over the rate that your device is using to update that specific characteristic.
But, some devices may have a command on their own high level protocol to set the advertising interval. That's completely up to the manufacturer. If you think that the system is advertising at a different rate with that Windows app that you have mentioned, I would suggest to take a look to see if there is any initialization code that the app may be doing when it starts (thus setting the rate). But for that you will need the Windows app's source code, or at least the manufacturer's documentation about your device's protocol (if any).
Also, are you really sure that the updating rate when the device is connected to the Windows app is really lower than the one you are experimenting when connected your iOS app? How are you measuring that?
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 have a bluetooth device which connects to my iphone and i can perform all sorts of operations on the device. Its a tracking device and I log all sensor based data in the device. Since the device have a data limit, I want to read data from the device once every hour and dump it into a file through the app.
Now I have gone through all the documentation from Apple and other medium blogs and stack overflow questions, but I didnt find the correct solution on how to run a process in background. Also it has to be periodic. I need something that will trigger my code once every hour and I can connect to the bluetooth device and download the data.
I know for security reasons and for extended battery life apple doesnt support running background process infinitely. But I have to solve this problem.
I have created an iOS app that interacts with a bootloader on some custom hardware/firmware to update the application on the hardware. In order to accomplish this, the hardware/firmware has a bootloader application and a regular application. First, I connect my iOS app to the bootloader application and update the regular application. At which point the regular application starts to run and I would like to connect to it with my iOS app.
If I search for peripherals with an Android application it correctly sees my hardware broadcasting as the bootloader application and then switch to broadcasting as the regular application after the update has been completed. However, for some reason, the equivalent iOS app only sees it being broadcast as the bootloader application. I have found that if I restart the iOS device or if I turn the iOS device's bluetooth off and back on after a few seconds it will finally recognize that the regular application is broadcasting.
It seems as though the iOS device is caching the peripheral information. Does anyone know if there is a way to clear the cache or refresh to get the current/valid status of the device?
I have exactly the same issue here, unfortunately this is indeed due to iOS. There are a lot of other threads about this topic but after looking for a while I would recommend this answer :
https://stackoverflow.com/a/25930825
Best of luck, I haven't finished yet and this won't be easy...
I am having an issue concerning Bluetooth Low Energy. I am using an iPhone (iOS 6.1) and an Nordic board using the nRF51822 chip.
I am currently developing a system where the iPhone and the nRF51822 connect using certain services, then disconnect and reconnect again. However, on the second connection, the nRF51822 uses different services from the first connection.
The problem is that on the second connection, the iPhone discovers the former services of the first connection. I have tested with a TI CC2540 development board and it discovers the new services well. The only solution I have found is to put the central manager to nil and allocate it again to make it work. Nevertheless, it seems kind of a dirty solution, is there a standard (clean) way to deal with this kind of situation?
If you don't do any bonding, but only pairing, then you would not have this issue.
If you do require bonding, then the best way to solve this problem is to use the Bond-manager that is in the SDK. If you are not using the bond manager, you could try to use the Service Changed functionallity and set the start handle to 0x000C, and end handle to 0xFFFF. This would most likely trigger a rediscovery from the iOS, thus finding your new services and characteristics. The iOS would always look for service changed, and enable this in the peripheral.
If you have any Nordic related question, then you could post them at the Q&A forum located at https://devzone.nordicsemi.com/
BR
Pål
Services and characteristics are cached on the iOS side when you initiate a pairing request with a ble device and discover services/characteristics. Don't do the pairing request if you're concerned about that. Then just pass in the array of services you actually want to discover (not nil).
(Side note: The whole thing of having the ble device controlling which services are seen to the iOS device seems really muddled..you should control that on the iOS side.)