• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 73 subscribers
  • Views 6540 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 113068
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Matts

Hi.

I've played around with the android application (based around google gatt example, but used in gatt server -mode).

How is the example expected to be handled? In proper central mode the nrf would do the scanning and connecting and android would be the peripheral and just host the gatt server (with Alert notification service + necessary characteristics) and advertise.

However as the nrf needs to be scanned by the android device, I first connect the device via regular gatt. At this point I've already opened gatt server connection and registered callback to it. I've also created the service and added characteristics to it and added those to gatt server. I also got onServiceAdded-callsto my BluetoothGattServerCallback.

After connection call I can get onConnectionStateChanged - and onCharacteristicRead -calls to BluetoothGattServerCallback. However if I try to write to said characteristic or do notify call, I can see no response on the nrf device. I've enabled read&write&notify priviledges on the characteristics and also I have enabled all notifications from the control point characteristic.

log from terminal:

[DB]: Discovery of service with UUID 0x1811 completed with success for Connectionhandle 0
[ANS] Found supported new alert category 
[ANS] Found New Alert 
[ANS] Found supported unread alert category 
[ANS] Found Unread Alert 
[ANS] Found Ctrlpt 
hox evt  
hox ansc disco
[main] alert_ns
[ANS] ble_event
[ANS] ...default id: 51
[ANS] ble_event
[ANS] ...read rsp
[ANS] read_rsp len 5
hox evt
hox read resp
[ANS] ble_event
[ANS] ...read rsp
[ANS] read_rsp len 5
hox evt
hox read resp
[ANS] ble_event
[ANS] ...default id: 18
[ANS] ble_event
[ANS] ...default id: 58
[ANS] ble_event
[ANS] ...disconnected
hox evt
hox disco comp
[ANS] ble_event
[ANS] ...default id: 27

Android side:

 04-08 17:00:23.571 BluetoothLeService: onServiceAdded
 04-08 17:00:23.577 BluetoothGatt: onClientRegistered() - status=0 clientIf=11
 04-08 17:00:23.644 BluetoothGattServer: onServerConnectionState() - status=0 serverIf=6 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.644 BluetoothLeService: onConnectionStateChage device CE:CE:67:C2:71:FE
 04-08 17:00:23.645 BluetoothGattServer: onServerConnectionState() - status=0 serverIf=7 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.645 BluetoothLeService: onConnectionStateChage device CE:CE:67:C2:71:FE
 04-08 17:00:23.646 BluetoothGattServer: onServerConnectionState() - status=0 serverIf=8 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.646 BluetoothLeService: onConnectionStateChage device CE:CE:67:C2:71:FE
 04-08 17:00:23.647 BluetoothGattServer: onServerConnectionState() - status=0 serverIf=9 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.647 BluetoothLeService: onConnectionStateChage device CE:CE:67:C2:71:FE
 04-08 17:00:23.662 BluetoothGattServer: onServerConnectionState() - status=0 serverIf=10 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.662 /BluetoothLeService: onConnectionStateChage device CE:CE:67:C2:71:FE
 04-08 17:00:23.663 BluetoothGatt: onClientConnectionState() - status=0 clientIf=11 device=CE:CE:67:C2:71:FE
 04-08 17:00:23.663 BluetoothGatt: onConnectionStateChange
 04-08 17:00:23.663 BluetoothGatt: status connected
 04-08 17:00:23.663 BluetoothGatt: discoverServices() - device: CE:CE:67:C2:71:FE
 04-08 17:00:23.671 BluetoothGatt: onSearchComplete() = Device=CE:CE:67:C2:71:FE Status=0
 04-08 17:00:23.691 Timeline: Timeline: Activity_idle id: android.os.BinderProxy@2ebcc89a time:102305919
 04-08 17:00:24.132 BluetoothLeService: onCharacteristicReadRequest UUID: 00002a47-0000-1000-8000-00805f9b34fb from device: CE:CE:67:C2:71:FE
 04-08 17:00:24.224 BluetoothLeService: onCharacteristicReadRequest UUID: 00002a48-0000-1000-8000-00805f9b34fb from device: CE:CE:67:C2:71:FE
 04-08 17:00:24.322 /BluetoothLeService: ondescriptorwriterequest UUID: 00002902-0000-1000-8000-00805f9b34fbValue: 1
 04-08 17:00:24.322 BluetoothLeService: sending nofication!

I checked the ans callback values from softdevice header, and they seem to be reporting non-faulty statuses (and pardon the traces I've added there).

Ideas where to go from here? There isn't really many examples on this sorf of usecase, altough the notifications from android to embedded device is quite used usecase.

  • 0

    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?

  • 0

    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.

  • 0

    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.

  • 0

    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.

  • 0

    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.

Related
Terms of service