This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Reponse time of WRITE WITH RESPONSE command

Hi

I'm using a NRF52840 as multi central with 8 connections

SDK: 15.0; SD: 6.1 S140

My central connects to a peripheral with a connection interval of 50ms and latency of 0

When connected to 1 peripheral, from the time of issuing the sd_ble_gattc_write() command to the time I receive the BLE_GATTC_EVT_WRITE_RSP event is on average +-100ms.

As soon as I receive the response, I immediately send the next command and keep doing this.

With 2 peripherals connected, the turnaround time from command to the event is +-200ms. I tested it up to 6 connections the led to a 600ms turnaround time form sending the message to receiving the BLE_GATTC_EVT_WRITE_RSP. 

Is there an internal delay/queue/timer in the softdevice for sending messages? What else could be causing this?

Thanks

Parents
  • To add more details to this...

    I am using FreeRTOS to start with.

    Then, I have done some more controlled test in the following way:

    1) Connections: 1; Send 1 message and resend the message on every WRITE_RSP event

    Result: WRITE_RSP event arrival times after sending message: 210ms, 60ms, 120ms, 150ms, 60ms ... (perfect 30ms windows)

    (IMAGE: Looking at the bottom two rows where there are 'i' in: First row is calling sd_ble_gattc_write(); 2nd row is getting BLE_GATTC_EVT_WRITE_RSP)

    2) Connections: 2; Send only 1 message on each connection at the same time, not to be repeated on EVT

    Result: First connection's WR_RSP arrives 130ms after send, 2nd connection's WR_RSP arrives another 30ms later

    3) Same test as in (2) but with 4 connections

    Result: First connection's WR_RSP arrives 300ms later, followed by each of the other connections' WR_RSP an extra 30ms later

    4) Same test as (2) & (3) but with 8 connections

    Result: Interestingly the first WR_RSP arrives 250ms later followed by the WR_RSP for of the other connections 30ms appart (so a total of 450ms to receive all WR_RSP events)

    5) Connections: 8; Send 1 message per connection at the same time and reply to each WR_RSP event with another message as it arrives

    Result: First WR_RSP event arrives 250ms after sending WRITE with 30ms spacing between each connection's WR_RSP event, however, the next set of events arrive 250ms after the last WR_RSP event was received. This means that for the second set of sending of WRITE_WITH_RESPONSE commands sent, their corresponding event arrives 470ms later

    6) Connections: 8; Send only 1 message on only one connection and reply to the WR_RSP event (So only 1 connection is talking)

    Result: Almost xact same timing as per (5), however, only one connection is talking. Time to event from first write is 300ms. Time to every other event after a write is 470ms

    So with 8 connections and only one device talking, it takes 470ms just to send one WRITE_WITH_REPONSE and get the corresponding WR_RSP event.

    1) What is the softdevice design that explains this?

    2) Does each connection receive a 30ms (or something) timeslot in which data is sent and received?

    3) Is there a SDK setting or something that will allow me to change this to not have such a slow turnaround time for WRITE_WITH_RESPONSE issues when having multiple connections? We are planning on supporting 20 connections so this might be a painful experience if it cannot be changed.

    Thanks

Reply
  • To add more details to this...

    I am using FreeRTOS to start with.

    Then, I have done some more controlled test in the following way:

    1) Connections: 1; Send 1 message and resend the message on every WRITE_RSP event

    Result: WRITE_RSP event arrival times after sending message: 210ms, 60ms, 120ms, 150ms, 60ms ... (perfect 30ms windows)

    (IMAGE: Looking at the bottom two rows where there are 'i' in: First row is calling sd_ble_gattc_write(); 2nd row is getting BLE_GATTC_EVT_WRITE_RSP)

    2) Connections: 2; Send only 1 message on each connection at the same time, not to be repeated on EVT

    Result: First connection's WR_RSP arrives 130ms after send, 2nd connection's WR_RSP arrives another 30ms later

    3) Same test as in (2) but with 4 connections

    Result: First connection's WR_RSP arrives 300ms later, followed by each of the other connections' WR_RSP an extra 30ms later

    4) Same test as (2) & (3) but with 8 connections

    Result: Interestingly the first WR_RSP arrives 250ms later followed by the WR_RSP for of the other connections 30ms appart (so a total of 450ms to receive all WR_RSP events)

    5) Connections: 8; Send 1 message per connection at the same time and reply to each WR_RSP event with another message as it arrives

    Result: First WR_RSP event arrives 250ms after sending WRITE with 30ms spacing between each connection's WR_RSP event, however, the next set of events arrive 250ms after the last WR_RSP event was received. This means that for the second set of sending of WRITE_WITH_RESPONSE commands sent, their corresponding event arrives 470ms later

    6) Connections: 8; Send only 1 message on only one connection and reply to the WR_RSP event (So only 1 connection is talking)

    Result: Almost xact same timing as per (5), however, only one connection is talking. Time to event from first write is 300ms. Time to every other event after a write is 470ms

    So with 8 connections and only one device talking, it takes 470ms just to send one WRITE_WITH_REPONSE and get the corresponding WR_RSP event.

    1) What is the softdevice design that explains this?

    2) Does each connection receive a 30ms (or something) timeslot in which data is sent and received?

    3) Is there a SDK setting or something that will allow me to change this to not have such a slow turnaround time for WRITE_WITH_RESPONSE issues when having multiple connections? We are planning on supporting 20 connections so this might be a painful experience if it cannot be changed.

    Thanks

Children
No Data
Related