Supported L2CAP modes in SoftDevice

Hello.

Our softdevices (from the nRF5 SDK) has a very restricted access to the L2CAP layer. This meaning that it happens inside the softdevice, and there is no way to overrule it. What is it that you want to acheive? Perhaps that is an easier way to attack this problem.

Best regards,

Edvin

Hi Edvin,

Thanks for you quick reply.

We want to achieve a reliable transmission of big data packet (e.g.: 16kB) with the best possible through-output by relying as much as possible on Bluetooth standard. L2CAP Le Credit Based Flow Control mode provides only packets receipt acknowledgement. Using another L2CAP mode with packet fragmentation/reassembly should allow to not have to define a custom fragmentation/reassembly protocol on top of BLE.

However, I didn't found a clear description on the BT Core specification if such a configuration is even possible.

That is not the softdevice supports, at least. I see that there are some questions regarding this on DevZone from time to time, but most of them are from a time where you had very low throughput on BLE.

What sort of transfer speed are you looking for? Using standard BLE services characteristics can give you up to ~1.3Mbps of payload under ideal conditions. 

I see that there are a few functions related to L2Cap, which you can find on Infocenter. But I don't see how this would allow you to not define a custom fragmentation/reassembly protocol. (You wouldn't have to do it on top of BLE, but there is no file transfer protocol in L2CAP either).

Whether you are able to use L2CAP also depends on what your connected device is. Is it another nRF chip, or is it a phone/pc?

BR,

Edvin

Thanks for the extra clarifications.

Indeed, the L2CAP API provided by the Softdevice only provides access to the  "LE Credit Based Flow Control Mode", which doesn't help for packed fragmentation/reassembly.

> What sort of transfer speed are you looking for?

We don't have a specific target yet, just experimenting on how better can a L2CAP oriented connection be.

> Whether you are able to use L2CAP also depends on what your connected device is. Is it another nRF chip, or is it a phone/pc?

The peer device would be an iOS or Android phone. Which of the nRF chip/ phone-pc option won't be possible?

Regards,

Louis

loumay said:

The peer device would be an iOS or Android phone. Which of the nRF chip/ phone-pc option won't be possible?

That depends on the bluetooth stack running on the connected device, how much or whether the stack gives access to the L2CAP layer. Whether it actually is that much faster I am not sure either. 

I would say that unless you are on the very limit of the speed, I would go with normal BLE, which is easier, and more widely supported. 

Other than that, the functions from the link in the previous reply is the only L2CAP layer that is exposed to the application. 

loumay said:

The peer device would be an iOS or Android phone. Which of the nRF chip/ phone-pc option won't be possible?

That depends on the bluetooth stack running on the connected device, how much or whether the stack gives access to the L2CAP layer. Whether it actually is that much faster I am not sure either. 

I would say that unless you are on the very limit of the speed, I would go with normal BLE, which is easier, and more widely supported. 

Other than that, the functions from the link in the previous reply is the only L2CAP layer that is exposed to the application.