Can you try using bleprofile_sendIndication? This will caues the client to send back a confirmation packet.
Yes, I can use this function, send indication out and get the confirmation.
I want to know that what action is needed if I send an indication out, but can’t get the confirmation? Does my application just wait for it?
Confirmation on Notification?
For my understanding, BLE supports:
- Notification: a message from device/slave to master WITHOUT a confirmation from master ("unreliable send")
- Indication: this is similar message but master device will send acknowledge - this is for reliable transmission
The WICED Sense uses just Notifications. My guess: you should not see that after Notification the master device will reply and confirm. You had to change the GATT descriptors to "indicate" instead.
Due to indication transmission is reliable, so I decide to use it. But I want to know if master do NOT send confirmation(ack) to slave, what countermeasure should be taken?
I had ever used zigbee stack, it had ack mechanism when transmission. No matter transmission success or not, stack always invoke callback handler to tell application the transmission result. But wiced smart stack do NOT return the result of indication transmission.
1 of 1 people found this helpful
I am sorry, cannot help, not familiar with the BLE stack on FW side.
I would guess, instead of a callback, there should be a timeout. If it is a standard acknowledge for a "synchronous message", Indication - I would think the call for the Indication to send might return with error (or time out indication), or you have an error callback handler. My guess: if all is OK, you do not see any callback (no reason for it, just in case of error, 'ack not received', after timeout an error callback invoked).
1 of 1 people found this helpful
For my understanding these are the differences:
server (device) can sent any time, with any speed (repetition ratio) a Notification.
It is unreliable because: no ack sent and not sure if received on device (it does not know if client has realized, therefore it might continue as fast as needed).
And it can create congestion on client (fast repetitive Notification sent).
Real handshake: server (device) sends and will await acknowledge. As of my knowledge: server will not send again if ack was not received. A guarantee before next Indication - there must be an ack.
It is like a "back pressure": if client does not ack - server will not send again. The client device can decide what server (device) will do and control the speed of Indications and Acks.
Good question what slave should do if ack was missing.
I guess: it will be stuck forever or: there is a timeout defined (and I think there is one), so that server (device) will try again. No clue what this timeout value is (had to study standard or the books here). I would imagine it is the same timeout used for lost connection (quite long).
More serious: if it can result also in disabling the connection, one peer assumes the link is broken and will shutdown RF, state and link goes to "sleep" - it depends on implementation. It might be possible that a FW will assume, a missing ack means "client is not there anymore" and will go to unbound, disengaged state.
And: if this is the case: also client has to deal with this timeout and make an assumption (server might be down). It cannot assume the client-server states are still in sync, as "server waiting for my ack still". If link goes down, a new advertisement and re-bond cycle (directed advertisement by server) would be needed.