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

[tesc]

What do you mean by 100Hz data rate? You also write connection interval of 30 (ms) and 18 bytes/packet. How many packets per connection interval?

There is some overhead (due to serialization) and latency (at multiple points from the pc to the connectivity nRF) when using nRF Connect or any other pc-ble-driver based application, where you will see bottlenecks.

If you have a central connected to many peripherals with the same connection interval on the connections, then the events are scheduled as shown in Figure 3 in the Connection timing as a Central section of the SoftDevice specification. How many peripheral connections will fit depends on connection interval, packet size and number of packets per connection event.

[Frederik]

Hi Terje,

100 HZ = 100 packets/s with 18bytes packetsize

CI 30 = 37,5ms

=> 100 packets / (1s / 37,5ms) => ~ 3,76 packets/CI

Total payload data per device per second = 18byte * 100/s = 1800 byte/s

So with 3-4 Packets / CI can you estimate how many devices I could connect?

(I will also check the link you mentioned)

Currently the whole nRF52 is a backbox for me - I just see less packets at the UART in the end and know that our transmitters are sending all packets (tested with another reciever). Thats why I assume I have to optimise the firmware somehow to recieve more than the 3,5 devices, e.g. RAM management, UART DMA transfer,... can you point in the right direction?

Also can you confirm that the nrf Connect included firmware is based on nRF5_SDK_XXX\examples\connectivity\ble_connectivity\pca10040\ser_s132_hci?

regards Frederik

[tesc]

nRF Connect uses pc-ble-driver, which uses a slightly modified version of nRF5_SDK_12.1.0_0d23e2a\examples\ble_central_and_peripheral\ble_connectivity\pca10040\ser_s132_hci\ as per the sdk121_connectivity.patch.

[Frederik]

Great to know.

Seems the baud rate is set to 115200 with that patch - as per some basic calculations with HCI overhead that might be one bottleneck at ~4 devices. So I assume the 1M told by nRF Connect is jsut the PC side setup.

What will SER_MAX_CONNECTIONS 8 do?

Anything more to the above?

thanks for the fast reply!

[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???