I am finding out about BLE on the Internet. I don't understand why everybody use GATT server for the device, such as KIT. And use GATT client for the application on mobile?
Can you explain for me?
Thank you very much!
The roles in Bluetooth are Central and Peripheral. Typically the computer/mobile device will have the central role and the Bluetooth device (let's say a heart monitor) will be the peripheral.
The central will initiate a connection to the peripheral. If you were to think of it in client/server terms, the heart rate monitor is the server (it serves heart rate data) and the mobile application is the client (it is receiving the data) but as I said, this isn't the right terminology for BLE.
BLE devices often have limited or no user interface capability while the mobile device has a touch screen - so it is much easier to discover and connect to a peripheral from a mobile device acting as a central than if the roles were reversed.
Related
When connection to a custom BLE device from an app (android and ios) I have two options
a) first pair the device on the phone (like a headset or other devices) and then use it from the app to read and write data
b) without pairing on the phone, go inside the app, search for a device with a specific name or address, and just connect to it and read and write data.
when is one preferred over the other one ?
Its just when it needs to interact in the background or am I missing something?
The devices you see in your phones Bluetooth settings are Bluetooth Classic devices. There are some devices using both BLE and Bluetooth Classic which show up in the settings too, but the settings page is only for the Bluetooth Classic part of the device. Headphones for example are streaming music trough the Bluetooth Classic profile A2DP but might offer BLE services for additional features.
You always have to use a special app to communicate with the BLE part of a device. This could be an app provided by a manufacturer or a generic BLE scanner app such as nRF Connect.
As alexander.cpp already told you in his answer pairing (the exchange of keys) and bonding (saving of said keys) is not required for the communication with BLE devices and only needed if the device requires a secured connection.
Bonding (technically correct term for BLE, often called Pairing in non-technical speech) is mostly for security, we can send sensitive information because the receiver is verified and data is transferred in encrypted form.
Prefer to use bonding if the data is sensitive (means users feel uncomfortable if somebody they don't know receive their data). For example, I consider "current temperature = 25" as NOT sensitive. For detailed explanation, find "Bonding with a BLE device" in BLE guide by PunchThrough.
Also this is a good answer to a similar question: https://stackoverflow.com/a/42916081/10380092.
Your second question about background - no, bonding is not related to interaction in background.
I am looking for a way to scan a device I own and discover "what it can do".
In other words, I'd like to know if a device is able to describe the way you have to communicate with it in order to build some application around it.
In my case it is a simple Christmas light that I'd like to play with but this could be used in different situations.
For classic bluetooth (BR/EDR):
When scanning for bluetooth devices (Inquiry), the bluetooth device will send an inquiry response (if it wants to be discovered) and maybe also an extended inquiry response (EIR). This EIR may already contain a list of services, the devices supports. This is a very fast way to get a picture of a remote device.
Moreover, the service discovery protocol (SDP) gives more information on a device. This takes some more steps. In SDP two devices can exchange their capabilites in kind of ping pong process.
For BLE:
After connecting a BLE device usually a service discovery takes place. The BLE peripheral (e.g. headset or a light) reports its capabilities to the central (e.g. smart phone). Some of these services have predefines functionalities. Additionally, it is free to the manufacturer to add custom services.
I'm not a ble guru, I worked on some modules to expose some simple service with pairing and bla bla :9
One of our customer ask me if it possible to control mcu gpio, with a beacon service running. For what I know beacon standard is only a lighthouse to check the proximity (streaming simple packet uuid, signal strength etc etc), and the only way to do something like this is to expose a new service running concurrently with beacon ( in practice send multi type of packets). I don't want pairing (beacon<->device app) and don't worry about race condition, if multi devices set/reset a gpio, it's not my business.
I found something similar https://community.estimote.com/hc/en-us/articles/217429867-What-is-GPIO-How-to-set-it-up-, what you think about?
There are libraries or eddystone's extensions to do that? Some project on github?
We prefer to work with Nordic ble module, but if you know solution based on other mcu, you are welcome.
Thanks for your help
Standard beacons (iBeacon, Eddystone, AltBeacon) are transmit only devices. They simply send out advertisements at a fixed rate with a unique identifier. Some manufacturers expose proprietary configuration interfaces as read-write Bluetooth LE GATT Services. But there is no standard GATT Service that does this, and the manufacturer-specific schemes are designed specifically to set beacon identifiers and other operating parameters.
I don't think there are beacon-specific libraries or extensions that will help with this, beyond standard Bluetooth LE SDKs for iOS and Android. In order to accomplish this goal with a Nordic BLE module you would need to build your own custom system:
Write custom Nordic firmware (that sits alongside beacon transmission firmware) that exposes a new Bluetooth LE GATT Service. The service would expose a writable GATT Attribute that would control the GPIO pin.
Write custom mobile app code that connects to this GATT Service (CoreBluetooth on iOS and android.bluetooth on Android), and writes to the GATT attribute to control the pin.
One thing you must be careful of is that connecting to to a GATT Service will typically stop a Bluetooth Peripheral from advertising (meaning it won't transmit as a beacon). So you may wish to drop the connection quickly to prevent mobile devices or other Bluetooth Centrals from stoping the beacon transmissions.
I was wondering if there's any way that I can control BLE device pairing specific to my app running on mobile device?
I do not want to write my own bluetooth profile so that only my app can talk to the BLE device instead i want to standard profiles available in BLE device but when it's paired to my phone, only my app should be able to communicate to it and none of the other apps should be able to communicate.
No don't do that.
If you MUST then you should encrypt your data with a key only your app knows.
Bluetooth Low Energy is supposed to be open and free for all.
What is the purpose for you to block others? Preventing them to block your service?
Then use some pre-shared key to verify that it's your app in both sides and close the connection if it's not.
i know that iBeacon use only advertising channel. which means there is no need connection.
im trying to make my own beacon module which send and receive data.
im curious about what makes the packet in iBeacon format(prefix /UUID / minor/ major/ TX) in communication ?
is it firmware?
let's assume that
when i make my iPhone act as iBeacon , it will send the advertising packet. which means it sends data in iBeacon format. but after turn off the app for iBeacon, i try to use my iphone
to send some files to laptop via Bluetooth low energy mode as usual.
then it will send data in bluetooth standard format. is this right?
given that situation, my iphone can be both iBeacon and just normal phone capable of bluetooth low energy.
i think also the beacon module can be like that. how about the product recently released? like estimote, redbearlab and so on. after connection, do they receive data?
Every iBeacon product works a little differently, but it is common for a product to be connectable for configuration purposes over Bluetooth LE.
Radius Networks' RadBeacon, for example, has firmware that sends out its advertisement as needed to be a standard iBeacon. The same firmware will allow a connection over Bluetooth LE, exchanging data with an external client (the RadBeacon app for iOS). This connectability is outside standard iBeacon functionality, using proprietary techniques that are still part of the larger Bluetooth LE standard.
Your understanding is therefore correct.
Full disclosure: I am Chief Engineer at Radius Networks.