What is the best practice for using the Bluetooth Low Energy Generic Access Profile Service (0x1800)?
Is there a reason that iOS prevents developers from using the Generic Access Profile Services and Characteristics?
Section 3.12 (page 24) documents the fact iOS does not
let a developer use that Service (and a couple others)
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
I've also seen some hardware implementations on microcontrollers that also seem to hide this Service from a developer in the firmware.
The work around that I (and most others) have done to allow an app to update the device_name to is to make a separate custom Service-Characteristic that updates the local device name and updates the name in the advertising packet. This is not ideal for many reasons and I am wondering if I am missing something. Should we all be able to use the 0x2A00 Characteristic just like any other Characteristic?
Related
For a project of mine I need a pairless bluetooth data transfer. I have first thought about doing it with BLE IBeacons but they can only advertise a very limited amount of data. I looked further through the Apple documentation and found this tutorial about Central/ Peripheral
BLE data transfer. I've implemented the code in my project but even though the devices were very close together they could not "see" each other. I have since looked up on the Internet and could not find a hint about whether the devices need pairing or not and what the problem of mine could be(the code is not throwing any errors nor warnings).
If it does require pairing, is there some way to do that in the background without requiring the user to perform an action, so that I could theoretically advertise some kind of pair request via. IBeacons to then transfer the data? If that's not the case, is there even a way to transfer data (mono directional, round about 512 bytes) between nearby bluetooth devices without user actions?
greets from germany!
To get started with Bluetooth Low Energy or any other protocol, it's best to learn how it works. At least basics.
Simplifying. BLE allows you to send data:
"Passive" (without conncetion) - over Advertisement Data. The size of the packages depends on the BLE version.
"Active" (requires connection with the device) - bidrirectional comunication. In this case size of the data package also depends on the BLE version.
Bonding and pairing is a separate issues.
I suggested you look at the following book:
https://www.oreilly.com/library/view/getting-started-with/9781491900550/
The websites of BLE module manufacturers also offer a lot of information about this technology. For example Nordic or TI. Very often with sample programs for various platforms.
For iOS:
https://developer.apple.com/videos/play/wwdc2017/712/
https://developer.apple.com/bluetooth/
You may also be interested in sending more data without connection using version BLE 5.0
https://www.bluetooth.com/blog/exploring-bluetooth5-whats-new-in-advertising/
From Android documentation:
Caution: When a user pairs their device with another device using BLE, the data that's communicated between the two devices is accessible to all apps on the user's device.
For this reason, if your app captures sensitive data, you should implement app-layer security to protect the privacy of that data.
Is this also true for iOS? I haven't found anything on it and I assumed because iOS doesn't show the true MAC addresses of devices this wouldn't be an issue, but just wanted to check. Thanks
Yes, iOS also works in a similar way. And if you want private communication, you also need to maintain app layer security. Thus android wear, galaxy watch, and other similar devices use encrypted communication in the app layer.
If you already know the details. BLE communication works via Gatt Characteristics.
Consider there are two health applications running on an iOS device and the user also using an activity tracker device. In that case if the user wants to connect both of the health apps with that tracker, he certainly can do it. Both apps will be able to communicate with the activity tracker and get sensor data using the CBCentral module. Look at the diagram for Details.
On the other hand, In general, vice versa will not possible. Because if both iOS apps use Peripheral Role they will register two different instances of BLE-Service even if using the same UUID. Thus it will force two apps to communicate with completely different characteristics instances. However, it is also possible to work with two peripheral apps with the same UUID but this is not what the BLE developers ever wanted.
you need to provide app level security based on Service UUID, so that devices having the app with only same service UUID can connect.
I'm hoping to create a BLE advertisement on iOS where I can control the advertisement on a byte level.
One use case would be to mimic an iBeacon advertisement. What is the iBeacon Bluetooth Profile (I want to advertise while my app is in the background which is why I'm not using CoreLocation)
I do not see a way to do this with the Core Bluetooth API. Is this correct? Are there alternatives using private API's or jailbreaking?
As the others already pointed out, there is no API on iOS that allows you to do this.
You can advertise as an iBeacon, but only when your app is in the foreground. When in background, the advertisement is removed and therefore cannot be discovered anymore (except for other iOS devices which explicitly scan for that service UUID). Also see the documentation here: Core Bluetooth Background Processing
If you would share your use case and what you want to achieve, maybe there are other ways to realise it.
My experience with iOS is that if it is something is not exposed in the API, there is no way around, except jailbreaking. For Bluetooth low energy the API is at GAP/GATT level, and very little at the lower levels (if anything) is exposed. Advertising is a LL (link layer) feature.
To illustrate how restricted the access is: When scanning for BLE devices you will not have access to the advertiser's MAC address iOS. In Android you have it.
I do not see a way to do this with the Core Bluetooth API. Is this
correct?
Since you have to set Manufacture Specific Data in order to achieve this, if nothing has changed you will experience exactly the same issue that I did. Explained here:
The advertisement key 'Manufacturer Data' is not allowed in CoreBluetooth
It is not possible.
I am looking for a way to load data from an embedded device via a serial port (RS232) to an iPhone. The app needs to be on the AppStore and our company is not part of the MFI program.
Before you say, it can't be done, we are looking into Bluetooth Low Energy 4.0 as a possible solution. We can create a device that can turn ConnectBlue's OBS421 module into a serial port adapter (with the speed bursts limitation). To that effect, connectBlue provides their own protocol called Serial Port Service, but it is documented only on a very high level.
Does anyone have any experience in using this protocol? If so, can you provide an example(objective C) code that establishes communication in this way?
Has anyone submitted an app to Apple that does this without getting rejected for infringing MFI rules?
One more question.. The device I am trying to connect only supports serial commands in the EZII Escape Computer Command Set standard (PROG ID of "EZ2 2.0" and higher). They look different than the common ATT-Commands. Example: <ESC>Gc100<EOT>.
Any idea if I can send such commands via ConnectBlue's LE-SPS?
Your help is much appreciated.
Thank you!
I haven't used this protocol but from the documentation it seems quite straight-forward. You should be able to take any of the core-bluetooth examples and adapt it fairly quickly.
You need to look for a peripheral that is offering service 0x2456e1b926e28f83e744f34f01e9d701
This service exposes two characteristics -
0x2456e1b926e28f83e744f34f01e9d703 to read & write to the serial port
0x2456e1b926e28f83e744f34f01e9d704 for "credits" if you need flow control. Essentially it seems that this value indicates the number of bytes you can send to the device and you can write a value to indicate the number of bytes you are prepared to receive from the device
The device should support a full 8-bit data path, so I don't see why you would have a problem sending the serial commands.
Bluetooth Low Energy is specifically excluded from the MFI program, so you won't get rejected on that basis -
I want to develop an accessory that communicates with an Apple device
using only Bluetooth Low Energy. Do I need to join the MFi Program?
No. Accessories which connect to an Apple device using only Bluetooth
Low Energy/BTLE/Bluetooth 4.0 or standard Bluetooth profiles supported
by iOS are not part of the MFi Program.
Bluetooth Low Energy does not have a SPP defined as a standard protocol.
You have to program it yourself using the GATT service/characteristics, you just need to generate your own 128bit UUID (google it, there are plenty of UUID generators and even on Mac or Linux it's easy to generate from command prompt)
GATT sends smaller chunks of data which you would have to concatenate yourself in the other end.
Be aware that the throughput of BLE is quite low compared to Bluetooth Classic SPP. Maybe around 3kbytes/sec.
I have an application (Basically an Arduino) that I connect to from iOS (and might use Android in the future as well) using BLE. I reprogram the BLE hosts to a specific value so that the when I ask the peripherals name after it gets discovered in iOS can be accepted or rejected.
I'm however not sure that this is a good way to do. The name has a code that users can easily change to an other (always valid) code. That way if two modules are up and running at the same time, users will be sure that only the module they are linked to is the one they want to be linked to. This is a bit the same like connecting a mouse / keyboard of course using 'normal' bluetooth.