calling sd_ble_gap_disconnect () from function ble_evt_handler()

[GK]

Dear Sir,

I am calling the function sd_ble_gap_disconnect() to disconnect the peripheral  from the App.

This is called inside  ble_evt_handler() function and under 

switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:

 Under the case statement  BLE_GAP_EVT_CONNECTED: I am calling a  function which in turn calls  sd_ble_gap_disconnect().

I was using nRFCOnnect to test the working.

When the connect - disconnect happens I am getting the following error from the App.

Do I need to take care of anything while calling  sd_ble_gap_disconnect() after establishing connection.

Or the fix for this to be done on the App side?

In the peripheral side I checked the error codes and all of them returns NRF_SUCCESS only.

Thanking you in advance.

with regards,

Geetha

[haakonsh]

Many examples are setup to re-start advertisments when the SofDevice sends a BLE_GAP_EVT_DISCONNECTED event, you'll probably need to disable that. 

[GK]

Hi haakonsh,

I need to re-start advertising as soon as disconnect happens. So I think no need to disable them.

I want the following scenario

1)switch on peripheral

2)start advertising

3)initaite connect from nrfconnect App

4)once connected disconnect (from peripheral side).

5)agian start advertising( immediatelt afyer disconnect) which is step 2,then step3, step4 etc....

Is the error displayed on the App(nRFConnect App) is due to  some issue on peripheral side?

Or is it to be fixed on the App side?( On the peripheral side none of the APIs return errors)(like this....  https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/9)?

Please shed some light on this ?

with regards,

Geetha

[haakonsh]

I suggest you capture a sniffer trace as it will tell us what's actually going on on-air. 

[GK]

Hi,

I could capture  the snifer trace.

But I could not figure out any issues.( I am new to this sniffer and related things).

Is it because I am missing something in settings/ or anywhere else.

I have captured 3-4 logs.

I am attaching the same with this.

with regards,

Geethalog_2times.pcapng8206.log4.pcapng3240.log3.pcapng

[haakonsh]

The first two sniffer traces only show advertisements and scan/response packets, but the third trace has some valuable information. 

The first connection start at packet number 480 and is immediately terminated by the peripheral. This pattern repeats itself for the next connection attempts. 


"Under the case statement  BLE_GAP_EVT_CONNECTED: I am calling a  function which in turn calls  sd_ble_gap_disconnect()."

"I need to re-start advertising as soon as disconnect happens."

You have set up a loop where you disconnect whenever you enter a connection, and re-start advertisements whenever you disconnect. 

[GK]

Hi haakonsh,

Thank you for your reply. I am very happy to hear from you.

Yes what you told is correct.

For the initial 45secs/60 secs I will do a looping. where the device will connect and disconnect. It is the behaviour I am expecting. THis is done to know about the phones who are all trying to connect to the device.The connect-disconnect pattern is repeated for this purpose.

But my question is about the error coming on App. i.e. the GATT-ERROR 133 . Is that something expected?.

Do I need to worry about this error on App side?

Or something to be done on App side to fix this, like i mentioned.

"Or is it to be fixed on the App side?( On the peripheral side none of the APIs return errors)(like this....  https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/9)?"( Because none of the API returns an error on peripheral side).

Please share your valuable suggestions.

with regards,

Geetha

[haakonsh]

Error 133 is a very general error code that Android spits out, and debugging it is next to impossible. What I think is that Android throws the error because the BLE stack got surprised by the sudden disconnect. By the sniffer trace you can see that the LL_TERMINATE_IND is received 500µs after the LL_FEATURE_REQ was sendt. This might have cause the Android stack to perform an "illegal" state change. 

[GK]

Thank you for your reply.

ok. So any ways to fix it?  Is it an issue with App or issue in peripheral? Any solution like Introduction of some delay etc will work?

[haakonsh]

If the issue is a BLE stack panic then a delay between connection and disconnect might solve the problem. 

We do not have any control over the BLE stack on the various mobile phones on the market. If they behave out of spec then we can only try to work around it.