Skip to content

BLECharacteristic::subscribe() fails with iTag #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
gdsports opened this issue Sep 2, 2019 · 9 comments
Open

BLECharacteristic::subscribe() fails with iTag #20

gdsports opened this issue Sep 2, 2019 · 9 comments
Labels
type: imperfection Perceived defect in any part of project

Comments

@gdsports
Copy link

gdsports commented Sep 2, 2019

My BLE central iTag program based on the SensorTag example fails at the simpleKeyCharacteristic.subscribe() step. I "fixed" the problem as shown below. The characteristics properties are not available at this point but I assume the correct way to handle this is to check for BLEWrite versus BLEWriteWithoutResponse. Without this change the subscribe() blocks for a few seconds then returns an error.

int BLERemoteDescriptor::writeValue

#if 0
  uint8_t resp[4];
  int respLength = ATT.writeReq(_connectionHandle, _handle, value, length, resp);

  if (!respLength) {
    return 0;
  }

  if (resp[0] == 0x01) {
    // error
    return 0;
  }

#else
  ATT.writeCmd(_connectionHandle, _handle, value, length);
#endif
@sandeepmistry
Copy link
Contributor

Hi @gdsports,

Do you think you could provide some debug logging for this. Please add BLE.debug(Serial); in the setup() of your sketch and provide the output of the Serial Monitor. Thanks.

@gdsports
Copy link
Author

gdsports commented Sep 3, 2019

Ok, here is the log without code changes.

12:45:57.333 -> HCI EVENT RX <- 043E1A0201000039080B00FFFF0E020105020A000319C1030302E0FFB4
12:45:57.399 -> HCI EVENT RX <- 043E1E0201040039080B00FFFF12110969544147202020202020202020202020BE
12:45:57.465 -> Discovered a peripheral
12:45:57.465 -> -----------------------
12:45:57.465 -> Address: ff:ff:00:xx:yy:zz
12:45:57.465 -> Local Name: [iTAG            ]
12:45:57.465 -> Service UUIDs: ffe0 
12:45:57.465 -> RSSI: -66
12:45:57.465 -> 
12:45:57.465 -> HCI COMMAND TX -> 010C20020000
12:45:57.498 -> HCI EVENT RX <- 040E04010C2000
12:45:57.532 -> Found iTag
12:45:57.532 -> Connecting ...
12:45:57.532 -> HCI COMMAND TX -> 010D201960003000000039080B00FFFF0006000C000000C80004000600
12:45:57.598 -> HCI EVENT RX <- 040F0400010D20
12:45:57.730 -> HCI EVENT RX <- 043E1301000000000039080B00FFFF08000000C80007
12:45:57.764 -> Connected ff:ff:00:xx:yy:zz 
12:45:57.764 -> Connected
12:45:57.764 -> Discovering service 0xffe0 ...
12:45:57.797 -> HCI ACLDATA TX -> 02000007000300040002F700
12:45:57.947 -> HCI EVENT RX <- 0413050100000100
12:45:57.947 -> HCI ACLDATA RX <- 020020070003000400031700
12:45:57.947 -> HCI ACLDATA TX -> 0200000B0007000400100100FFFF0028
12:45:57.947 -> HCI EVENT RX <- 0413050100000100
12:45:57.947 -> HCI ACLDATA RX <- 0200201800140004001106010005000018060008000F1809000B000218
12:45:57.947 -> HCI ACLDATA TX -> 0200000B0007000400100C00FFFF0028
12:45:57.947 -> HCI EVENT RX <- 0413050100000100
12:45:57.996 -> HCI ACLDATA RX <- 0200200C000800040011060C000E00E0FF
12:45:58.029 -> HCI ACLDATA TX -> 0200000B0007000400100F00FFFF0028
12:45:58.095 -> HCI EVENT RX <- 0413050100000100
12:45:58.128 -> HCI ACLDATA RX <- 02002009000500040001100F000A
12:45:58.128 -> HCI ACLDATA TX -> 0200000B0007000400080C000E000328
12:45:58.194 -> HCI EVENT RX <- 0413050100000100
12:45:58.194 -> HCI ACLDATA RX <- 0200200D000900040009070D00120E00E1FF
12:45:58.261 -> HCI ACLDATA TX -> 0200000B0007000400080F000E000328
12:45:58.294 -> HCI EVENT RX <- 0413050100000100
12:45:58.327 -> HCI ACLDATA RX <- 02002009000500040001080F000A
12:45:58.327 -> Service discovered
12:45:58.360 -> Subscribing to simple key characteristic ...
12:45:58.360 -> HCI ACLDATA TX -> 020000090005000400120F000100
12:45:58.393 -> HCI EVENT RX <- 0413050100000100
12:46:03.361 -> subscription failed!
12:46:03.394 -> HCI COMMAND TX -> 01060403000013
12:46:03.427 -> HCI EVENT RX <- 040F0400010604
12:46:03.427 -> HCI EVENT RX <- 04050400000016
12:46:03.461 -> Disconnected ff:ff:00:xx:yy:zz 
12:46:03.461 -> HCI COMMAND TX -> 010C20020001
12:46:03.461 -> HCI EVENT RX <- 040E04010C2000
12:46:03.494 -> HCI COMMAND TX -> 010B200701100010000000
12:46:03.527 -> HCI EVENT RX <- 040E04010B2000
12:46:03.527 -> HCI COMMAND TX -> 010C20020101
12:46:03.560 -> HCI EVENT RX <- 040E04010C2000
12:46:03.560 -> HCI COMMAND TX -> 010A200101
12:46:03.593 -> HCI EVENT RX <- 040E04010A2000
12:46:04.388 -> HCI COMMAND TX -> 010C20020001
12:46:04.421 -> HCI EVENT RX <- 040E04010C2000
12:46:04.454 -> HCI COMMAND TX -> 010B200701100010000000
12:46:04.487 -> HCI EVENT RX <- 040E04010B2000
12:46:04.521 -> HCI COMMAND TX -> 010C20020101
12:46:04.521 -> HCI EVENT RX <- 040E04010C2000

@sandeepmistry
Copy link
Contributor

Thanks @gdsports,

Have you tested the peripheral with other centrals like iOS or Android? Do they work when subscribing?

It seems macOS and iOS will send a write request as this library does.

@gdsports
Copy link
Author

gdsports commented Sep 3, 2019

gatttool running on a raspberry pi works with the iTag. And light blue on IOS.

@gdsports
Copy link
Author

gdsports commented Sep 3, 2019

I got an old SensorTag based on the CC2541 working with a small change to the
SensorTag example sketch. The localName is slightly different. Works fine without
changing BLERemoteDescriptor::writeValue.

--- a/examples/Central/SensorTagButton/SensorTagButton.ino
+++ b/examples/Central/SensorTagButton/SensorTagButton.ino
@@ -51,7 +51,10 @@ void loop() {
 
     // Check if the peripheral is a SensorTag, the local name will be:
     // "CC2650 SensorTag"
-    if (peripheral.localName() == "CC2650 SensorTag") {
+    // For very old SensorTags based on the CC2541, the local name will be
+    // "SensorTag"
+    String local_name = peripheral.localName();
+    if ((local_name == "CC2650 SensorTag") || (local_name == "SensorTag")) {
       // stop scanning
       BLE.stopScan();

@mockendon
Copy link

Found this bug report while trying to understand why the only thing I can get to accept a .subscribe request is a very old devkit TI keyfob. That works perfectly but nothing else (physical or virtual) will accept a request to subscribe using the arduinoBLE library on my Nano 33 IoT.

gsports 'fix' for int BLERemoteDescriptor::writeValue (I'm assuming is to be added to BLERemoteCharacteristic.cpp) is a great idea but didn't help me.

Is there an authentication problem in the library?

@sandeepmistry
Copy link
Contributor

Is there an authentication problem in the library?

@mockendon Currently authentication is not supported in this library. #36 is open to track that feature.

@mockendon
Copy link

Thank you sandeepmistry! I had assumed the authentication that was missing was for pin codes and encryption. It all becomes clear!

@willtmakinen78 willtmakinen78 mentioned this issue May 1, 2020
Open
@per1234 per1234 added the type: imperfection Perceived defect in any part of project label Mar 9, 2021
@Jamal-Nazzal
Copy link

has this been solved ever?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: imperfection Perceived defect in any part of project
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@sandeepmistry @per1234 @mockendon @gdsports @Jamal-Nazzal