Issue facing in connection between central device (1st "xiao nrf52840 sense") to peripheral device (2nd "xiao nrf52840 sense")

RE: Issue facing in connection between central device (1st "xiao nrf52840 sense") to peripheral device (2nd "xiao nrf52840 sense")

Edvin — Thu, 28 Nov 2024 00:10:41 GMT

That is great to hear! Even watching the sample, it is not trivial to get this working, so well done!

If you compare your old implementation with the current one (the one from the central_uart sample), you can see that the one in the central_uart sample uses the API that you used to use a few steps into the implementation. The difference is that when it receives the equivalent of your old discovery_func callback, it does some checks, and returns BT_GATT_ITER_CONTINUE in some cases. Actually, in most cases, unless it is the very last characteristic in the very last service.

Your implementation, however, returned BT_GATT_ITER_STOP if the first UUID didn't match the one you were looking for. Since the first UUID belongs to some general service that most devices has (containing name and type and so on), you told it to stop the discovery process, instead of continuing to the next UUID in the peripheral. Hence, you never found the service/characteristic that you were looking for.

Best regards,

Edvin

RE: Issue facing in connection between central device (1st "xiao nrf52840 sense") to peripheral device (2nd "xiao nrf52840 sense")

JAYnish2345 — Tue, 26 Nov 2024 17:25:39 GMT

Hi Edvin,

Thank you so much! It worked perfectly. The central device is now successfully connected and subscribed to notifications from the peripheral. I implemented the discovery mechanism from NCS\nrf\samples\bluetooth\central_uart.

Since I am entirely new to this and coding in general, I would like to understand why the previous code didn't work. Could you explain the possible mistakes I made in my earlier code?

RE: Issue facing in connection between central device (1st "xiao nrf52840 sense") to peripheral device (2nd "xiao nrf52840 sense")

Edvin — Mon, 18 Nov 2024 23:26:35 GMT

Hello,

Sorry for the late reply.

What is happening here is that the discovery callback is triggered, but with an UUID that is not the one you are looking for. When you then reutn BT_GATT_ITER_STOP, it stops the discovery process to continue searching for more services. The service that it typically will find first is the Generic Access Service, which just holds the name and appearance (icon ID) of the device.

I suggest that you look into the NCS\nrf\samples\bluetooth\central_uart and how it does it's discovery process. You can notice that it uses bt_gatt_dm_start() (dm = discovery manager), to handle the discovery callbacks, and then let it handle when to proceed and when to stop. Then, in the callbacks, you can print the UUIDs of the discovered service. You will probably see the discovery of some services that you are not interested in, but eventually, you will see the one you are looking for.

Alternatively, you can look at the discovery flow in the discovery module (ncs\nrf\subsys\bluetooth\gatt_dm.c), and how it handles it's callbacks, when it returns BT_GATT_ITER_STOP, and when it returns BT_GATT_ITER_CONTINUE.

Best regards,

Edvin.