BlueNRG indication issue

kukushonok · ‎2014-10-13

Posted on October 13, 2014 at 10:33

Hello

I have the following issue with BlueNRG: when I try to use ''INDICATION'' to sending data from server to client I have ble crash (the BlueNRG stops to respond to any command) after a few indicate packet (50 - 60). When I use ''NOTIFICATION'' this problem is not appear. I have checked this issue in ''Ble_chat'' project (I have modified characteristic properties for ''charUuidTX'' from ''CHAR_PROP_NOTIFY'' to CHAR_PROP_INDICATE and set delay (1s) between sending packet) and this issue also has appeared. Maybe do you have any idea what could be the problem?

Thanks

Regards

Software engineer, Andrei Kukenov

charles23 · ‎2014-10-15

Posted on October 15, 2014 at 21:01

Hi Andrei

The main difference between Notify and Indicate is, of course, that the Peripheral sending the Indicate expects an acknowledgement. Could it be that once in a while this handshake does not occur - either because the Indicate message did not make it to the Central or because the Central's ack did not make it back to the Peripheral?

As I recall, the BlueNRG stack will time out after about 30s if it does not see the ack, and fires a timeout event. Are you looking for that event and processing it?

Alternatively: if you are sending many Indicates, one per second, then the BlueNRG will have to keep track of the ack for all outstanding Indicates. I guess at some point there will be a limit to the number of unacknowledged Indicate messages and something unpleasant will happen. Are you looking at the status byte in the command complete response that at the BlueNRG sends when you send the Indicate? (ST: what happens?)

Request to ST: it would be great if the BlueNRG could fire an ''Indicate ACK Received'' event as soon as the ack arrives, as a positive acknowledgment that the Indicate has reached its destination. Otherwise the application has no way of knowing this, beyond waiting the 30s and checking for the absence of the timeout.

Regards - Charles Palmer

kukushonok · ‎2014-10-16

Posted on October 16, 2014 at 14:03

Hi, Charles

Thank you very much for your reply.

Yes, I am looking for ''EVT_BLUE_L2CAP_PROCEDURE_TIMEOUT: but unfortunately

this event does not appear. On the master side disconnection occurs and on the slave side this event does not occurs. I have no suggestions what could be the problem.

Regars,

Andrei Kukenov

charles23 · ‎2014-10-17

Posted on October 17, 2014 at 13:37

Hi Andrei

I have looked at the behaviour that I see, which is this:

1 When my Central and Peripheral are connected they seem reliable while the Peripheral is sending Indications. I put the Peripheral in a loop (100 times with 1s period) and I get Indication events at the Central every time the Peripheral makes a change to the characteristic.

2 On receipt of the Indication at the Central I send an acknowledgement (Bluehci_Gatt_Confirm_Indication). If I deliberately stop sending the acks then (a) I get no more Indication events and (b) both the Central and the Peripheral time out 30s later with a Bluehci_Gatt_Procedure_Timeout event and (c) the Central (but not the Peripheral) also receives a Disconnect_Complete event with a reason 0x08 (connection timeout).

So:

1 Do you also look for the Bluehci_Gatt_Procedure_Timeout event? (Make sure you detect and report every event.) Then you might see the same thing as me: failure to issue a

Bluehci_Gatt_Confirm_Indication causes the Central to disconnect but not the Peripheral.

2 Can ST please tell us why only one of the two devices sees a Disconnect? I see this quite often - not only in the Indications scenario. I have not had time to investigate. Surely this must be a bug? You cannot write code that re-establishes a connection if one device thinks it is still connected.

Regards - Charles

kukushonok · ‎2014-10-23

Posted on October 23, 2014 at 15:30

Hi, Palmer

Thanks a lot for you reply.

On my side I see exactly the same behavior that you describe. I get ''disconnection'' just on Peripheral side. I also really want to know how can I determine the BlueNRG is connected to master now or not. For example, after disconect on master side the method (

hci_read_rssi) returns last actual rssi value.

Regards

Andrei

marchese.graziella · ‎2014-11-19

Posted on November 19, 2014 at 11:55

Hi,

As Charles has said, ''The main difference between Notify and Indicate is, of course, that the Peripheral sending the Indicate expects an acknowledgement. '' therefore when the central receives the event ''EVT_BLUE_GATT_INDICATION'', it has to respond with the command ''ACI_GATT_CONFIRM_INDICATION''. If this not occurs (about 30 sec), both devices receive the event ''EVT_BLUE_GATT_PROCEDURE_TIMEOUT'' that means that the GATT procedure shall be considered to have failed, and no further GATT procedures shall be performed.

Anyway, the connection between devices is lost, both devices should receive the HCI_DISCONNECTION_COMPLETE.

Regards,

Graziella

Hi, Palmer

Thanks a lot for you reply.

On my side I see exactly the same behavior that you describe. I get ''disconnection'' just on Peripheral side. I also really want to know how can I determine the BlueNRG is connected to master now or not. For example, after disconect on master side the method (

hci_read_rssi) returns last actual rssi value.

Regards

Andrei

kukushonok · ‎2014-11-23

Posted on November 24, 2014 at 08:25

Hi,

Thank very much for you reply, if I understand correctly, there is no any event on peripheral role to indicate that acknowledgement from Central had been received and

I'll find out just in 30 seconds if acknowledgement was not recieved is not it?

Regards,

Andrei Kukenov

marchese.graziella · ‎2014-11-26

Posted on November 26, 2014 at 15:45

Hi,

I confirm that there is no event on peripheral role to indicate that acknowledgement from Central had been received. After 30 sec, if central doesn't send the ACI_GATT_CONFIRM_INDICATION, the EVT_BLUE_GATT_PROCEDURE_TIMEOUT event is raised on both devices.

However, the peripheral doesn't have to wait 30 sec between an indication and another, he can send them sequentially and the stack manages all.

Regards,

Graziella Marchese

kukushonok · ‎2014-11-27

Posted on November 27, 2014 at 10:20

Hi,

Thank you for you help

Regards,

Andrei Kukenov