how can the bluetooth server identify the discovered clients - get the type of them, for example, that discovered device is blackberry or iphone device?
You can use device address to find out the manufacturer. The list for lookup is here: http://standards.ieee.org/regauth/oui/oui.txt
Bluetooth devices use a Class Of Device, which is returned when one Bluetooth Device performs an inquiry to find what other devices are around.
Typically, the Bluetooth Inquiry function (depending on API) can be configured to search for a specific Class of Device and return only the results that match that.
The Class of Device value is a 3-octet value. Top 11-bits indicate the Service Class (Information, Telephony, Audio, etc..), 5-Bits for the Major Device Class, (Computer, Phone, LAN, etc...) and 6-bits for the Minor Device Class, which depends on the Major Device Class for interpretation.
The enumerations for the Class of Device values can be found from the BlueTooth website (login required) https://www.bluetooth.org/Technical/AssignedNumbers/baseband.htm
Using this you can narrow down that the server is connecting to a Phone (Major Device Class), specifically a Smart Phone (Minor Device Class). But after that, how to determine the make and model is probably specific to that device e.g. in the Device Name or in a custom field in an Extended Inquiry Response. I don't think there is a (Bluetooth) standard way of doing it.
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.
Is there anyway to differentiate different type of audio devices in android? For example, I got audio device type A and audio device type B from different manufacturers, both devices are using audio jack. Whenever user plug in audio device type A or type B, I wanted to know device id or name, type. I can detect the audio devices plug in/ out using BroadcastReceiver. But couldn't get device id or name or type. Scenario is: when audio device type A is connected, start service A, and when audio device type B is connected, start service B.
No, it's not possible, unfortunately. The audio jack is a purely analog standard, it just doesn't provide any means for identifying a device. The only thing that can be identified is whether it's headphones (no mic), a headset (with mic), or a line in (has higher input impedance than headphones). And the latter difference isn't actually communicated to apps, it only affects how Android does audio routing and applies volume settings.
For USB and Bluetooth devices, information about device manufacturer and ID is available, so they can be distinguished but you need to use a lower level API than just a broadcast receiver. See https://developer.android.com/guide/topics/connectivity/usb/host.html and https://developer.android.com/guide/topics/connectivity/bluetooth.html.
I need to get the friendly device name from a ble sensor. I want to find the device and tell the user they are connected to "My Home Sensor" for example. I can find the device, but I don't know how to find that data.
In regular bluetooth, I believe I can use BLUETOOTH_DEVICE_INFO or winsock.
Is there a bluetooth low energy equivalent to bluetooth's BLUETOOTH_DEVICE_INFO?
If possible, could you please provide an example for how to get the information (i.e. device name)?
I'm using Windows 8.1, c++ and visual studio 2013. I've been referencing windows dev docs, but I haven't found anything useful yet.
Thanks!
Assuming that you are able to get connected with the GATT Server, when you parse the GAP profile of the device, you will find an attribute for Device Name under Generic Access Profile (GAP).
This is a list of all the standard GATT Services and their UUIDs. UUID for GAP is 0x1800.
You can look for the list of all the standard Characteristics and their UUIDs. For the Device Name Characteristic, it is 0x2A00.
This explains that the Device Name characteristic is a part of the GAP.
I understand that Bluetooth profiles consist of other profiles and protocols. What I don't understand is exactly how Bluetooth devices interact with each other. For example, if you take any accessory that implements the A2DP profile and connect it to the iPad then the iPad will stream all audio output to it. This makes me believe that a profile is nothing more than a modular component in a well-defined eco-system. For instance, a web-browser can use any one of your choice of search-engines in the toolbar; would I be correct in saying that the iPad is the equivalent of the browser and the A2DP accessory is the equivalent of the search-engine? Would I also be correct in saying that the use of A2DP is entirely up to the device it's paired with? That is, Apple could have instead chosen (albeit unwisely) to make the iPad output only key-clicks and ring-tones to it, correct? So there's nothing inherent in the A2DP profile that says "All devices using the A2DP profile MUST output all audio to it" right?
I'm not 100% familiar with Bluetooth as a whole. I've been spending some time drafting a profile for BT Low-Energy, so someone might be able to provide insight on standard Bluetooth with a little more detail.
But, from what I understand, the profiles are essentially a large map of connected references. So the A2DP profile will have a list of attributes, or rather, a list of HEX values which point to attributes within the larger profile. These attribute are typically universally available to all profiles, but only implemented by the profile where they are needed. These attributes define some piece of information that is going to be transmitted. This profile needs to be on both device to communicate, because this allows to Bluetooth transmissions to be smaller by only referencing a commonly known definition of the data it is transmitting (rather than defining what the data is in every transmission like some communication types).
So for A2DP, the transmission might be something very simple like '0x1351458 0', which tails the device that whatever that profile attribute is, it's value is 0. So that attribute might be the "play" attribute, so setting to 0 might stop the music.
Again, this is how I understand Bluetooth profiles from the Low-Energy standpoint which tends to be more a transmission of state than actual data, so it might differ a bit with regular Bluetooth.
Bluetooth profiles are specifications of bluetooth protocols that are implemented on the host side in bluetooth protocol stack.
Following link by bluetooth.org will provide basics about bluetooth profiles
https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx
Bluetooth Profiles are set of standard interoperable guidelines defined by bluetooth.org, to ensure interoperability between different bluetooth devices.
Bluetooth devices claiming to support bluetooth profiles, should get Bluetooth Qualification Board[BQB] certified for interoperability.
You can buy any device supporting A2DP and test with any tablet/computers[which has bluetooth A2DP profile supported].
A2DP is not specific to iPad. It is a generic profile that stands for Advanced Audio Distribution Profile for exchanging Audio between two bluetooth devices.
I am trying to get the device node (eg. /dev/sdb) of a usb device.
I was wondering if there is any libusb API that would give me the particular device node to which the USB device is associated with.
If there is no API, are there any other alternate means of achieving this? Any insight on this would prove REALLY helpful.
Thanks in advance.
On Linux, easiest method to explore attached USB devices and their properties is to simply scan directory /sys/bus/usb/devices. This virtual directory lists all attached devices. Each entry has very simple structure, and for every device that has slave connected (like device connected via hub) there is virtual subdirectory.
What is also nice that in general you do not need to be root to read a lot of device properties, like manufacturer or serial number.
Another very good property of this interface is that it is semi-stable. That is, every device has unique id like a-b.c.d.e:x.y (a - bus number, b,c - root hub, next hub, port, etc.., x,y - function, subfunction), and this device enumeration is not going to abruptly shift for all devices if one device is connected or disconnected.
You can also easily map these device ids into libusb-style bus/device numbers (but those are not stable).
Unfortunately, this is Linux specific, and does not seem to be available for other operating systems. I wish libusb had implemented something like this, but it does not.
Anyway, good luck!