Design an application with or without the SDK

[obbe]

We're developing a new device for a regulated market (medical). As such, we need to have control on what third-party software we're using, and how it is working. While starting to dig into the Bluetooth aspects of our device, I've found two routes to take.

1) Develop the application using the SDK as interface for the SoftDevice. Benefits of this is out-of-the-box experience, while the downside is another third-party library (SoftDevice already being one) that we have to manage and that we don't have full control on what the SDK actually does. We (probably) won't use the other drivers from the SDK, so we're a little worried that there will be some conflicts that may be hard to discover, particularly when it comes to timers and power management, e.g. stuff that is not application specific in the sense I2C or SPI are.

2) Code directly to the SoftDevice. Benefits of this is total control (except as stated in the SD specification) of hardware with less risk of conflicts / shared usage. Downside is the increased work that needs to be done to complement the SoftDevice, where bonding and advertising seems to be the bigger tasks.

I don't have a particular question, but rather seeking input on which route to go and if any has experience with both ways and how much extra effort it was to go with option 2. Also, I'm curious on how much using the SDK locks you in design-wise? Is there a particular design paradigm that is suggested (I've seen a little about the app timer, but haven't grasped it fully)? Anyone have experience with the SDK doing "unexpected things", or the general quality of the SDK?

Any thoughts or observations on the two routes are greatly appreciated!

[Kenneth]

I recommend to use the SDK libraries, because even though it is possible to implement bonding and database discovery yourself, you will be doing work that has already much work have been put into (and considering the actual sequence of messages may also vary depending on the peer) you may spend years before you will have all combinations covered. If you still want to pursue this you can find the message sequence charts in the softdevice specification useful:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v6.0.0/s132_msc_overview.html?cp=2_3_1_1_0_1 

 

[obbe]

Thank you for your reply! I should probably have mentioned that we control the central the peripheral will communicate with. (The SoftDevice would only be needed for peripheral) Its very application specific use of BLE; it's only intended as means to transmit data wirelessly between two devices. The communication will use a single service with two characteristic (Rx and Tx).

The link was very helpful, thanks for that! Why am getting the feeling I'm fooling my self looking at it thinking it seems pretty straightforward? Why is it it "may take years" to cover the combinations? What's more specifically taking time - coding, testing, troubleshooting, analysing...?

Edit: Also, are there any security features implemented in the SDK that should be taken into considerations? I assume the data encryption is done on SoftDevice level, but thinking of paring - is that handled in the SoftDevice or the SDK/Application? I assume that for e.g. passkey there has to be some intervention from the application side.

[Kenneth]

Especially bonding and storing and retrieving keys, identifiers and system attributes is not as straight forward as it seems. A problem could be that someone bond, and for unknown reason decide to remove the batteries shortly after because it's now bonded and should be working, so you need to be able to store away data fast.