Enabling Notification on a Characteristic

[augustio]

Hi, I was trying to send notification from nRF51822 to an android central when notification is enabled on the nordic uart rx characteristic and I discovered that if I enable notification on the characteristic once it has been discovered by the android app, nothing is received by the app but when I enable notification more than once, for example each time, the battery level characteristic is read, then I would start receiving data. I found out that in the source code of nrftoolbox, precisely in the hrs code, notification is enabled on the hrm characteristic each time the battery level characteristic is read:

	public void onCharacteristicRead(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, int status) {
		if (status == BluetoothGatt.GATT_SUCCESS) {
			if (characteristic.getUuid().equals(HR_SENSOR_LOCATION_CHARACTERISTIC_UUID)) {
				final String sensorPosition = getBodySensorPosition(characteristic.getValue()[0]);
				//This will send callback to HRSActicity when HR sensor position on body is found in HR device
				mCallbacks.onHRSensorPositionFound(sensorPosition);

				if (mBatteryCharacteritsic != null) {
					readBatteryLevel();
				} else {
					enableHRNotification();
				}
			}
			if (characteristic.getUuid().equals(BATTERY_LEVEL_CHARACTERISTIC)) {
				int batteryValue = characteristic.getValue()[0];
				//This will send callback to HRSActicity when Battery value is received from HR device
				mCallbacks.onBatteryValueReceived(batteryValue);

				enableHRNotification();
			}
		} else {
			mCallbacks.onError(ERROR_READ_CHARACTERISTIC, status);
		}
	}

So why wont notification be sent when it is enable just once?

[endnode]

Hi augustio,

As per BT SIG specification 4.0+: GATT CCCD (Client Characteristic Configuration Descriptor) values should be persistent across connections for bonded devices. If you are not using bonding you need to enable Handle Value Notifications each time you connect (from Central side).

Cheers Jan

---

Edit #1 (2015/05/22):

Hi augustio,

I cannot help you with Android or another API reflection of core BLE events so I'll stick to what is only real (on RF interface): CCCD state for not bonded nRF51 device with Nordic stacks (at least according to my experience and Nordic documentation) is kept between CONNECT_REQ and termination of BLE connection on LL layer (either by some time out or explicitly by particular TERMINATE command). I'd suggest to go down to the BLE principles and carefully map your solution to it in detailed flow charts. Then you also must include limitations coming from stack implementation on both sides (mainly what connection and advertising intervals are allowed, what is MTU size, how many events per connection interval it can handle, known bugs from release notest etc.) If you are then tight to some 3rd party HW and SW such as particular Android phone you must add significant cost/time into your project planning for debugging and testing (e.g. you might need more expensive BLE sniffer then Nordic's nRF51 DK/Dongle). Plus overall risk that if you push BLE to its "limits" (in this case it's anything else than vague bi-directional data transfer in range of several hundreds of bytes within couple of seconds) you might fail completely with your HW+SW set-up...

Cheers Jan

[endnode]

My post seems to be too long for comment so see amended question above;)