peer_id,conn_handle and check connection

RE: peer_id,conn_handle and check connection

Einar Thorsrud — Thu, 27 Jun 2024 12:49:37 GMT

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).

RE: peer_id,conn_handle and check connection

Chaoyue Ying — Thu, 27 Jun 2024 12:15:44 GMT

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?

RE: peer_id,conn_handle and check connection

Einar Thorsrud — Thu, 27 Jun 2024 12:06:02 GMT

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).

[quote user="Chaoyue Ying"]I think it is necessary that make sure get correct conn_handle everytime.[/quote]

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.

RE: peer_id,conn_handle and check connection

Chaoyue Ying — Thu, 27 Jun 2024 00:36:02 GMT

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和)

RE: peer_id,conn_handle and check connection

Einar Thorsrud — Wed, 26 Jun 2024 10:56:08 GMT

Hi,

[quote user="Chaoyue Ying"]

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.

[/quote]

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.

[quote user="Chaoyue Ying"]I think it is unnormal that they are not equal.[/quote]

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.

[quote user="Chaoyue Ying"]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()?[/quote]

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.

[quote user="Chaoyue Ying"]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.[/quote]

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.

RE: peer_id,conn_handle and check connection

Chaoyue Ying — Wed, 26 Jun 2024 00:26:12 GMT

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.

RE: peer_id,conn_handle and check connection

Einar Thorsrud — Tue, 25 Jun 2024 10:43:25 GMT

Hi,

[quote user="Chaoyue Ying"]

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.

[/quote]

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?

[quote user="Chaoyue Ying"]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?[/quote]

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.

RE: peer_id,conn_handle and check connection

Chaoyue Ying — Tue, 25 Jun 2024 02:01:45 GMT

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.

RE: peer_id,conn_handle and check connection

Chaoyue Ying — Tue, 25 Jun 2024 00:24:04 GMT

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).

RE: peer_id,conn_handle and check connection

Einar Thorsrud — Mon, 24 Jun 2024 13:59:38 GMT

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.