I want to know what does bluetooth transmit when it is just visible, not connected. I googled , I saw it transmit name of the device and mac address but just them ? Can we add some extra datas or can we change them dynamically ?
For classic Bluetooth (i.e. pre Android API level 21), you are restricted with the data that you can send in the inquiry response (which is connection-less data sent over the air). There are three types of inquiry response data that can be sent over the air:-
Inquiry Result:-
Inquiry Result with RSSI:-
Extended Inquiry Result:-
In other words, depending on what the scanning device asks for, the result can be different, and even though in all cases it is not just name and mac address, you cannot add just random extra data to the inquiry response.
For Bluetooth Low Energy (i.e. Android API level 21 and later), advertising data can be dynamic and can be configurable. The minimum advert report can only contain the device's Bluetooth Address (either the public or the random address). In other words, even the name of the device is not a requirement. However, it is usually common to include both the address and the name as this gives more information about the advertising device.
You can read more about this in the Bluetooth Specification v5.2, Vol 6, Part B, Section 2.3.1 (Advertising PDUs). Also have a look at the links below for more information:-
Is a BLE advertisement required to provide a non-empty local name
How BLE works: advertisements
BLE advertising primer
Related
Does anybody have the BLE Advertising Packet format that shows the relation (e.g. a hierarchy graph) among packet preamble, MAC address, and CRC fields? A graph that shows the length of bits for each field would be the best.
This is written in the Bluetooth Core
Specification https://www.bluetooth.com/specifications/specs/core-specification/ in the Link Layer chapter, section 2.1.
The advertising bluetooth device address is found in section 2.3.1.1 (ADV_IND).
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
In terms of BLE, I'm getting a little confused between the terms and their usage in BlueZ:
Manufacturer Data
Service Data
Advertising Data
I'm going to try to sum up what I understand and where that falls apart.
From here there is a payload in the Advertising Packet that is 31 bytes long that can be used for User Defined Data.
However, BlueZ in its advertising API have a different notion of data. It takes a dict which is of <type> <byte array> from the docs.
Looking a little more you can come across this table which seems to be of the same two byte type and data structure.
It has user defined payload in terms of:
0xFF «Manufacturer Specific Data» Bluetooth Core Specification:Vol. 3, Part C, section 8.1.4 (v2.1 + EDR, 3.0 + HS and 4.0)Vol. 3, Part C, sections 11.1.4 and 18.11 (v4.0)Core Specification Supplement, Part A, section 1.4
So I downloaded the spec to try to read up on the distinction, which leads me to this sentence that I don't quite follow:
The data is sent in advertising or periodic advertising events. Host Advertising
data is placed in the AdvData field of ADV_IND, ADV_NONCONN_IND,
ADV_SCAN_IND, AUX_ADV_IND, and AUX_CHAIN_IND PDUs. Additional
Controller Advertising Data is placed in the ACAD field of AUX_ADV_IND,
AUX_SYNC_IND, and AUX_SCAN_RSP PDUs. Periodic Advertising data is
placed in the AdvData field of AUX_SYNC_IND and AUX_CHAIN_IND PDUs.
Scan Response data is sent in the ScanRspData field of SCAN_RSP PDUs or
the AdvData field of AUX_SCAN_RSP PDUs. If the complete data cannot fit in
the AdvData field of an AUX_ADV_IND, AUX_SYNC_IND, or
AUX_SCAN_RSP PDU, AUX_CHAIN_IND PDUs are used to send the
remaining fragments of the data. An AD Structure may be fragmented over two
or more PDUs
Also when I look in the BlueZ implementation of their own DBUS API, I see they provide a way to fill in manufacturing data but no way to change the type of advertising (ADV_NONCONN vs ADV_CONN)
.
They also do have an adv_data type but it's only 25 bytes? Why can I not get the full 31 bytes?
https://github.com/bluez/bluez/blob/cbbb0c2ead89ed19280ecd94e8a2fb0d22216bb6/client/advertising.c#L55
Actual Questions:
When implementing a BT peripheral using BlueZ do I have 31 or 25 bytes. Can I fill in both Service Data and Manufacturer Data for a total of 50 bytes??
Is Manufacturer Data an abstraction over Advertising Data? If so how can I access the underlying Advertising Data? If not, can I theoretically fill in both Advertising and Manufacturer data?
The image below created by Jos Ryke might be helpful to visualise what is happening.
As shown in the image, ADV FLAGS and Advertisement data make up the 31 bytes advertising payload, but there are only 26 bytes for data available. The image contains examples of Manufacturer Data (type = FF) and Service Data (type = 16)
In the D-Bus API, to change the type of advertising (ADV_NONCONN vs ADV_CONN) use the type property:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n37
broadcast = ADV_NONCONN
You can have both service and manufacturer data in the same advertisement (see example https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-advertisement#n141) but it cannot be longer than 31 bytes. With BlueZ, you can register (if I remember correctly) up to four advertisements that will be sent as different packets.
So in summary, service data and manufacturer data are sub elements types within advertising payload. BlueZ allows you to build up the different data types you want in your advertisement and then register it for broadcast.
I bought a HM-15 BLE bluetooth module and successefully connected to Arduino. I am able to sent At commands and I would like to use it for scanning for iBeacons and get their major and minor.
Using AT+DISC? I can see the beacon address but I cannot connect to it and now I am stuck on how to retrieve major and minor
Can you help me? Here is the datasheet of the module:
http://www.elecrow.com/download/bluetooth40_en.pdf
Thanks
Bluetooth beacons do not require a connection and you read the identifiers directly from the advertisement.
Read section 19, Start a discovery scan, and learn how to read and decode the bytes in the discovered peripherals. The exact byte layout varies for different beacon types. For AltBeacon, an open source beacon variant, you can see the byte layout here: https://github.com/AltBeacon/spec
To decode a proprietary beacon format, you will need to learn how that beacon layout differs from the example linked above.
Old question, but just for the record, you can use AT-DISI?
This will scan for beacons, including iBeacons and also AltBeacons. The response from HM-10 will include RSSI for each.
PS: I'm assuming HM-15 and HM-10 operate the same way. Probably not exactly a fully reasonable assumption.
Bluetooth standard V4.0 [vol. 2, 7.7.65.2] allows the controller to "queue advertising reports and send information from multiple devices in one LE Advertising Report event".
To manage this feature, the HCI protocol includes, among the Event parameters, the field Num_Reports (with values between 1 and 25).
In case Num_reports is > 1, how the Event parameters are organized in the event packet received through HCI?
Note 1: The Bluetooth standard seems to specify an unusual ordering of the data, not packing each advertising report after the other (as suggested by the event description), but packing instead each type of information after the other (i.e. all Event_types for each advertiser, followed by all Address types, then all addresses, and so on till last field, with all rssi values). Do I understand well?
Note 2: I didn't find any software example managing more than 1 advertising report in one single event. Does it mean that this feature of the standard isn't used by real-world devices?
You understand correctly.
When there are more (Num_Reports > 1) advertising reports packed into one event, these parameters are contained by the event:
Subevent_Code,
Num_Reports,
Event_Type[i],
Address_Type[i],
Address[i],
Length[i],
Data[i],
RSSI[i]
So for example if Num_Reports = 3, then follow 3 Event_Type (each being one of ADV_IND, ADV_DIRECT_IND etc.) for the 3 reports, in the order they were received.
The same order is preserved for all other parameters marked with [i].
To answer your second question: the standard says the controller may queue more reports into one event. Perhaps the implementations you have looked into don't do it.