The BLE may connected multiple devices. Does this call disconnect all connected devices if the device object is BLE?

For peer device object, it only connect it self.

That sounds like the right behaviour to me.

For peer device object, it only connect it self.

You been disconnect itself, right?

Yes. But how to handle the local BLE device? That's my concern.

How to handle local device? The BLE object.

BLE.Disconnect of Device == disconnect all connected peripherals/central. Disconnect per object.

Done

What's different with setAdvertisedServiceUuid in line 156? Does this only set service UUID in the ADV?

This is more of a convenience API my colleague proposed.

Basically the following are equivalent:

BLE.setAdvertisedServiceUuid(service.uuid());

BLE.setAdvertisedService(service);

It's so the user doesn't have to call service.uuid().

This has been resolved.

done

Does this only be used in ADV? And the type in ADV is BT_DATA_SOLICIT16 (0x14) and BT_DATA_SOLICIT128 (0x15).

Am I correct?

That is correct.

Sandeep will provide detail info on this topic.

One application of service solicitation in the new Bluetooth SIG HTTP Proxy Service (HPS): https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=308344 - see page 16 of PDF

Done

To support this area, the central need add callback to allow user handle the data. Line 374 and Line 385 has the defined the API for local name and services.
If user want set Manufacturer data, or other data in the ADV, how we allow user to establish the connection.

I'm unclear about your comment, please clarify. The manufacturer data is only for advertisement and it is independent from the connection.

How to handle the manufacture data in the sketches?

How user to access the manufacturer data? The manufacturer data is self defined. The BLE lib can't recognized the format.

Manufacture data == defined in BlueTooth spec. Sandeep will provide a link and iBeacon spec, if possible.

Baseline testing - use iBeacon.

Need to API, in Central, to provide the app for processing the manufacturer data. This is feature.

The iBeacon specification can be downloaded from the following link: https://developer.apple.com/ibeacon/ - see page 6/7 for the payload value put in the manufacturer section of the advertisement data.

I think Line 431 to 435 are not necessary. Those API are designed for verify the scanned device, for we can set the critical to filter the device and decrease the memory load. What's your idea?

We should keep them for the user to process advertisement and scan response data.

We can discuss memory concerns in the 101 core.

With buffering of ADV data, these APIs are needed.

Done

Not used. Need delete.

Agree. Removed,

Does this necessary? What different between startScanning?

I'll start a more detailed discussion for scanning.

startScanning will only report the discovered BT address once (it is filtered out after the first time), startScanningWithDuplicates will report the BT address continuously.

How many ADV devices we need to buffered?

done

How to make user process the ADV RAW data?

We should not expose the raw advertisement data.

Please see the following example sketch for the public facing API for the user to access the combine advertisement and scan response data: https://github.com/arduino/ArduinoCore-API/blob/master/api/BLE/examples/central/scan/scan.ino

Need to determine if the Nordic stack is capable of filtering BT addr.

Now only notify the Written event. ValueUpdated event need be implemented.

Sorry, can you please expand on what you mean by this?

Only notify the written event to user. The valueUpdated doesn't notify to user.

Will add the update event to baseline.

Done

What's this mean? Do you give me some background?

Broadcast will add the characteristics value to the advertisement as a service data entry.

For example for the Eddystone protocol: https://github.com/google/eddystone/blob/master/protocol-specification.md#common-elements

Service data has the EIR type of 0x16.

So when return value is true?

Sandeep will provide an example sketch.

Will not in the baseline and will be a feature.

Here's a example sketch for a simple counter that updates every second:

#include <ArduinoBLE.h>

BLEService testService("abcd"); // must be 16-bit UUID for broadcasting service
BLEIntCharacteristic testCharacteristic("ed12", BLERead);

// Generally, you should use "unsigned long" for variables that hold time
// The value will quickly become too large for an int to store
unsigned long previousMillis = 0;        // will store last time LED was updated

// constants won't change :
const long interval = 1000;           // interval at which to blink (milliseconds)

int counter = 0;

void setup() {
  BLE.begin();

  // add the characteristic to the service
  testService.addCharacteristic(testCharacteristic);

  // add the service to the GATT server
  BLE.addService(testService);

  // start advertising
  BLE.startAdvertising();

  // initialize the characteristc value
  testCharacteristic.setValue(0);

  // broadcast the characteristic, this will make it appear in the advertisement as service data
  //
  // 06 16 cd ab 00 00 00 00
  // -> 0x06: EIR length
  // -> 0x16: service data EIR type
  // -> 0xabcd: service UUID
  // -> 0x00000000: service data value (same as characteristic value)

  testCharacteristic.broadcast();
}

void loop() {
  // check to see if it's time to update the counter
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    // save the last time you blinked the LED
    previousMillis = currentMillis;

    // increment the counter
    counter++;

    // update the characteristic value
    // the value will be updated in the GATT server attribute table
    // as well as in the advertisement data, since the value is broadcasted
    testCharacteristic.setValue(counter);
  }
}

When scanning with nRF Master control panel on Android, you should be able to see the service data field when you look at a particular device's advertisement data (without connecting).

Done

What all those can* API mean? Does this only based on properties?
If yes, how we explain the canSubscribe and canUnsubscribe?
If not, what different with subscribed method?

They are same really.

It's based on properties and connection status of the device. For example, if the device is disconnected can* should return false. Also, for scenarios like this it should be false:

BLECharacteristic simpleKeyCharacteristic = peripheral.characteristic("ffe1");

if (!simpleKeyCharacteristic) {
  // should be false, because the characteristic does not exist on the peripheral
  simpleKeyCharacteristic.canSubscribe();
}

I don't think so. We can delete some duplicated APIs in you description. The subscribe method are called in the sketches. So the user need to know the property and the subscribe state. And the sketch will subscribe/unsubscribe based on the state. The property is based on the discovered/user setup, the subscribe is online.

sample sketch,

https://github.com/arduino/ArduinoCore-API/blob/master/api/BLE/examples/central/sensortag_button/sensortag_button.ino

line 85 onward.

Done

BLEDescriptor also need property.

This is a future feature for the app to change the descriptor of a peripheral. The Nordic stack does not allow descriptor to be changed.

This is an example for a changeable descriptor,

https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.server_characteristic_configuration.xml

Done

In multiple connection scenario, this method will auto return the next connected peripheral devices. Does this acceptable?

I don't think I had this call in the original spec.

What are the use cases for it? I think it can be removed all together actually.