Optimising for serialisation throughput?

[Frederik]

Hi, we are currently testing the nRF52 DK as a reciever for several BLE devices.

For a fist test we implemented some datarate measuring in the:

PC -> nrf Connect -> Bluetooht Low Energy App

The device firmware version is 1.1.0 (is suppose it not the newest from SDK 13.1.0?)

The datarate for 1 devices is 100Hz (18 bytes/package) @ ConnectionInterval: 30

We currently notice:

• 3 connected devices = 3x 100% Datarate

• 4 connected devices = 3x 100% datarate, 1x 50% datarate

• 5 connected devices = 3x 100% datarate, 2x 50% datarate

Baudrate of nrF Connect App is at 1000000. Should be way sufficient.

What is the limitation here? Can the firmware be optimized?

Regarding number of connections: As we currently know RAM is a critical value for the number of connection a device can hold. The latest SDK states to support up to 20 simultanious connections. Does that mean that value refers only to BLE5? Waht is it for SDK 13.1.0? Even im sure we wont be able to conenct 20 devices with that datarate cause of BLE limitations - what would be the expected number we can connect with full datarate with the serialized host?

regards Frederik

[Frederik]

Hey Terje, took me some time to setup my own connectivity FW with increased baudrate. Sadly it's even worse now and I absolutely don't know why.

FW: SDK 12.1 with patch @ 230400 baud SW: pc-ble-driver heartrate example - modified to measure datarate from 4 devices

Result:

• 2 connections => 2 devices @ full data rate (100Hz)
• 3 connections => 3 devices @ ~70Hz
• 4 connections => 4th devcie won't even connect (see devzone.nordicsemi.com/.../)

Sadly I'm not sure where the problem comes from. Why does nRFConnect perfrom a bit better with the defaul *.hex? Maybe SW handshaking is one problem (overhead) - how to disable?. Another reason could be different init parameters (see other post regarding 4 devices) .

Still the biggest question is: Is it even possible with the nRF52382???