Is there a way to know the Android Bluetooth Ver?( 5 or 4.x - 4.1 or 4.2?)
Currently as per
https://developer.android.com/about/versions/oreo/android-8.0-changes
Feature like Advertisement packet length ~ 60 bytes of more than usual (that is 31 bytes) or Support for LE Extended Advertising are features for Bluetooth 5.
Is checking these APIs below (for True) can guarantee that the Bluetooth 5 is supported?
Also is it possible to know the Bluetooth ( though they come in WiFI Combo) chip version?
isLe2MPhySupported()
isLeCodedPhySupported()
isLeExtendedAdvertisingSupported()
isLePeriodicAdvertisingSupported()
getLeMaximumAdvertisingDataLength() > 31 ( for Bluetooth 5)
I have read that by getting the Physical MAC of the device we can know to which Brand the chip-set is as different vendors have purchased these MACs from the Bluetooth Org?
Assist please !
Yes if any of the APIs listed above returns true, then your device supports Bluetooth v5. The reason that there isn't a clear cut 'version' API is that Bluetooth is now more about features than it is about hardware version. You can have a device that contains Bluetooth 5 hardware, but will not support any of the Bluetooth 5 features such as 2MPHY, CODED PHY, or LE Advertising Extensions. Therefore it is more useful to have a feature by feature check of your hardware.
You are correct in that different companies have different MAC addresses assigned to them. You can find the full list here. For example, theoretically speaking, Apple MAC Addresses should start with 00:4C:XX:XX:XX:XX. However, I say theoretically because not everyone abides by this, and as a user you sometimes have the option to change your MAC address, making this information redundant.
I hope this helps.
Related
I’m working on a project that uses BLE (Bluetooth Low Energy) protocols for transferring data and am currently limited to my MacBook due to some Admin permission constraints on my work machine (running Windows).
I need to find a USB adapter that supports Bluetooth 4.0 Tx/Rx, however I am ONLY finding these dongles that solely support Windows distros. So my question:
1) Why is this? Is Bluetooth SIG or at least BLE somehow a propriety protocol patented or somehow bound to Microsoft? I mean, there exist iOS libraries for high-level BLE management, so...
2) Am I just missing the product I’m looking for and there are such accessories compatible with a Unix based OS?
Who said USB dongles only support Windows? On the contrary, I haven't heard about a single USB dongle that doesn't support Linux. Bluetooth SIG has defined and specified HCI over USB and every device uses that protocol (however some device specific code is often needed to initialize the device). See a list of some tested devices at https://github.com/50ButtonsEach/fliclib-linux-hci/blob/master/README.md#bluetooth-controllers. Those should work with Mac OS X as well, but if the computer already has a built in Bluetooth chip you might need to adjust the currently used device.
As far as I read about the dev boards, every SoC is capable to use Bluetooth.
I didn't tested it yet, but can I use Android Things with a Bluetooth connection? My question is, how can I enable Bluetooth without an input device? If I want to enable Bluetooth on my phone (with code), I had to confirm it, but this can't be possible on Android Things.
Update: Since the release of Android Things developer preview 3, Bluetooth and BLE are now available.
Old Answer
No. You can not use Bluetooth with the current version of AndroidThings (developer preview 1).
It is said in the known issues part of the release notes that Bluetooth is currently disabled (and so is USB).
It is supposed to be included at some point, but at the moment if you try to get a BluetoothAdapter it does return null.
Android Things will use the latest version of Bluetooth called Bluetooth Low Energy and the only similarity between the two is that they have Bluetooth in the name!
Can I use Android Things with a Bluetooth connection?
Yes, well a Bluetooth Low Energy connection
https://www.link-labs.com/bluetooth-vs-bluetooth-low-energy/
In summary, Bluetooth and Bluetooth Low Energy (BLE) are used for very different purposes. Bluetooth can handle a lot of data, but consumes battery life quickly and costs a lot more. BLE is used for applications that do not need to exchange large amounts of data, and can therefore run on battery power for years at a cheaper cost. It all depends on what you’re trying to accomplish.
Everything you need to know about BLE is written here:
https://developer.android.com/guide/topics/connectivity/bluetooth-le.html
how can I enable Bluetooth without an input device?
You do not pair BLE devices like you used to with the older Bluetooth (but you can use Bonding). Check this out:
Android Bluetooth Low Energy Pairing
https://stackoverflow.com/a/20093695/413127
But as stated by #shalafi Android Things doesn't currently support Bluetooth
I am trying to identify which android phones support Bluetooth Low Energy and I am a bit confused on whether or not a device with BTv4.0+ is BLE compatible.
To be more precise, I am looking at the device Samsung Galaxy J5. According to http://www.gsmarena.com/samsung_galaxy_j5-7184.php, the bluetooth version is 4.1 but it doesn't mention anything about BLE.
According to the bluetooth specification:
"Bluetooth Low Energy (LE) (also called Bluetooth Smart or Version 4.0+ of the Bluetooth specification) is the power- and application-friendly version of Bluetooth that was built for the Internet of Things (IoT).". According to this I would presume that 4.0+ is BLE.
However if you see the specs of Samsung Galaxy S6 (http://www.gsmarena.com/samsung_galaxy_s6-6849.php) it mentions that it supports both BTv4.1 and BLE. It therefore distinguishes the two BT specifications.
Any information would be very helpful
Edit
Additional reference information for interested parties:
from bluetooth.org: Two flavors of Bluetooth The two most prevalent implementations of the specification are Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), which was adopted as version 2.0/2.1, and Bluetooth with low energy (LE), which was adopted as version 4.0/4.1/4.2. Each implementation has different use cases and each implementation uses a different chipset to meet essential hardware requirements. Dual-mode chipsets are also available for applications that include both use cases. - See more at: https://www.bluetooth.com/specifications/bluetooth-core-specification#sthash.7X7IrtWy.dpuf
Instead of relying on gsmarena with unreliable information, you can refer to Bluetooth SIG's official information.
Based on this Bluetooth SIG's announcement and this one, BLE is a core specification of Bluetooth 4.0. Bluetooth 4.1 and 4.2 also adopt this core specification.
However, all this still depends on whether the manufacturers implement the firmware. To keep track of all this, Bluetooth SIG maintains a list of devices currently supporting any profile (for example GATT).
This crossed my mind myself as I saw it as a pointless advancement until I saw the low energy bLE (bluetooth low energy) side of it. In my pastime I tinker with various electronics and with various BLE 4.x modules and their pro's and cons are HUGE.
All in all, BLE is better as Bluetooth pretty much is battery drain on the most robust of phones.
I found a nice little writeup (pretty simple yet comprehensive) here: http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-guide-to-selecting-a-bluetooth-chipset/
Do cut my answer short, as the bag you linked shows it as being "NFC" compatible, then yet, it's BLE 4.x. (That's Near Field Communication i.e. similar to your your contactless bank card). The v4.1, A2DP which you mention is how one "audio device talks to another" via bluetooth. (dvanced Audio Distribution Profile).
If you're really bored, there's a long list of other profiles (other than A2D):
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
Hope this helps!
Happy bluetoothing!
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.
I know that one way to find this out is to have a look at the device specification. Most device specifications are reporting just that A2DP is supported. Is there another way to find which version of A2DP is used from a headset device?
I recommend using linux with either built in bluetooth or with a bluetooth dongle. Then you can use the bluez tool sdptool from the command line to get this information.
A protocol sniffer is not necessary as all a protocol sniffer does is decode the packets over the air (which is exactly what sdptool does already), and it is more difficult as you will need to find out the link key as well which, depending on the devices you are using, can be quite difficult.
Currently there are only 2 versions of A2DP - 1.0 and 1.2
The differences are only minor optimizations / adaptations. So from a user's point of view it really does not matter.
Both versions are compatible and will talk to each other.
Since the differences are minor technical documentation changes in the spec it is not marketed as different versions to the end user. (Its just A2DP)
To really know the versions you will have to hook up with a Protocol sniffer and look at the SDP (Service Discovery) Query which typically happens after pairing / initial connection.