Optimising for serialisation throughput?

RE: Optimising for serialisation throughput?

Frederik — Mon, 02 Oct 2017 14:39:56 GMT

So as shown in the other post: setting MAX_PEER_COUNT to 6 seems to work for 4 devices.

Sadly nearly the same problem. Now:

3 peripherals sending @ 100Hz -> 3x 100Hz @ UART (pc-ble-driver)
4 peripherals sending @ 100Hz -> 4x ~75Hz @ UART (pc-ble-driver)

So there seems to be a bottleneck in the device firmware / controller.

RE: Optimising for serialisation throughput?

Frederik — Fri, 29 Sep 2017 12:27:36 GMT

Thanks Terje, just tested switching to 1M - seems to work now with 3 devices - not sure why - have tested it before and driver failed to initialize...

anyway now the 4 devcie connection problem is kicking in ;) Can you have a look at it ?

RE: Optimising for serialisation throughput?

tesc — Fri, 29 Sep 2017 12:09:18 GMT

It came to my attention earlier this month that the version used with nRF Connect is actually using 1M baud, despite that the default in the connectivity patch for pc-ble-driver is 115k. Changing to 1M should give similar performance as for nRF Connect.

RE: Optimising for serialisation throughput?

Frederik — Fri, 29 Sep 2017 12:01:21 GMT

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

RE: Optimising for serialisation throughput?

Frederik — Thu, 10 Aug 2017 14:43:24 GMT

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!

RE: Optimising for serialisation throughput?

tesc — Thu, 10 Aug 2017 14:33:06 GMT

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.

RE: Optimising for serialisation throughput?

Frederik — Thu, 10 Aug 2017 14:27:36 GMT

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

RE: Optimising for serialisation throughput?

tesc — Thu, 10 Aug 2017 07:56:19 GMT

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.