I stumbled upon this Question: Reading Thermometer Data with Bluez Bluetooth Low Energy
and was following it trying to read data from a bluetooth thermometer that I got.
I was able to extract and read all handles with this command:
gatttool -b 00:11:22:33:44:55 -I
[00:11:22:33:44:55][LE]> connect
Connection successful
[00:11:22:33:44:55][LE]> primary
attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0008, end grp handle: 0x000b uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x001e uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x001f, end grp handle: 0xffff uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-desc 0x0001 0x0001
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-desc 0x0001 0x0007
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 01
Characteristic value/descriptor: 00 18
[00:11:22:33:44:55][LE]> char-read-hnd 02
Characteristic value/descriptor: 02 03 00 00 2a
[00:11:22:33:44:55][LE]> char-read-hnd 03
Characteristic value/descriptor: 54 68 65 72 6d 6f 42 65 61 63 6f 6e
[00:11:22:33:44:55][LE]> char-read-hnd 04
Characteristic value/descriptor: 02 05 00 01 2a
[00:11:22:33:44:55][LE]> char-read-hnd 05
Characteristic value/descriptor: 00 00
[00:11:22:33:44:55][LE]> char-read-hnd 06
Characteristic value/descriptor: 02 07 00 04 2a
[00:11:22:33:44:55][LE]> char-read-hnd 07
Characteristic value/descriptor: 50 00 a0 00 00 00 e8 03
[00:11:22:33:44:55][LE]> char-desc 0x0008 0x000b
handle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0009, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000a, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x000b, uuid: 00002902-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 08
Characteristic value/descriptor: 01 18
[00:11:22:33:44:55][LE]> char-read-hnd 09
Characteristic value/descriptor: 20 0a 00 05 2a
[00:11:22:33:44:55][LE]> char-read-hnd 0a
Error: Characteristic value/descriptor read failed: Attribute can't be read
[00:11:22:33:44:55][LE]> char-read-hnd 0b
Characteristic value/descriptor: 00 00
[00:11:22:33:44:55][LE]> char-desc 0x000c 0x001e
handle: 0x000c, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x000d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000e, uuid: 00002a23-0000-1000-8000-00805f9b34fb
handle: 0x000f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0010, uuid: 00002a24-0000-1000-8000-00805f9b34fb
handle: 0x0011, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0012, uuid: 00002a25-0000-1000-8000-00805f9b34fb
handle: 0x0013, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0014, uuid: 00002a26-0000-1000-8000-00805f9b34fb
handle: 0x0015, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb
handle: 0x0017, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0018, uuid: 00002a28-0000-1000-8000-00805f9b34fb
handle: 0x0019, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001a, uuid: 00002a29-0000-1000-8000-00805f9b34fb
handle: 0x001b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001c, uuid: 00002a2a-0000-1000-8000-00805f9b34fb
handle: 0x001d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 0c
Characteristic value/descriptor: 0a 18
[00:11:22:33:44:55][LE]> char-read-hnd 0d
Characteristic value/descriptor: 02 0e 00 23 2a
[00:11:22:33:44:55][LE]> char-read-hnd 0e
Characteristic value/descriptor: 5e 0b 00 00 00 00 f4 00
[00:11:22:33:44:55][LE]> char-read-hnd 0f
Characteristic value/descriptor: 02 10 00 24 2a
[00:11:22:33:44:55][LE]> char-read-hnd 10
Characteristic value/descriptor: 4d 6f 64 65 6c 20 4e 75 6d 62 65 72
[00:11:22:33:44:55][LE]> char-read-hnd 11
Characteristic value/descriptor: 02 12 00 25 2a
[00:11:22:33:44:55][LE]> char-read-hnd 12
Characteristic value/descriptor: 53 65 72 69 61 6c 20 4e 75 6d 62 65 72
[00:11:22:33:44:55][LE]> char-read-hnd 13
Characteristic value/descriptor: 02 14 00 26 2a
[00:11:22:33:44:55][LE]> char-read-hnd 14
Characteristic value/descriptor: 46 69 72 6d 77 61 72 65 20 52 65 76 69 73 69 6f 6e
[00:11:22:33:44:55][LE]> char-read-hnd 15
Characteristic value/descriptor: 02 16 00 27 2a
[00:11:22:33:44:55][LE]> char-read-hnd 16
Some of them like for example 4d 61 6e 75 66 61 63 74 75 72 65 72 20 4e 61 6d 65 reads Manufacturer Name letter by letter when converted with HEX to ASCII converter but some of them like for example 02 1c 00 2a 2a read ** with some blank squares
I also tried converting to decimal some of the numbers to try to get a temperature value but with no luck.
The values stay the same every time I read them so I guess this is no way to read the temperature value.
Do I have to somehow request that data from those handles. How do I find the termperature value from this data that I have above?
While I was reading this temperature was from 19.8 to 20.2°C, something like that (in case it is hidden somewhere in those values I have listed above)
I just want to read out the temperatur value from it nothing else.
UPDATE:
After turning scan on on bluetoothctl I am getting this packets from bluetooth thermometer:
[CHG] Device 00:11:22:33:44:55 RSSI: -81
[CHG] Device 00:11:22:33:44:55 TxPower: 0
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 43 01 75 04 f3 5b ..^.....$.C.u..[
01 00 ..
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 23 0c 43 01 79 04 02 5c ..^.....#.C.y..\
01 00 ..
[CHG] Device 00:11:22:33:44:55 RSSI: -63
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00 .#..
[CHG] Device 00:11:22:33:44:55 RSSI: -81
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 44 01 75 04 22 5c ..^.....$.D.u."\
01 00 ..
[CHG] Device 00:11:22:33:44:55 RSSI: -54
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00
Lets take the first set of data:
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 43 01 75 04 f3 5b ..^.....$.C.u..[
01 00
I noticed by skipping the first 2 Bytes 55 44 33 22 11 00 MAC address of the device but in reverse.
After that 24 0c part repeats simiraly in other sets like for example in next one its 23 0c.
The next 2 Bytes (43 01) are the ones that I noticed change when temperature in my room changes and are the bytes that represent the temperature. Here is how I calculated temperature. Reverse the byte order -> 01 43 -> 0x0143 -> 323 in decimal -> 323/16 -> 20.1875 which is 20.2 rounded up. This is the exact temp that is on my thermometer and I tried it when temp was higher and lower and it always shows the exact temp.
Similarly the next two 75 04: 0x0475 -> 1141 in decimal -> 1141/16 = 71.3125 which is 71% rounded down -> humidity shown on thermometer
Is this the right interpretation?
What confuses me is the 3rd set of data which is longer and the data packets alternate between those two:
[CHG] Device 00:11:22:33:44:55 RSSI: -63
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00
Is that some other data that thermometer is sending?
As a side note, gatttool is deprecated and the current supported tool for doing this is bluetoothctl.
GATT UUID's with the format 0000xxxx-0000-1000-8000-00805f9b34fb mean they have been adopted by the Bluetooth SIG and you can look up what they represent in the 16-bit UUID Numbers Document
There are also generic Bluetooth Low Energy scanning and exploration tools such as nRF connect that can be helpful exploring a device.
From the GATT information you posted, I could only see generic content that needs to be included and not anything specific about temperature.
The advertising data is including Manufacturer Data which can (as maybe the name suggests) be anything that the manufacturer wants. From the Core Specification Supplement
This means you need to get the information from the manufacturer or work backwards from what you think the data is saying. As you have not shared any information about the device broadcasting, it seems like you are heading in the right direction.
Most Bluetooth data is little endian so having to swap the bytes around is not unexpected. Beacon formats like iBeacon and Eddystone tend to be big endian but they are the exception rather than the rule.
You will probably want to use the D-Bus API if you want to get the data into some kind of code. There are D-Bus bindings for most languages and the BlueZ API you will need is documented at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt
Related
I'm trying to communicate with an ACR122U nfc reader using Qt 5.15.2 and neard 0.18 on Ubuntu 22.04 by running the code below but nothing happen when presenting a tag. Slots never get called and no error is printed.
NFCHandler::NFCHandler(QObject *parent)
: QObject{parent}
{
manager = new QNearFieldManager(this);
if (!manager->isAvailable()) {
qWarning() << "NFC not available";
return;
}
connect(manager, &QNearFieldManager::targetDetected,
this, &NFCHandler::targetDetected);
connect(manager, &QNearFieldManager::targetLost,
this, &NFCHandler::targetLost);
manager->setTargetAccessModes(QNearFieldManager::NdefReadTargetAccess);
if (!manager->startTargetDetection()) {
qWarning() << "Starting detection failed during startup";
}
}
I enabled qt.nfc.neard logging category which print:
qt.nfc.neard: org.neard.Adapter found for path "/org/neard/nfc0"
qt.nfc.neard: starting target detection
qt.nfc.neard: adapter is already powered
qt.nfc.neard: successfully started polling
And this when stopping:
qt.nfc.neard: stopping target detection
qt.nfc.neard: successfully stopped polling
I noticed there was an error in dmesg. After enabling debug prints this is what i get from dmesg -x (Not all messages are included):
kern :debug : [20439.162016] usb 1-6: Sending command 0x32
kern :debug : [20439.162020] usb 1-6: __pn533_send_async Queueing command 0x32
kern :debug : [20439.162022] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20439.162024] PN533 TX: 32 01 02
kern :debug : [20439.171701] PN533 RX: 83 04 00 00 00 00 00 02 81 00 d5 33 90 00
kern :debug : [20439.185997] usb 1-6: pn533_wq_poll cancel_listen 0 modulation len 0
kern :debug : [20439.186018] usb 1-6: pn533_send_poll_frame mod len 0
kern :debug : [20439.186021] usb 1-6: Sending command 0x56
kern :debug : [20439.186024] PN533 TX: 6b 2a 00 00 00 00 00 00 00 00 ff 00 00 00 25 d4
kern :debug : [20439.186025] PN533 TX: 56 01 02 07 00 ff ff 00 03 01 fe c6 17 05 76 26
kern :debug : [20439.186026] PN533 TX: 95 ff ff 46 66 6d 01 01 11 04 01 96 03 02 00 01
kern :debug : [20439.186027] PN533 TX: 02 02 07 ff
kern :debug : [20439.530001] PN533 RX: 83 05 00 00 00 00 00 02 81 00 d5 57 01 90 00
kern :debug : [20439.530079] usb 1-6: Sending command 0x32
kern :debug : [20439.530101] usb 1-6: __pn533_send_async Queueing command 0x32
kern :debug : [20439.530102] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20439.530103] PN533 TX: 32 01 02
kern :debug : [20439.539773] PN533 RX: 83 04 00 00 00 00 00 02 81 00 d5 33 90 00
kern :debug : [20439.554018] usb 1-6: pn533_wq_poll cancel_listen 0 modulation len 0
kern :debug : [20439.554022] usb 1-6: pn533_send_poll_frame mod len 0
kern :debug : [20439.554025] usb 1-6: Sending command 0x8c
kern :debug : [20439.554028] PN533 TX: 6b 3d 00 00 00 00 00 00 00 00 ff 00 00 00 38 d4
kern :debug : [20439.554029] PN533 TX: 8c 02 01 01 00 00 00 40 01 fe 4c f0 e7 db 21 5c
kern :debug : [20439.554030] PN533 TX: 00 00 00 00 00 00 00 00 ff ff 01 fe 4c f0 e7 db
kern :debug : [20439.554031] PN533 TX: 21 5c 00 00 11 46 66 6d 01 01 11 04 01 96 03 02
kern :debug : [20439.554045] PN533 TX: 00 01 02 02 07 ff 00
kern :debug : [20441.570323] usb 1-6: Listen mode timeout
kern :debug : [20441.590175] usb 1-6: pn533_wq_poll cancel_listen 1 modulation len 2
kern :debug : [20441.590180] usb 1-6: pn533_send_poll_frame mod len 2
kern :debug : [20441.590182] usb 1-6: Sending command 0x4a
kern :debug : [20441.590184] usb 1-6: __pn533_send_async Queueing command 0x4a
kern :debug : [20444.691762] PN533 RX: 83 00 00 00 00 00 00 02 fe 00
kern :err : [20444.691817] usb 1-6: NFC: Received an invalid frame
kern :err : [20444.691903] usb 1-6: NFC: pn533_poll_complete Poll complete error -5
kern :err : [20444.691918] usb 1-6: NFC: Error -5 when running poll
kern :err : [20444.691925] usb 1-6: NFC: Polling operation has been stopped
kern :debug : [20444.691940] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20444.691946] PN533 TX: 4a 01 00
kern :debug : [20444.787575] PN533 RX: 83 05 00 00 00 00 00 02 81 00 d5 4b 00 90 00
kern :debug : [20444.787652] usb 1-6: Polling has been stopped
According to https://www.usb.org/sites/default/files/DWG_Smart-Card_CCID_Rev110.pdf the invalid frame is a RDR_to_PC_Escape message. The error message "NFC: Received an invalid frame" is caused by the pn533/usb.c file in the pn533 driver because data length is 0 (the 4 bytes after 83).
Am I doing something wrong with the code ?
Could the product be deficient ?
I'm running bluez 5.50 on a Raspberry Pi (both Buster and Stretch). I have a ble sensor device that advertises data only when a button on the sensor device is pressed. So advertisements are asynchronous and there are no periodic advertisements in between (and all packets are unique, no duplicates). I'm having an issue with Bluez though where once a packet is received, Bluez seems to not report any additional packets from the device for the next approximately 11 seconds (very occasionally the interval is shorter). This is with the bluetoothctl line command tool as well as my own c++ application (based off the bluez client/main.c example). In both cases before starting a scan I clear the scan filter, set transport to le, and set duplicate-data reporting on. Conversely, when running hcitool scan I see all the packets from the sensor (it even seems to be reporting all 3 copies broadcast on the different advertisement channels). So my question is, is there a way to get those missing advertisements through the dbus api, possibly some additional setting somewhere? If not, is the hci api okay to use from c++ and should it do the trick? Any help appreciated, thanks!
Edited per Alex's questions -
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Not yet, just wanted to check and see if this might be something known beforehand.
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
hcitool lescan (under root), and yes, the hardware is a Pi Zero/W and a P3 so BLE 4.x controllers (I assume)
Have you tried running sudo btmon to see all of the HCI communication during scanning?
I have but can't remember exactly what I saw other than it didn't contradict anything else, i.e. missing packets w/ dbus api vs hci
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
always exactly as you've noted...
Could you also provide the results of hciconfig -a
--- Results (P Zero) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:79:2E:3F ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:55476 acl:126 sco:0 events:2012 errors:0
TX bytes:6956 acl:114 sco:0 commands:444 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi01'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
--- Results (P3) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:2B:A2:A3 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:10995 acl:0 sco:0 events:390 errors:0
TX bytes:2145 acl:0 sco:0 commands:91 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi02'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
Below is a scan covering about 20 seconds (editing out all unrelated packets),
where I'm pressing down the button on the sensor about every 2 seconds and then
holding it down for another 2 seconds before letting it up. The first chunk
is from bluetoothctl, the second from "hcidump --raw" (on a second raspberry pi). The first four bytes
in the bluetoothctl packet data is a little endian packet seq number
incremented by the sensor for each new packet. The next byte indicates a
button up/down action. You can see bluetoothctl reported packets numbered 05df,
05e5, 05e9. In the raw dump the seq number is at the end of the top line. There
you can see all packets are in order, reported 1 to 3 times (I assume it is
reporting all advertising channels it catches). All packets are present 05df to
05e9 in the hcidump scan. Lastly is the output from "hcitool lescan --duplicates",
which I'm not really sure how it maps...
------ bluetoothctl
.
[NEW] Device E2:15:00:01:73:96 E2-15-00-01-73-96
[CHG] Device E2:15:00:01:73:96 RSSI: -46
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
df 05 00 00 10 a1 ac 8a b4 .........
[CHG] Device E2:15:00:01:73:96 RSSI: -45
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e5 05 00 00 10 e7 4f 67 6e ......Ogn
.
[CHG] Device E2:15:00:01:73:96 RSSI: -65
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e9 05 00 00 10 f4 f9 f8 7d ........}
---------- hcidump --raw
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 C3
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E0 05
00 00 11 11 0F 3E 24 B6
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 CF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A BF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A B8
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E3 05
00 00 10 E2 29 C7 F7 BB
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E5 05
00 00 10 E7 4F 67 6E CA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E7 05
00 00 10 2D 52 48 C2 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E9 05
00 00 10 F4 F9 F8 7D BC
------- hcitool lescan --duplicates
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
Have you tried running sudo btmon to see all of the HCI communication during scanning?
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
Could you also provide the results of hciconfig -a
Handling of duplicate advertising data with the BlueZ D-Bus API is an on-going saga that is complicated by the fact that both the kernel and user-space are involved. The following thread over on the BlueZ developer mailing list probably gives the best insight: https://marc.info/?l=linux-bluetooth&m=158225950522806&w=2
The workaround I have been using with the D-Bus API, when scanning for beacons, is to remove the device once I have the data from it. I don't appear to miss data this way. As I don't connect to the beacons, I don't need to worry about losing the paring data for that device.
As a side note, tools like hciconfig, hcitool, and hcidump were deprecated back in 2017
I want to use my computer as an iBeacon, and I don't succeed (On a Ubuntu 14.04 running in a virtualBox environement on Windows 8.1)
Here is the code I use
#!/bin/bash
sudo hciconfig hci0 up
sudo hciconfig hci0 noleadv
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 \
d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
sudo hciconfig hci0 leadv
My hciconfig result
hci0: Type: BR/EDR Bus: USB
BD Address: 00:C2:C6:18:C5:E9 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:5333127 acl:66 sco:0 events:887454 errors:0
TX bytes:40617442 acl:64 sco:0 commands:887224 errors:0
I have the bluez version 5.36 installed (checked with bluetoothd -v)
I have seen many Stack overflow post about this but cannot figure it out!
Check Here, Here or Here.
I have bought a real iBeacon to look about what works to help me, here is what I have:
Using hcidump -R I read this
< 01 0B 20 07 01 10 00 10 00 00 00
> 04 0E 04 01 0B 20 00
< 01 0C 20 02 01 01
> 04 0E 04 01 0C 20 00
> 04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
> 04 3E 2A 02 01 04 01 4F 00 00 02 4D CD 1E 02 0A F4 08 16 F0
FF 64 00 00 00 00 11 09 4D 69 6E 69 42 65 61 63 6F 6E 5F 30
30 30 37 39 BB
> 04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
> 04 3E 2A 02 01 04 01 4F 00 00 02 4D CD 1E 02 0A F4 08 16 F0
FF 64 00 00 00 00 11 09 4D 69 6E 69 42 65 61 63 6F 6E 5F 30
30 30 37 39 BB
< 01 0C 20 02 00 01
> 04 0E 04 01 0C 20 00
Problem is I don't understand why there so much different paquet size and type (maybe other bluetooth nonBeacon device).
I'm pretty sure that this is the beacon paquet, but theses data make no sense to me
04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
I have trying to use this to understand it but failed (using some stack overflow responses like the following)
First, in order to get BlueZ to advertise, the byte sequence you supply must include a valid BLE advertisement header, which is a minimum of 8 bytes. So to advertise "helloworld" you actually need to send:
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.
The first 8 bytes can be broken down like this:
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
---------------------
If you got anything that can help me to understand how iBeacon paquet are constructed, thank you
Oh Gosh! I have found someone with exactly the same problem as me.
Look Here.
Response that helped from #Richard Wifall
I saw the same issue as memoryhole where I had to remove the extra zeros. I also had to enable advertising before I configured the advertising data for it to work properly with my dongle.
Here is the exact sequence/commands that worked for me:
sudo hciconfig hci0 up
sudo hciconfig hci0 leadv 3
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00
This is what my version of the Radius script ended up looking like:
#!/bin/sh
../ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
sudo hcitool -i $BLUETOOTH_DEVICE cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 $UUID $MAJOR $MINOR $POWER 00
echo "Complete"
This was on a Rasberry Pi with a ORICO BTA-402-BK branded BLE dongle (CSR8510 A10)
(I would have left this as a comment, but didn't have enough rep)
I have an iBeacon broadcasting every ~1280 ms from my Raspberry Pi, but I need it to broadcast every ~100ms how do I configure this?
How I'm set up:
I followed this guide:
http://www.wadewegner.com/2014/05/create-an-ibeacon-transmitter-with-the-raspberry-pi/
I have a Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
My config string:
hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 63 6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 00 00 00 00 C8 00
On my phone I see my iBeacon, the UUID is correct, the Major and Minor versions are correct. The problem I'm having is the broadcast rate.
Can I change this from ~1.2 seconds to ~100 ms?
Update 1:
I'm still getting errors.
pi#raspberrypi ~ $ sudo hciconfig hci0 up
pi#raspberrypi ~ $ sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 44
1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60
D0 F5 A7 10 96 E0 00 00 00 00 C5 00 00 00 00 00 00 00 00 00
00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 12
pi#raspberrypi ~ $ sudo hcitool -i hci0 cmd 0x08 0x0006 A0 00 A0 00 03 00 00 00 00 00 00 00 00 07 00
< HCI Command: ogf 0x08, ocf 0x0006, plen 15
A0 00 A0 00 03 00 00 00 00 00 00 00 00 07 00
> HCI Event: 0x0e plen 4
01 06 20 0C
pi#raspberrypi ~ $ sudo hcitool -i hci0 cmd 0x08 0x000a 01
< HCI Command: ogf 0x08, ocf 0x000a, plen 1
01
> HCI Event: 0x0e plen 4
01 0A 20 0C
Update 2:
I found a way to make it work:
hciconfig hci0 down
hciconfig hci0 up
hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 63 6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 00 00 00 00 C8 00
hcitool -i hci0 cmd 0x08 0x0006 20 00 A0 00 00 00 00 00 00 00 00 00 00 07 00
hcitool -i hci0 cmd 0x08 0x000A 01
hciconfig hci0 noscan
I think the key was the noscan part. I think if scan was on I couldn't change the advertisement frequency.
An additional resource I found useful:
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737
Specifically Volume 2, Part E, Section 7.8 This gave me the actual description of the commands I was sending, instead of copy and paste programming.
You can increase the advertising rate to 10 Hz like this:
sudo hciconfig hci0 up
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
sudo hcitool -i hci0 cmd 0x08 0x0006 A0 00 A0 00 03 00 00 00 00 00 00 00 00 07 00
sudo hcitool -i hci0 cmd 0x08 0x000a 01
See here for more info:
Is there a way to increase BLE advertisement frequency in BlueZ?
I tried to follow the steps provided by davidgyoung in this question. Here are the commands I use:
hciconfig hci0 up
hciconfig hci0 noleadv
hcitool -i hci0 cmd 0x08 0x0008 48 45 4c 4c 4f 57 4f 52 4c 44
hciconfig hci0 leadv
Which gives me this output:
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 10
48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
Note that I can't use the advised command hciconfig hci0 leadv 0 because it will throw the error Warning: unknown command - "0".
However, when I try to read out (e.g. with a hcidump --raw) the payload in the advertised package from another device I'm getting an output like this:
hcitool lescan -- duplicates output snippet (both entries are repeated over and over again, looking at the MAC it should be the same device, though):
00:1A:7D:DA:71:14 mint17-0
00:1A:7D:DA:71:14 (unknown)
matching hcidump --raw output snippet:
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74 31 37 2D 30 BE
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08 AD
I'm using Bluez 5.26 and CSR4.0 dongles.
This is the hciconfig output of the advertisier:
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:14 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1242 acl:0 sco:0 events:77 errors:0
TX bytes:2079 acl:0 sco:0 commands:77 errors:0
And this is the hciconfig output from the 'scanner':
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:11753 acl:0 sco:0 events:552 errors:0
TX bytes:1842 acl:0 sco:0 commands:75 errors:0
What did I miss to get it to work?
Update:
Following David's advice I changed the cmd values to
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
getting this output
< HCI Command: ogf 0x08, ocf 0x0008, plen 18
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
but still gibberish payloads (payload portion of the hcidump --raw output)
af:08:0a:02:02:01:02
b7:08:0a:02:02:01:02
be:08:0a:02:02:01:02
...
Update 2:
Following the next advice I tried adding some 00 to the payload:
< HCI Command: ogf 0x08, ocf 0x0008, plen 42
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
> HCI Event: 0x0e plen 4
01 08 20 12
And here the hcidump --raw output
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AC
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
BF
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AD
So still no joy.
Would it make sense to try a different (maybe older) version of bluez? Or can it be hardware related and I should try to get different Bluetooth dongles?
Update 3:
Tried the same with bluez 5.21 which works for David.
Here's a snippet of the hcidump --raw output
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D7
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D4
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D4
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D2
The hostname has changed (tested on the third machine so far), so the output is a bit different but I still don't see 'hello world' anywhere.
At this point any ideas are more than welcome!
Update 4:
Tried a different hardware dongle (IOGEAR GBU521W6 as suggested by David) and this looks very promising now!
When using this advertising config:
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
I get this hcidump --raw output:
> 04 3E 1C 02 01 00 00 BA D0 63 70 F3 5C 10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C B5
As you can see the payload is almost complete, but the last char is missing. By changing the length attribute to 11 I get the full payload:
hcitool -i hci0 cmd 0x08 0x0008 11 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
----
> 04 3E 1D 02 01 00 00 BA D0 63 70 F3 5C 11 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 AB
So for the future (and different payloads): the required length seems to be the bytes of the payload (without the length attribute) - 17 in this case.
Important: It does not work with bluez 5.26 for me, I'm using bluez 5.21 now.
Two issues:
First, in order to get BlueZ to advertise, the byte sequence you supply must include a valid BLE advertisement header, which is a minimum of 8 bytes. So to advertise "helloworld" you actually need to send:
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.
The first 8 bytes can be broken down like this:
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
Note that this header contains two different length fields that you must adjust if you change the length of the "helloworld" payload. Also, for experimentation purposes, you are welcome to use any two bytes for the company identifier that you want.
Second, you can't see the raw bytes of a detected advertisement with the hcitool lescan command. To see the raw bytes, you have to use this command in combination with the hcidump command. See here for details: https://stackoverflow.com/a/21790504/1461050