nrf52 (sdk2.0 v11) alert notification and android gatt server

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

vit bernatik — Fri, 16 Sep 2016 23:44:56 GMT

I'm using for 2 descriptors always same uuid and it works. UUID shall be: UUID.fromString("00002902-0000-1000-8000-00805f9b34fb");

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Thu, 14 Apr 2016 07:35:53 GMT

Actually I think the problem is solved. I had to remove android device battery for a moment. I haven't worked with BLE stuff for a year, so I had a epiphany of last project with similar issue. The Android side BLE stack was in some weird state. I noticed that the changed characteristics didn't really change state.

Thanks for the support and the links!

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Thu, 14 Apr 2016 06:07:26 GMT

Yes, the original issue is "hidden" as I really would like to get some sort of indication that the nrf device has received the notification. Is started getting more notifications trough after changed the android side notifyCharacteristicChanged not to ask for confirmation. But as I said, I would like to get some sort of indication that the notification is received.

The connection drop is another matter that might be related to original issue. I can make another question if that's preferred for that.

Thanks for the documentation.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Hung Bui — Wed, 13 Apr 2016 14:25:11 GMT

Hi Matts,

I am kind of lost on what is the issue you have now. Do you still have the trouble that the notification doesn't come more than once per connection ? Or it's the issue that you need to keep sending notification or the connection will break ??

As you mentioned you can catch the BLE_GATTC_EVT_HVX event every time the phone send the notification, I suggest you to check why the application didn't switch the LEDs state . Could you check, if it's not a new message

Regrading the concept, I don't think we have anything other than the Alert Notification Service spec here. Also you can have a look at the documentation for the ancs example here.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Wed, 13 Apr 2016 13:21:27 GMT

Yes, it happens every timein nrf board after I send notifyCharacteristicChanged from android side. I made the breakpoint conditional so that it triggered on second BLE_GATTC_EVT_HVX-event. No timeout of course in nrf side in than case as debugger has stopped the execution.

But with non-debugger usecase the connection keeps alive as long as I keep giving notifications to nrf board from android side. If they stop, the board timeouts.

The consept I meant is whole alert notification consept. How fe acknoledging should be done and what sort of communication flow is expected.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Hung Bui — Wed, 13 Apr 2016 11:12:18 GMT

You meant you still receive BLE_GATTC_EVT_HVX events after the first notification ?

If you put a breakpoint inside the ble_ancs_c_on_ble_evt() function to catch that event, what happens after the first notification ?

There is no ACK for the notification, but there is ACK for every packet on linklayer on BLE.

Which concept you are talking about ? You can get an idea how BLE work here.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Wed, 13 Apr 2016 06:33:15 GMT

Regarding that BLE_GATTC_EVT_HVX -event. Yes, it happens. That the indication that notification has occurred. I had a trace in that switch-case. Also I can see the passed message in the nrf side trace. Anything specific I should check with debugger?

What I'm more conserned, that shouldn't the notification be somehow acknowledged the received notification?

And is there anywhere any explanation how this whole consept should work?

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Tue, 12 Apr 2016 13:52:42 GMT

In phone side: I just increase the new alert and unread alert counter in those two characteristics. For new alert I also change the payload type (first byte) and actual payload. The format is like the example value here: developer.bluetooth.org/.../CharacteristicViewer.aspx

After that I just call gattserver.notifyCharacteristicChanged for both unread and new alert notification characteristics.

In the nrf side I've added traces to all functions (special emphasis on event handlers) in ble_ans_c.c and main.c. In case of second notification i get no indications at all from any of those that something has occurred on.

I'll try the debugger tomorrow. Could you also suggest any special points of interest on the nrf side where I could add more traces?

I'll update the question with update log.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Hung Bui — Tue, 12 Apr 2016 11:10:31 GMT

What you described is a little bit strange, on that you receive only one notification before you need to disconnect and reconnect. Could you debug a little bit more ? Maybe check if it's the problem from the phone or from the nRF. You can use a sniffer to check if the notifications are sent but the nRF52 didn't catch it or didn't tell the application. You can run in debug mode and add a breakpoint at BLE_GATTC_EVT_HVX event to check if any event received.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Tue, 12 Apr 2016 05:44:32 GMT

Hi Hung Bui.

The nrf side example is unchanged from the original, other than enabling traces and adding some more.

In my app side I have a button than changes char value and calls notifyCharacteristicChanged. I can get one notification through per connection. After that I have to disconnect to get another through. The alerts I send are SMS alert, Call alert and email alert. All go trough as single notification. Also the communication is still OK, as the alert disabling (with nrf buttons) cause call to android side descriptor write callback.

Do I have to add some notification processing to app to make it accept more notifications? A flow how these things should be handled would be nice.

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Hung Bui — Mon, 11 Apr 2016 12:31:14 GMT

Hi Matts,

It's a little bit unclear for me on what you did on the nRF52 side. Did you do service discovery, and when you have the characteristic's handle ID, did you do a write to the CCCD to enable notification ?

Note that there is no nCharacteristicRead event with BluetoothGattServerCallback.

Have you called notifyCharacteristicChanged() from Android to start sending notification ?

RE: nrf52 (sdk2.0 v11) alert notification and android gatt server

Matts — Mon, 11 Apr 2016 09:40:07 GMT

Ok, the problem was that those descriptors needed to be unique. so 00002902 for one and second 10002902. After that the gattserver.sendresponse worked OK.

EDIT3: one integer value interprited as hex.

EDIT2: I think this whole problem is somehow related to character/service(?) rights. I changed the notifyCharacteristicChanged(BluetoothDevice device, BluetoothGattCharacteristic characteristic, boolean confirm) confirm-parameter to false and now I can send several notifications.

HOWEVER if there's more than few second pause, the's timeout and connection is dropped. There seems to be ble_ans_c_new_alert_read. tx function doesn't return any errors, but after while there's ble_ans_c_on_ble_evt callback with BLE_GATTC_EVT_TIMEOUT -value.

My New Alert -characteristic has pretty much all modes and priviledges enabled (for testing purposes). Or is this on nrf side?

My service & characteristics &server connection code:

    mGattServer = mBluetoothManager.openGattServer(this, serverCallback);

    mSupportedNewAlertCategory = new BluetoothGattCharacteristic(SampleGattAttributes.UUID_SUPPORTED_NEW_ALERT_CATEGORY,
            BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_READ | BluetoothGattCharacteristic.PERMISSION_WRITE);
    mSupportedNewAlertCategory.setValue(new byte[]{0x1f});
    /*
    * New alert part (char & descriptor)
    * */
    clientCharacteristicConfigNa = new BluetoothGattDescriptor(SampleGattAttributes.UUID_CLIENT_CHARACTERISTIC_CONFIG_NA,
            BluetoothGattDescriptor.PERMISSION_READ | BluetoothGattDescriptor.PERMISSION_WRITE);
    clientCharacteristicConfigNa.setValue(new byte[]{1});

    mNewAlert = new BluetoothGattCharacteristic(SampleGattAttributes.UUID_NEW_ALERT,
            BluetoothGattCharacteristic.PROPERTY_WRITE |BluetoothGattCharacteristic.PROPERTY_INDICATE | BluetoothGattCharacteristic.PROPERTY_NOTIFY | BluetoothGattCharacteristic.PROPERTY_READ,
            BluetoothGattCharacteristic.PERMISSION_READ | BluetoothGattCharacteristic.PERMISSION_WRITE);

    mNewAlert.addDescriptor(clientCharacteristicConfigNa);
    /*
    * Unread alert status associated with new alert
    * */
    clientCharacteristicConfigUa = new BluetoothGattDescriptor(SampleGattAttributes.UUID_CLIENT_CHARACTERISTIC_CONFIG_UA, BluetoothGattDescriptor.PERMISSION_READ | BluetoothGattDescriptor.PERMISSION_WRITE);
    clientCharacteristicConfigUa.setValue(new byte[]{1});

    mUnreadAlertStatus = new BluetoothGattCharacteristic(SampleGattAttributes.UUID_UNREAD_ALERT_STATUS,
            BluetoothGattCharacteristic.PROPERTY_NOTIFY | BluetoothGattCharacteristic.PROPERTY_INDICATE | BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_READ | BluetoothGattCharacteristic.PERMISSION_WRITE);
    mUnreadAlertStatus.addDescriptor(clientCharacteristicConfigUa);

    mSupportedUnreadCategory = new BluetoothGattCharacteristic(SampleGattAttributes.UUID_SUPPORTED_UNREAD_ALERT_CATEGORY,
            BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_INDICATE | BluetoothGattCharacteristic.PROPERTY_NOTIFY  | BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_READ | BluetoothGattCharacteristic.PERMISSION_WRITE);
    mSupportedUnreadCategory.setValue(new byte[]{0x1f});

    mAlertNotificationControlPoint = new BluetoothGattCharacteristic(SampleGattAttributes.UUID_ALERT_NOTIFICATION_CONTROL_POINT,
            BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_INDICATE | BluetoothGattCharacteristic.PROPERTY_NOTIFY | BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_READ | BluetoothGattCharacteristic.PERMISSION_WRITE);

    mAlertNotificationService = new BluetoothGattService(SampleGattAttributes.UUID_ALERT_NOTIFICATION_SERVICE, BluetoothGattService.SERVICE_TYPE_PRIMARY);

    mAlertNotificationService.addCharacteristic(mSupportedNewAlertCategory);
    mAlertNotificationService.addCharacteristic(mNewAlert);
    mAlertNotificationService.addCharacteristic(mSupportedUnreadCategory);
    mAlertNotificationService.addCharacteristic(mUnreadAlertStatus);
    mAlertNotificationService.addCharacteristic(mAlertNotificationControlPoint);

    mGattServer.addService(mAlertNotificationService);