Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Jeong Hyun Seok — Tue, 16 Aug 2016 04:17:00 GMT

I am about to develop "LE Secure Connections". I already know you provide experimental example, but could you please give me more information?

LE Secure Connections - in Nordic

how it works - explanation with diagram

Tutorial could be best
Verification Method

How can I know it works properly

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Pär H — Wed, 16 Mar 2016 08:59:38 GMT

It is available here: developer.nordicsemi.com/

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Nate — Mon, 07 Mar 2016 19:21:18 GMT

Any updates on the release of the updated nRF5 SDK 11? Thanks

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Carles — Thu, 03 Mar 2016 16:00:34 GMT

@schoensn

You can continue to use sd_ble_tx_packt_count_get() (formerly buffer) as you did before. The only difference is that you will now get a different packet count for every connection depending on bandwidth settings. There are MSCs coming up in the SDK release.

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

schoensn — Fri, 26 Feb 2016 08:25:40 GMT

is it possible to provide detail information about the "queueing function" ?

regarding this post devzone.nordicsemi.com/.../

sd_ble_tx_buffer_count_get() returns 7 that means 6 packets are sent each connection interval and the additonal packet is used for queueing a packet for the next connection interval.

how is the behaviour in the S132 V2 for a peripheral? how many buffers are available for queuing?

at the moment my application sebnds 20-bytes notification packets via sd_ble_gatts_hvx() until it returns BLE_ERROR_NO_TX_BUFFERS.

maybe you can provide some diagrams that describes the behaviour of the function and how to use it...

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Ulrich Myhre — Thu, 25 Feb 2016 15:21:42 GMT

fluent: Yes, but only with the L2CAP APIs. This lets you send a few extra bytes per packet, since the channel ID and length is not repeated. The actual throughput varies a lot on the exact packet length though. If you send slightly longer packets, but end up with a fragment that contains just a few bytes, you probably didn't gain much at all compared to before.

Mentioned in the release notes is also the fact that the host interrupt is triggered during connection intervals now, and the bandwidth is configurable per link. This means that if the peer supports it, and you constantly queue packets with very little delay, you can in some cases go beyond the 6 packets per connection interval. This is very dependent on the number of concurrent links, what processing your app has to do between TX_COMPLETE events and the next queued packet, the number of buffers the peer device has etc. This functionality also applies to ATT as well, not only L2CAP.

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

fluent — Wed, 24 Feb 2016 02:14:02 GMT

From the release notes for the new version of the SoftDevice:

"L2CAP: The sd_ble_l2cap_* APIs now support packets longer than 23 bytes (DRGN-6649)."

Does this mean you can send data at a throughput higher than 16000 bytes per second, i.e. ((1000 / 7.5) x 6 x 20)?

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

Carles — Tue, 23 Feb 2016 14:44:55 GMT

Working on it, should come very soon.

RE: Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52

jmw — Tue, 23 Feb 2016 05:38:00 GMT

Any idea what the release date of the updated nRF5 SDK 11, that includes these softdevice versions will be?