peer_id,conn_handle and check connection

[Chaoyue Ying]

I'm organizing my code with nRF SDK v17.0.0,using the board nRF52832 that designed by myself.

In order to support multi-central,the peer_manager module is used.So that I can use peer_id and conn_handle to get another one.

Such as I will save peer_id and conn_handle about a new security connection at pm_evt_handler that are contained in pm_evt_t that be called back.

Maybe due to the quickly connect and disconnect,sometimes the conn_handle that I saved is not equal to the one that get from pm_conn_handle_get().

And it seem either the save one or the get one be used in ble_nus_data_send() seem also can return NRF_SUCCESS but the data is not send to the aim.

So I try to poll the save conn_handle and the get conn_handle,if they are not equaled,I will try to disconnect the connection so that they can try to connect again.

But it seem inoperative.

I want to get the way to solve it.And the code as follow.

1202蓝牙程序v0.1.8.rar

[Einar Thorsrud]

Hi,

I have not been able to digg down into the details of your code so I am not able to see what causes this issue. However, I wonder if you could make this a bit simpler for yourself by ensuring that you don't start scanning again before the connection is properly established and the link encrypted)? That way, you will never have to deal with more than one new connection at any time.

PS: As a side note, I would suggest using defines to name the magic words used across this application to indicate states, as at least for me, it is difficult to understand what the condition you use in your dev_find represents. 

[Chaoyue Ying]

Hi,

You mean I need to restart advertising when connection established and link encrypted so that I restart advertising at the enf of PM_EVT_CONN_SEC_SUCCEEDED?

I use dev_find to find the save data to find the one of connection that a param equal to value to find a device(connection).

[Chaoyue Ying]

I get a screenshot share with you.

The conn_handle in first line is the value that p_evt->conn_handle that is return from the p_context of the interrupt and the get handle in third line is the value that get  by pm_conn_handle_get().

I'm not sure which one is authentic.

[Einar Thorsrud]

Hi,

Chaoyue Ying said:

The conn_handle in first line is the value that p_evt->conn_handle that is return from the p_context of the interrupt and the get handle in third line is the value that get  by pm_conn_handle_get().

I'm not sure which one is authentic.

The conn_handle you get in p_evt->conn_handle (you will get this for any evetn related to a connection), reflect which connection this event is about. The conn_handle you get from pm_conn_handle_get() is the conn_handle for the peer for which you have provided the peer_id. As this is a multi link project where you can be connceted to several peripherals at once, I do not quite understand why it is strange or an issue that you soemtimes get different conn_handle's? I would think that both these are valid/authentic, just that they represent two separate connections. Is that not the case?

Chaoyue Ying said:

You mean I need to restart advertising when connection established and link encrypted so that I restart advertising at the enf of PM_EVT_CONN_SEC_SUCCEEDED?

Not nesesarily. And I don't have a full understanding of your application. But  you have a multi link application, which by nature, can have more than one connection (so more conn_handle's can be valid at one time). So perhaps it would be easier to only scan and/or advertise during specific times when you are done with other tasks. There is no requierment to do this, though.

[Chaoyue Ying]

Hi,

Maybe I not make myself clear,I mean the p_evt->conn_handle and the conn_hanle that get from pm_conn_hanle_get() should point to the same device.

I think it is unnormal that they are not equal.If they are both vaild,that mean BLE support connect a device by both two conn_handle?So that,which one should be used when I want to send data to the device by ble_nus_data_send()?

In my impression,neither p_evt->conn_handle or pm_conn_handle_get() used in ble_nus_data_send() return NRF_SUCCESS but both no data recived in the peer device.

[Einar Thorsrud]

Hi,

Chaoyue Ying said:

Maybe I not make myself clear,I mean the p_evt->conn_handle and the conn_hanle that get from pm_conn_hanle_get() should point to the same device.

The p_evt->conn_handle is always correct for the event is concerns (though of course it could sometimes be that things have changed between when the event happened and you process it in your application).

pm_conn_handle_get() is different, as this is a function that lets you look up the conn_handle for a peer based on the peer ID. This can fail for several reasons, and this is documented in the API documentaiton. So you need to check both the return value to verify tha tit is NRF_SUCCESS, as well as check if the conn_handle is BLE_CONN_HANDLE_INVALID. If OK, you got the conn handle to the connection for that peer ID.

Chaoyue Ying said:

I think it is unnormal that they are not equal.

Yes and no. You have a multi link device, so if you have multiple connections, that may not be the case. And there is also a time factor here. What there is a disconnect (perhaps connection failed to be established due to packet loss), and then a rapid re-connect? You may have an old conn_handle and a new conn handle (with different value) for the same device as there are two different connections. This is something you need to handle.

Chaoyue Ying said:

If they are both vaild,that mean BLE support connect a device by both two conn_handle?So that,which one should be used when I want to send data to the device by ble_nus_data_send()?

If there is only one connection (?), then both cannot be valid at the same time. But if for instance your application processes the new connection event before the peer manager has processed it, you would get the old conn_handle with pm_conn_handle_get(). So you need to think about how to handle this. Generally, I see no benefit of getting the conn handle via the peer manager (which has to get it by processing a BLE event), instead of getting it from the connected event (and other BLE events). It would probably be better to only consider peer ID when relevant.

Chaoyue Ying said:

In my impression,neither p_evt->conn_handle or pm_conn_handle_get() used in ble_nus_data_send() return NRF_SUCCESS but both no data recived in the peer device.

This may be a different issue? Or perhaps you pass the wrong conn_handle to ble_nus_data_send() (it is the last parameter). If you do, I would expect it should return BLE_ERROR_INVALID_CONN_HANDLE.