Early questions about creating custom Bluetooth Service

[craig.goldman]

I am creating software for a proof-of-concept device using the nRF52840 Dev Kit and nRF Connect for VS Code.

I started a few weeks ago with the Nordic UART Service code example (for Zephyr).
Recently I found an example here...
https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/getting-started/posts/ncs-ble-tutorial-part-1-custom-service-in-peripheral-role#h55sk6jeuj5h1q0t9y3471sju120rfsj

There are some notable differences, which may be related when these examples were created.

1) NUS calls "bt_enable" with NULL for a parameter, then completes configuration and service initialization after the function returns.
The "custom service" example, calls "bt_enable" with a callback; the code in the callback completes configuration and service initialization.
My initial code follows the NUS example.  Since my device will not operate without Bluetooth, there is nothing else to do until configuration has completed.
Should I change the code to use the callback or my I continue to do configuration "synchronously"?

2) The NUS example calls "settings_load" to complete configuration; the "custom service" example does not.
I'm not sure what this does or why it is needed.  Would you please explain?

3) A couple of years ago, I worked on a BLE project using the nrf libraries.  I believe the library had a limit to the number of services and characteristic which could be supported (maybe a total of 7 or 8 services and characteristics).  Is there a similar limitation if I build my new device using nRF Connect and Zephyr libraries?

4) Is there a newer example for developing a custom Bluetooth service?

Thank you,

-Craig Goldman

[Edvin]

Hello,

1: If you call bt_enable(NULL), then bt_enable will not return before it is complete. If you don't have anything you want to do in the mean time, then it is perfectly fine to do so. 

2: "Settings" in this context refers to stored bluetooth security information, such as bonding information. I don't know if you plan to encrypt your link (pairing) and if you intend to save the pairing information for future connections (bonding). If so, you must enable bluetooth settings (you will see some "settings"  related configs in the prj.conf for the peripheral_uart sample). If encryption is not required in your application, then you don't need these settings.

3: There was never a hard limit on how many services or characteristics you could have (not in NCS, and not in the nRF5 SDK). There was a hard limit on 8 devices that could be active in a whitelist. Perhaps that is what you were thinking of. In reality, you can't have as many services/characteristics as you like, but the limitation is rather the amount of memory required by the characteristics. But that depends on the characteristic properties, so it is very difficult to say how many you can have. 

4: Not that I am aware of. I wrote something similar independently from the one that you linked to, and I was unaware that the one that you linked to was written at the same time. The funny thing is that they turned out very similar, and they are still valid in the latest NCS version (which is currently v2.1.1). 

I hope that clears up some of your questions. Let me know if anything was unclear. 

Best regards,

Edvin

[craig.goldman]

Thank you for your responses.

I'll investigate the "settings" to see if I want/need this functionality in the "proof-of-concept" device.
Is this documented in the nRF Connect documentation or do you have a link where this is explained in more detail?

There seemed to be some limit to the number of characteristics (maybe because of memory), but I tried to add some to a previous project and they simply did not show up.  Would you happen to know if the amount of memory allowed for use by characterisitcs has been changed (hopefully increased)?

I will review your custom NCS BLE example on GitHub.

Thank you again

-Craig

[Edvin]

Hello Craig,

If the new characteristics didn't show up, but the application running on the nRF doesn't report any errors, I suspect that you are trying to read the characteristics using a mobile phone. It is a bit tricky, because mobile phones tend to store the tables holding the services and characteristics between connections. You can try to turn bluetooth completely off and back on after a while, to see if that resets the service table. 

If you have an extra DK or Dongle, I can recommend the "nRF Connect for Desktop -> Bluetooth Low Energy" desktop application, which doesn't store the services and characteristics between connections. It does however require an extra nRF DK or Dongle.

Best regards,

Edvin

[craig.goldman]

An issue with the phone did not occur to me.  I'll keep that in mind while working on this project.

Thank you,

-Craig