Skip to content

CurieBLE: switchCharacteristic.written() returns incorrect value after first connect #380

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.

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

Closed
sandeepmistry opened this issue Dec 29, 2016 · 10 comments
Milestone

Comments

@sandeepmistry
Copy link
Contributor

I'm trying the following sketch:

#include <CurieBLE.h>

BLEService ledService("19B10000-E8F2-537E-4F6C-D104768A1214"); // BLE LED Service

// BLE LED Switch Characteristic - custom 128-bit UUID, read and writable by central
BLEUnsignedCharCharacteristic switchCharacteristic("19B10001-E8F2-537E-4F6C-D104768A1214", BLERead | BLEWrite);

const int ledPin = 13; // pin to use for the LED

void setup() {
  Serial.begin(9600);

  // set LED pin to output mode
  pinMode(ledPin, OUTPUT);

  // begin initialization
  BLE.begin();

  // set advertised local name and service UUID:
  BLE.setLocalName("LED");
  BLE.setAdvertisedService(ledService);

  // add the characteristic to the service
  ledService.addCharacteristic(switchCharacteristic);

  // add service
  BLE.addService(ledService);

  // set the initial value for the characeristic:
  switchCharacteristic.setValue(0);

  // start advertising
  BLE.advertise();

  Serial.println("BLE LED Peripheral");
}

void loop() {
  // listen for BLE peripherals to connect:
  BLEDevice central = BLE.central();

  // if a central is connected to peripheral:
  if (central) {
    Serial.print("Connected to central: ");
    // print the central's MAC address:
    Serial.println(central.address());

    // while the central is still connected to peripheral:
    while (central.connected()) {
      // if the remote device wrote to the characteristic,
      // use the value to control the LED:
      if (switchCharacteristic.written()) {
        if (switchCharacteristic.value()) {   // any value other than 0
          Serial.println("LED on");
          digitalWrite(ledPin, HIGH);         // will turn the LED on
        } else {                              // a 0 value
          Serial.println(F("LED off"));
          digitalWrite(ledPin, LOW);          // will turn the LED off
        }
      }
    }

    // when the central disconnects, print it out:
    Serial.print(F("Disconnected from central: "));
    Serial.println(central.address());
  }
}

When I connect and disconnect from LightBlue on my Mac the output is as follows:

Connected to central: AC:BC:32:7C:FA:26
LED off
Disconnected from central: AC:BC:32:7C:FA:26

I do not expect the LED off statement, as the central has not written to the characteristic.

@SidLeung
Copy link
Contributor

SidLeung commented Jan 6, 2017

@sandeepmistry Is it possible to use a BLE protocol analyzer to capture the connection activities between the 101 and LiteBlue? Would like to verify that there is no write operation involved here.

Issue is logged as Jira 796

@sandeepmistry
Copy link
Contributor Author

@SidLeung I don't have an analyzer on hand, however I can provide the output from the Xcode hardware IO tools packet logger app if you can't reproduce this. I don't expect LightBlue to send a write request, as I don't see this in v1.0.7.

@sgbihu
Copy link
Contributor

sgbihu commented Jan 20, 2017

Hi @sandeepmistry ,

I have found the root cause. I have a question about the written. In the setup function, I found below code.
// set the initial value for the characeristic: switchCharacteristic.setValue(0);

If you think this write doesn't need trigger the event, I will change the code. The current code save the state when you call setValue.
I think we need define the written triggered condition. Based on your input, you think the written event only triggered by peer device, am I correct?

Thanks!
-Gaoliang

@sandeepmistry
Copy link
Contributor Author

Based on your input, you think the written event only triggered by peer device, am I correct?

That is correct, the v1.0.7 release had this behaviour.

@sandeepmistry
Copy link
Contributor Author

Another user has reported this on the forum: http://forum.arduino.cc/index.php?topic=443728.msg3085664#msg3085664

sgbihu added a commit to sgbihu/corelibs-arduino101 that referenced this issue Feb 6, 2017
…first connect

1. Not set the flage when local device try to set the value.
2. Changed file
    libraries/CurieBLE/src/internal/BLECharacteristicImp.cpp
@SidLeung
Copy link
Contributor

SidLeung commented Feb 8, 2017

Resolution to this issue has passed code review, system testing, and merge to the main trunk. Will be available in the next nightly JSON build.

SidLeung pushed a commit to SidLeung/corelibs-arduino101 that referenced this issue Feb 9, 2017
…first connect

1. Not set the flage when local device try to set the value.
2. Changed file
    libraries/CurieBLE/src/internal/BLECharacteristicImp.cpp
@SidLeung
Copy link
Contributor

@sandeepmistry , resolution is available in nightly build starting on 2/9/2017,

http://mkfs.ndg.intel.com/json/public/package_public-07.4_index.json

@sandeepmistry
Copy link
Contributor Author

I'm still seeing this issue with the build2_16_2017.json release @SidLeung provided me. Output on Serial monitor after uploading the sketch above and connecting to the 101 using LightBlue on my Mac:

Connected to central: AC:BC:32:7C:FA:26
LED off

@sandeepmistry
Copy link
Contributor Author

Ok, there was a mix up with the JSON file, I have the incorrect version installed. This has been fixed.

@russmcinnis
Copy link
Contributor

I tested this with recent corelibs releases and don't see the issues with mac light blue as the central and running that sketch on a 101.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants