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.
Related
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
I've been working doing some reverse engineering to different BLE based devices and I have a weight scale where I can't find a pattern to find/decode/interpret the weight value that I can get from the android app. I was also able to get the services and characteristics of this device but did not found a SIG standard match with the UUIDs from the bluetooth site.
I'm using an nRF51 dongle to sniffing data packets between the android app and the weight scale and I can look the ble traffic, but there are several events during the communication that I can't really understand what's the relation and I can't be able to convert those values to readable weight in kg or pounds.
My target value is: 71.3kg readed from the weight scale app.
Let me show you what I get from the ble sniffer.
first I see that the master is sending notification/indication requests to the handles 0x0009(notify), 0x000c(indication) and 0x000f(notify) in each characteristic of one service.
Then I start to read notification/indications values mixed with write commands. At the end of the communication, I see some packets that I feel that they are the ones with the weight scale data and BMI.
Packets number 574, 672 and 674 in the image.
So that give us the following candidates:
1st. packet_number_574 = '000002c9070002
2nd. packet_number_672 = '420001000000005ed12059007f02c9011d01f101'
3rd. packet_number_674 = '42018c016b00070237057d001a01bc001d007c'
1st packet during the communication exchange looks more like a counter/RT/clock than a real measurement because of the data behavior, so I feel this one is not a real option.
2nd and 3rd looks more like real candidates, I have split them and convert them to decimal values and I have not found a relation, even combining bytes since this values are floating point data types. So my real question is, Am I missing something that you might see with this information? Do you know if there is a relation between this data packets and my target?
Thank you for taking your time reading me and any help could be good, thanks!
EDIT:
I have a python script that allows me to check the services and their characteristics hierarchy and some useful data like properties, their handles and descriptors.
Service 'fff0' (0000fff0-0000-1000-8000-00805f9b34fb):
Characteristic 'fff1' (0000fff1-0000-1000-8000-00805f9b34fb):
Handle: 8 (8)
Readable: False
Pro+perties: WRITE NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0x9; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff2' (0000fff2-0000-1000-8000-00805f9b34fb):
Handle: 11 (b)
Readable: False
Properties: WRITE NO RESPONSE INDICATE
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xc; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff3' (0000fff3-0000-1000-8000-00805f9b34fb):
Handle: 14 (e)
Readable: False
Properties: NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xf; uuid 00002902-0000-1000-8000-00805f9b34fb)
This are the characteristics related to the notifications and indications that I see in wireshark. I think the packet number 574 (which characteristics has only a notifiy property) is more important than I think.
I solve it by myself.
This post gives me the idea to take the values (2 bytes) and multiply them by 0.1, that way I could get the weight.
In bytes I could look for my target value without decimals 713, which is in hex = 0x02c9
If we look at the packet number 574:
000002c9070002 and split it 00:00:02:c9:07:00:02
I could see that 2nd and 3rd bytes match with this pattern!
The only thing required to do is to group this bytes and multiply the decimal value 713 x 0.1 = 71.3. I made different tests and found that this pattern is constant so I feel is accurate for my solution. Hope this could help someone in the future.
I'm implementing a LIN protocol on a Linux SBC that transmits over a UART. I don't have time to develop a complete LIN stack, so I'm just implementing a frame structure for messages as defined by the protocol. The problem is that the protocol requires a "Break" field which makes the slave devices on the bus listen. This field consists of zeros for 13 bit-times. Any ideas how to send zeros 13 bit-times over UART, when serial data transmission requires complete bytes?
Per Wiki:
LIN (Local Interconnect Network) is a serial network protocol used for
communication between components in vehicles. The need for a cheap
serial network arose as the technologies and the facilities
implemented in the car grew, while the CAN bus was too expensive to
implement for every component in the car. European car manufacturers
started using different serial communication topologies, which led to
compatibility problems.
If you would have paid attention at class you would have known that:
Data is transferred across the bus in fixed form messages of
selectable lengths. The master task transmits a header that consists
of a break signal followed by synchronization and identifier fields.
The slaves respond with a data frame that consists of between 2, 4 and
8 data bytes plus 3 bytes of control information.
You should just send an echo of 0x0000 following by CR/LF.
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.
I'm using Bluetooth Low Energy to connect a device in Central mode to several devices in Peripheral mode. The Peripheral device would need to send 4 strings (all fewer than 20 characters) to the Central device.
Is it better to create 4 characteristics and have the Peripheral make 4 write requests to the Central? Or is it better to have 1 characteristic and combine all 4 strings into a JSON object as to make only 1 write request?
Simply put - is it better in this instance to small chunks of data multiple times or send a larger chunk of data once?
Which approach would be better for allowing as many Peripherals to connect to a Central as possible? Does it matter?
Thanks.
Since you have four separate strings I would recommend that you make four characteristics as well. The data packets in BLE is usually about 20 bytes (23 bytes minus some ATT overhead) so your data fits in a single packet. And when you do a read long (on a single long attribute) your going to get a single read response packet back before you ask for the next chunk of data. You would probably end up with the same amount of packets going back and forth to read the data. Obviously, discovering four vs only one characteristic takes a few extra packets, but nothing to worry about.
Simply put - is it better in this instance to small chunks of data
multiple times or send a larger chunk of data once?
Only if your data strings are considerably smaller than 20 bytes.
You talk about having the peripheral write it's data to the central (presumably right after connection). Normally this is done the other way, where the central first discovers the peripheral database (after connection of course) and then read the data it's interested in.
You can also consider using indications, rather than reads. This is typical for a peripheral sensor which is logging data. The central connects, discovers the database and then enable notification for a given attribute. The peripheral will then send each data sample (maybe packed in some way) with indications until all the locally logged data has been transferred. With indication, every transfer is acknowledged so the peripheral can wait for the confirmation before removing the data locally making sure you don't loose logging samples.
Which approach would be better for allowing as many Peripherals to
connect to a Central as possible? Does it matter?
The way to organize and transfer data does not matter in how many peripherals your central can connect to. But if your peripherals write into the central database you need to make sure they don't write to the same handle(s). Better to do a read or indication/confirmation initiated by the central.