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]

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.

[Chaoyue Ying]

Hi,

I decide to use pm_conn_handle_get() to get conn_handle,but what should I do when pm_conn_handle_get() return BLE_CONN_HANDLE_INVALID?(Because I know the NRF_ERROR_NULL and NRF_ERROR_INVALID_STATE almost do not happened)

I think it is necessary that make sure get correct conn_handle everytime.

嗨，我决定使用pm_conn_handle_get()来获取conn_handle，但是当pm_conn_handle_get()返回BLE_CONN_HANDLE_INVALID时，我应该做什么?(因为我知道NRF_ERROR_NULL和)

[Einar Thorsrud]

If pm_conn_handle_get() gives you BLE_CONN_HANDLE_INVALID that means that either you have not connection with that peer at that time, or that the peer manger has not processed the new connection yet (or dependign on priorities etc that the peer manager has not processed the new connection yet, and if so you can try a bit later).

Chaoyue Ying said:

I think it is necessary that make sure get correct conn_handle everytime.

Definetly. Therefore, please note that the conn_handle you get with the connected event and all other evetns are always valid (at the time of the generation of the event). But as in any real time system, things can change over time. So you need to handle that a valid conn_handle may suddently be invalid (due to a disconnect for some reason), etc.

[Chaoyue Ying]

Hi,

You suggest that I can try a bit later.So which method you suggest?By timer or other ways?The bit later seem hard to fix a time so that I should use the timeout way to check?

[Einar Thorsrud]

To delay some things in nRF5 SDK, the typical way is to use a shingle shot app_timer. (I am stil struggling a bit to see why you do it this way, starting with the peer_id, instead of relating to the conn_handle you get with the connection event, though. I would think it would be easier to do it the other way around).