I have a Raspberry Pi 3 running the latest Raspbian, and I have
upgraded bluez from 5.23. to 5.43. I am attempting to connect to BLE
devices that advertise at 2 second interval. I wrote some code based
on gatttool and attempted to connect to these devices. I run into the
LE connect request being cancelled after 2 seconds. Thus I get a LE Connection Complete messages with a status of 0x02 (Unknown Connection Identifier)
From my research I ran across this from about 15 months ago in the archives,
https://www.spinics.net/lists/linux-bluetooth/msg65434.html
However after following the threads, I did not see if a resolution was found.
I have ran tests with my code, the gatttool utility and well as using
bluetoothctl. I see the same type of activity in btmon that is listed
below:
HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 [hci0] 21:45:51.917070
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.917819
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.918357
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 27 [hci0] 21:45:52.597503
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: D3:67:2D:D1:46:46 (Static)
Data length: 15
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: FedEx Services (321)
Data: 070a111080d28004
RSSI: -63 dBm (0xc1)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:52.599626
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
HCI Event: Command Status (0x0f) plen 4 [hci0] 21:45:52.600508
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:54.684146
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 21:45:54.684361
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
Handle: 64
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: D3:67:2D:D1:46:46 (Static)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
# Connect Failed: D3:67:2D:D1:46:46 (2) status 0x02
It looks like there is a 2 second timeout somewhere in the code, perhaps kernel side.
One thing to note is if I use hcitool to connect, I am able to connect
most all of the time. I know this is not the L2CAP layer, but I can
see that I am able to connect.
Also, if I change the advertising interval of the BLE devices to 1 second. I can connect just fine. (Reason for 2 sec advertising interval is power savings)
Has anyone recently ran into this issue, and if so has there been any resolution?
Thanks
Having the same issue. Reducing the advertisement interval, as you've noted, from 10s to 0.5s does fix the issue. I, also, need a longer interval to conserve battery. I know that using an older build of Raspbian ( 2016-03-18-raspbian-jessie kernel 4.1.19-v7+ #858 SMP, bluez 5.23 ) works fine, however, I have yet to get a newer build to work.
UPDATE
After discovering this post: https://www.spinics.net/lists/linux-bluetooth/msg67800.html I changed the following values in include/net/bluetooth/hci.h:
#define HCI_LE_CONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */
#define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */
recompiled, and all is working now with a 10.24 second broadcast interval from my device on the latest version of Raspbian kernel 4.4.50 with bluez 5.45. Hope this helps.
As Troy E. Lanes noted, this is due to a short HCI_LE_AUTOCONN_TIMEOUT defined in the kernel. If the timeout expired after LE Create Connection command is sent, the host sends command LE Create Connection Cancel.
But you can change timeout value without recompiling the kernel. I made a tool to change LE autoconnect timeout https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
Related
I have been trying out the bluez btmon tool to monitor the bluetooth discovery result on my raspberry pi 4.
The btmon tool returns stdout which is the following:
# MGMT Event: Device Found (0x0012) plen 42 {0x0001} [hci0] 0.207973
LE Address: 61:E1:E1:49:C8:DC (Resolvable)
RSSI: -51 dBm (0xcd)
Flags: 0x00000004
Not Connectable
Data length: 28
16-bit Service UUIDs (complete): 1 entry
Google (0xfe9f)
Service Data (UUID 0xfe9f): 0000000000000000000000000000000000000000
# MGMT Event: Device Found (0x0012) plen 33 {0x0001} [hci0] 0.224956
LE Address: 48:82:8F:DB:5C:65 (Resolvable)
RSSI: -76 dBm (0xb4)
Flags: 0x00000000
Data length: 19
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 5 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 491faeca8c8638
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.298194
LE Address: 0E:AF:D9:F0:D8:F1 (Non-Resolvable)
RSSI: -68 dBm (0xbc)
Flags: 0x00000004
Not Connectable
Data length: 29
Company: Microsoft (6)
Data: 0109210a065124d7b5c04445534b544f502d44484845413434
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.940219
LE Address: 86:2A:FD:9E:57:0D (OUI 86-2A-FD)
RSSI: -77 dBm (0xb3)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Service Data (UUID 0xfdf7): 01384a3dd6381b593c74d9369eefaa9b720000000003
Been looking for some official docs on explaining the field "Flags" in each discovered device info (those flag codes: 0x00000004, 0x00000000, 0x1a, 0x06), but I couldn't seem to find one that makes sense.
Would really appreciate if anyone could explain what does the Flags tell, and how to make sense of these codes?
Thanks in advance.
I don't know what you call "official docs", but the Bluetooth Core Specification and the Supplement to the Bluetooth Core Specification certainly explains it. Have a look at chapter 1.3 FLAGS of CSS
In the log you showed, you can see the advertising data of several Bluetooth LE devices. Each of this advertising data contains one ore more fields called AD Types. One of the AD Types is the "Flags" field. It may be zero or more octets long, with the first octet containing the following information:
Octet
Bit
Description
0
0
LE Limited Discoverable Mode
0
1
LE General Discoverable Mode
0
2
BR/EDR Not Supported. Bit 37 of LMP Feature Mask Definitions (Page 0)
0
3
Simultaneous LE and BR/EDR to Same Device Capable (Controller). Bit 49 of LMP Feature Mask Definitions (Page 0)
0
4
Previously Used
0
5..7
Reserved for future use
The given information tells you something about the used Bluetooth radio and about the advertising itself. If you are interested in a deeper understanding of this topic, I recommend reading this Bluetooth blog article: Advertising Works, Part 1
In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.
The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.
With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.
Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed. I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.
Using the DBus API (or bluetoothctl) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)
Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.
For example, running
btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1
to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:
< HCI Command:... (0x08|0x0036) plen 25 #631 [hci0] 5676.358401
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5 #632 [hci0] 5676.359321
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6 #633 [hci0] 5676.359410
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 2000 ms (0xc8)
Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4 #634 [hci0] 5676.361330
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
# MGMT Event: Com.. (0x0001) plen 4 {0x0003} [hci0] 5676.361372
Add Advertising (0x003e) plen 1
Status: Success (0x00)
Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6 #635 [hci0] 5676.362333
LE Advertising Set Terminated (0x12)
Status: Advertising Timeout (0x3c)
Handle: 1
Connection handle: 65535
Number of completed extended advertising events: 0
Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?
This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.
Looking at the source code for btmgmt those flags are now set with the -g, and -l command line switches. Use general discoverable mode to advertise indefinitely.
static void add_adv_usage(void)
{
bt_shell_usage();
print("Options:\n"
"\t -u, --uuid <uuid> Service UUID\n"
"\t -d, --adv-data <data> Advertising Data bytes\n"
"\t -s, --scan-rsp <data> Scan Response Data bytes\n"
"\t -t, --timeout <timeout> Timeout in seconds\n"
"\t -D, --duration <duration> Duration in seconds\n"
"\t -P, --phy <phy> Phy type, Specify 1M/2M/CODED\n"
"\t -c, --connectable \"connectable\" flag\n"
"\t -g, --general-discov \"general-discoverable\" flag\n"
"\t -l, --limited-discov \"limited-discoverable\" flag\n"
"\t -n, --scan-rsp-local-name \"local-name\" flag\n"
"\t -a, --scan-rsp-appearance \"appearance\" flag\n"
"\t -m, --managed-flags \"managed-flags\" flag\n"
"\t -p, --tx-power \"tx-power\" flag\n"
"e.g.:\n"
"\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}
The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing.
It is those 28 bytes that is being set with the -d option of btmgmt.
If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.
There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:
A packet containing an advertising PDU. See [Vol 6]
Part B, Section 2.3.1
More data is section:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT
It has an example for ADV_NONCONN_IND packet type:
PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03
Which starts with the flags data type.
I'm using BlueZ for handling BLE devices. I have compiled it from source, and wrote a wrapper around it.
I'm searching for this tiny bit of information:
What is "LE Read Remote Used Features" command for?
Which features can it read?
Is this mandatory for connecting to a BLE device?
Is it safe to disable querying it after connection?
Is it possible to increase the timeout for the reception of this command's response?
My problem is that my solution works with some devices already (can connect to them), but with a particular device, many times connection fails due to timeout.
I've created a sniff with btmon when the connection fails:
# btmon
Bluetooth monitor ver 5.50
= Note: Linux version 4.19.97-v7l+ (armv7l) 0.742019
= Note: Bluetooth subsystem version 2.22 0.742027
= New Index: AA:BB:CC:DD:EE:FF (Primary,UART,hci0) [hci0] 0.742030
= Open Index: AA:BB:CC:DD:EE:FF [hci0] 0.742033
= Index Info: AA:BB:CC:D.. (Cypress Semiconductor Corporation) [hci0] 0.742035
# MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.742038
# MGMT Open: btmon (privileged) version 1.14 {0x0002} 0.742321
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #1 [hci0] 4.737267
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #2 [hci0] 4.737714
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #3 [hci0] 4.737767
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 4.738160
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 42 #5 [hci0] 6.099681
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: FF:EE:DD:CC:BB:AA
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: 669a0c20-0008-6c91-e411-015500e22ea9
Version: 48661.62728
TX power: -59 dB
RSSI: -78 dBm (0xb2)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #6 [hci0] 6.099747
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #7 [hci0] 6.101862
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #8 [hci0] 6.101916
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: FF:EE:DD:CC:BB:AA
Own address type: Public (0x00)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #9 [hci0] 6.102446
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #10 [hci0] 7.476997
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: FF:EE:DD:CC:BB:AA
Connection interval: 48.75 msec (0x0027)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
# MGMT Event: Device Connected (0x000b) plen 43 {0x0002} [hci0] 7.477047
LE Address: FF:EE:DD:CC:BB:AA
Flags: 0x00000000
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: 669a0c20-0008-6c91-e411-015500e22ea9
Version: 48661.62728
TX power: -59 dB
# MGMT Event: Device Connected (0x000b) plen 43 {0x0001} [hci0] 7.477047
LE Address: FF:EE:DD:CC:BB:AA
Flags: 0x00000000
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: UUID
Version: 48661.62728
TX power: -59 dB
< HCI Command: LE Read Remote Used... (0x08|0x0016) plen 2 #11 [hci0] 7.477210
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #12 [hci0] 7.479342
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 14 #13 [hci0] 7.479357
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
00 00 00 00 00 00 00 00 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 12 #14 [hci0] 7.993969
LE Read Remote Used Features (0x04)
Status: Connection Timeout (0x08)
Handle: 64
Features: 0x2d 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Extended Reject Indication
Slave-initiated Features Exchange
LE Data Packet Length Extension
> HCI Event: Disconnect Complete (0x05) plen 4 #15 [hci0] 7.994591
Status: Success (0x00)
Handle: 64
Reason: Connection Timeout (0x08)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 8.027693
LE Address: FF:EE:DD:CC:BB:AA
Reason: Connection timeout (0x01)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 8.027693
LE Address: FF:EE:DD:CC:BB:AA
Reason: Connection timeout (0x01)
The connection first succeeds, but then my device executes a "LE Read Remote Used Features" HCI Command which times out after 500ms causes the whole connection to fail.
This is my reason for hunting the answers for the questions above.
Answers to all your questions can be found in the Bluetooth Core specification in the Link Layer chapter.
What happens is that the connection drops to the remote device. Bad signal quality? Bad antenna? Bad clock accuracy?
The connection timeout happens after the specified supervision timeout if no packets (possibly empty) are received within this time.
Now it just happens that the first thing BlueZ sends is a remote feature request. If any other packets were sent instead, you'd likely get the same result (connection timeout).
Use a BLE link layer sniffer instead to see what really happens.
I had a similar problem, here are my findings:
What is "LE Read Remote Used Features" command for?
As #Emil pointed out, this command was in the BT Spec, until 5.0. So In BT Spec 4.2 it says:
This command requests a list of the used LE features from the remote device.
This command shall return a list of the used LE features
You need to have an idea on what the Remote is capable of before expecting it to do things right ?
Which features can it read?
After increasing the timeout from 500ms to the upper limit 32000ms the result was
as follows:
Handle: 128
HCI Event: Command Status (0x0f) plen 4
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 11
LE Data Length Change (0x07)
Handle: 128
Max TX octets: 251
Max TX time: 17040
Max RX octets: 251
Max RX time: 17040
HCI Event: LE Meta Event (0x3e) plen 12
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 128
Features: 0x7f 0xfb 0x46 0x07 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
LE Data Packet Length Extension
LL Privacy
LE 2M PHY
Stable Modulation Index - Transmitter
LE Coded PHY
LE Extended Advertising
LE Periodic Advertising
Channel Selection Algorithm #2
LE Power Class 1
Unknown features (0x0000000007460000)
Is it safe to disable querying it after connection?
In my case the culprit was not this command that sabotaged the connection. I'd advice to increase the timeout amount and see what happens.
Is it possible to increase the timeout for the reception of this command's response?
If you were to issue this command separately and if it included such a parameter, then yes why not? In my case it's using what ever Supervision timeout I have provided to the (Extended)Create Connection command.
I am trying to connect a Wahoo Scale 1.3 to read the live weight of a person via bluetooth notifications.
The live weight can be read via the following characteristic:
handle: 0x0025, char properties: 0x10, char value handle: 0x0026, uuid: 00002b01-0000-1000-8000-00805f9b34fb.
This is working with LightBlue app on my iPhone.
When I try to receive notifications via gatttool I get the following error:
Command line gatttool: (tried also lots of different notations from different stack overflow topics)
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x0026 0100
Error: Characteristic Write Request failed: Attribute can't be written
btmon bluetooth log
< ACL Data TX: Handle 0 flags 0x00 dlen 9 [hci0] 4.291021
ATT: Write Request (0x12) len 4
Handle: 0x0026
Data: 0100
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 4.327199
Num handles: 1
Handle: 0
Count: 1
> ACL Data RX: Handle 0 flags 0x02 dlen 9 [hci0] 4.383580
ATT: Error Response (0x01) len 4
Write Request (0x12)
Handle: 0x0026
Error: Write Not Permitted (0x03)
One thing I noticed is that under UUID 1901 (weight service) there are 3 properties: 1: write/indicate, 2: notify, 3: notify.
Bluetooth characteristics on LightBlue App
I am able to write with gatttool to the first property, but not to the 2 and 3 property. But how does LightBlue starts listening for notifications?
I tried this one two different systems:
Beaglebone Black with QN9021 BLE controller (Bluez 5.38, OpenWrt Linux 4.4)
Beaglebone Black WiFi/Bluetooth (Bluez 5.23, Debian Linux 4.4)
Do I get this error because of incompatiblities of the Bluez stack and the Wahoo Scale? How do I fix this?
Thank you!
0x0026 is the handle for the value, not for the descriptor. I would guess the descriptor's handle is 0x0027.
I have the RedBearLab BLE shield connected to Arduino UNO R3. I can connect to it using gatttool from a Rasp-Pi (attached CSR4.0 dongle). I have some sensors (FSR) connected to the analog pin and LED connected to digital pin in Arduino. My goal is to read/write to anything that is connected to the Arduino through BLE.
As a sample, I was looking into this link. It seems I need to know the handle of the sensor, config register # etc. to read/write.But I am not sure how to find the handle/uuid related to the sensor that is attached to the shield.
For example I see below.
[xx:xx:xx:xx:xx:xx][LE]> char-desc
handle: 0x0001, uuid: 2800
handle: 0x0002, uuid: 2803
handle: 0x0003, uuid: 2a00
handle: 0x0004, uuid: 2803
handle: 0x0005, uuid: 2a01
handle: 0x0006, uuid: 2803
handle: 0x0007, uuid: 2a04
handle: 0x0008, uuid: 2800
handle: 0x0009, uuid: 2800
handle: 0x000a, uuid: 2803
handle: 0x000b, uuid: 713d0003-503e-4c75-ba94-3148f18d941e
handle: 0x000c, uuid: 2803
handle: 0x000d, uuid: 713d0002-503e-4c75-ba94-3148f18d941e
handle: 0x000e, uuid: 2902
handle: 0x000f, uuid: 2800
handle: 0x0010, uuid: 2803
handle: 0x0011, uuid: 2a27
Discover descriptors finished: No attribute found within the given range
[xx:xx:xx:xx:xx:xx][LE]> char-read-hnd 0x0001
Characteristic value/descriptor: 00 18
[xx:xx:xx:xx:xx:xx][LE]> char-read-hnd 0x000b
Error: Characteristic value/descriptor read failed: Attribute can't be read
How do I know which of them is the FSR I have attached to the shield?
update
I am using RedBearLab example - simplecontrol
So Arduino and iOS/Android code both are there. My goal is to understand from gatttool's perspective so I can develop something similar (of iOS/Android) in Java running at Raspberry Pi.
From the code, I can figure out which address to write. For example - to turn on the LED attached to the digital out pin, below works
char-write-cmd 0x000b 010100
Similarly, to turn on the sensor reading capability, I need to write below
char-write-cmd 0x000b A00100
I know this works. I see expected output in the Arduino serial monitor. I am pretty sure it is reading the sensor but I can't see that in the RaspPi prompt. I think I need to enable broadcast reading capability at RaspPi end.
Any suggestion?
well, to beging working with BLE, you have to understand how the whole GATT stuff is working. Basically, you need to have some code on your arduino that sets up a profile in the nRF8001 component on your shield that defines "pipes" which is the link between a characteristic exposed by the radio (and seen using the gatttool) and a function from which you can read data or to which you can send data.
To modify and work on gatt profiles, and define those pipes, you need to use the nrfgo tool distributed by Nordic. It's windows only, but it works perfectly fine using wine on OSX or linux (I do it every day).
There you can load a profile and modify it or create a new one, it's up to you. I'd also advice you to look at the nordic examples in their devzone on how to setup a profile for nrf8001 + Arduino, those example are pretty clear.
Then once you've made all your characteristics, you can only read/write the characteristics you're handling. Having a characteristic available does not mean it can be read/written to, you may need to subscribe to it or it may always return an error. Remember that most of the characteristics you list are characteristics used by the gatt for having the whole gatt system work and usually is hidden by libraries abstracting the BLE stuff.