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

when the SoftDevice Event rise SD_EVT_IRQ in Central Role? What's connect timing mode for multi-link in Central Role?

Hi:

    We are develop an Central Device can Connect 8 BLE Device in same time. and want max throughout. it use queue and freeRTOS.  the Central TX is simple.

    use  sd_ble_gattc_write() with BLE_GATT_OP_WRITE_CMD to write.  wait semaphore event rise by BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event. 

   but between the SD_EVT_IRQ interrupt rise(BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE ) and sd_ble_gattc_write, it  take about 7.5ms. not our expect 2.5ms(1Mbps) or 1.4ms(2Mbps).  When SD_EVT_IRQ interrupt rise by SoftDevice?  why it same value as NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL ? 

Is NRF_SDH_BLE_GAP_EVENT_LENGTH  use to reduce SD_EVT_IRQ  frequency?  Do the Nordic Semiconductor have guidebook for these config parameters? or have excel document can calculate these parameters?

   how the SoftDevice handle Multi-linked peripheral connect timing? 

   from "Connection timing as a Central" charter of S140_SDS_v2.1,  Do SoftDevice use one Big time Slot to scan each connected peripheral? each peripheral get equalization chance?

|  peripheral 1 connect timing(7.5ms) | peripheral 2 connect timing(7.5ms)  | .... | peripheral 8connect timing(7.5ms)|   --> Next loop

|_____________________________|_____________________________|_______________________________|

   or just each peripheral has random shift start connect timing? 

           |  peripheral 1 connect timing(7.5ms) |

                |  peripheral 2 connect timing(7.5ms) |

                 .....

                     | peripheral 8connect timing(7.5ms)| 

 

Here the Central Config:

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251

#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0

#define NRF_SDH_BLE_CENTRAL_LINK_COUNT  8

#define NRF_SDH_BLE_TOTAL_LINK_COUNT    8

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6

#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 7.5

the "Connection Event Length Extension" is enabled.  and connect peripheral use min_conn_interval=max_conn_interval=7.5ms.  peripheral use  BLE_GATT_CHAR_PROPERTIES_WRITE_WITHOUT_RESPONSE/BLE_GATT_CHAR_PROPERTIES_NOTIFY.

Parents
  • About Question 3:  what 's the SD_EVT_IRQHandler interrupt rise timing? can like this? 

    <-  Peripheral Device 1 connect timing (7.5ms)  ->

    |-----------------------------------------------------------------|

    | T  |  R |  T  | R  | ....                                              |

    | X  |  X |  X  | X  | ....                                              |

    |----------------------------------------------------------------|

         ↓    ↓      ↓     ↓

    Interrupt Rise(if radio data sent or OK data received)

Reply
  • About Question 3:  what 's the SD_EVT_IRQHandler interrupt rise timing? can like this? 

    <-  Peripheral Device 1 connect timing (7.5ms)  ->

    |-----------------------------------------------------------------|

    | T  |  R |  T  | R  | ....                                              |

    | X  |  X |  X  | X  | ....                                              |

    |----------------------------------------------------------------|

         ↓    ↓      ↓     ↓

    Interrupt Rise(if radio data sent or OK data received)

Children
  • Hello again,

    Thank you for your continued patience with this.

    wen jin zhang said:
    Thanks for your help.

    No problem at all, I am happy to help!

    wen jin zhang said:
    1) central config support 8 peripheral link connection, if only one connection established, do the SoftDevice still handler other 7 connection  time slot? if yes, why ? is the "connectionInterval 0" value of by sd_ble_gap_connect() setting value? Not NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL? 

    No, the central does not have 8 separate slots. It will scan according to the scan configuration, and then place timeslots for the peripheral as they are connected. 

    wen jin zhang said:
    2)  do the SoftDevice have own GATTC for each connection peripheral   in Central mode? Do SoftDevice have own inside buffer(sd_ble_gattc_write() API write to,  BLE_GATTC_EVT_HVX event receive buffer) for each connection? Do they are queue Buffers? or just single(from my debug info, seem this is true, because second call sd_ble_gattc_write() will return NRF_ERROR_RESOURCES) ?

    The SoftDevice allocated a GATTC buffer pool per connection. What is your current queue size set to? The default value is 1, so this might be why you are getting NRF_ERROR_RESOURCES on your second function call.

    wen jin zhang said:
    3)  when the SoftDevice trigger the SD_EVT_IRQHandler? for example, when the SoftDevice radio finish the sd_ble_gattc_write() data package? Or finished the one device connection timing?  my issue: the SD_EVT_IRQHandler frequency is too slow. it about 135Hz. about 7.5ms interval. not our expect 400Hz(1Mbps) or 714Hz(2Mbps). 

    The event will be generated when the operation has finished, but the application's SD_EVT_IRQhandler will not be called until after the SoftDevice is finished processing and releases the control of the CPU back to the application layer. No application layer instructions are happening when the CPU is used by the SoftDevice, and all events that are generated in the time that the SoftDevice is active will be pending when the application resumes.

    Best regards,
    Karl

  • Thanks for your support!

    Karl YIvisaker answer:

    The SoftDevice allocated a GATTC buffer pool per connection. What is your current queue size set to? The default value is 1, so this might be why you are getting NRF_ERROR_RESOURCES on your second function call.

    Yes, we used the default value 1.  We only found can change hvn_tx_queue_size  of GATT Server  and write_cmd_tx_queue_size for GATT client. all the for transmitter.  Why No for Receiver? Do SoftDevice have ping-pong buffer for GATT Server and GATT client receiver? 

    we change hvn_tx_queue_size  = 3, write_cmd_tx_queue_size  =3, but still only get 32KB/s == 256kbps.  for one connection. (scan disable when connected).  the examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput  about 992.07kbps (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 7.5 millisecs).   

    our example also use Device GATTS sd_ble_gatts_hvx send.  Central receive the data. the SD_EVT_IRQHandler frequency still about 135Hz.  the Device GATTS feed data as far as possible. same ATT MTU =247, Data Length=251.  

  • Hello, 

    wen jin zhang said:
    Yes, we used the default value 1.  We only found can change hvn_tx_queue_size  of GATT Server  and write_cmd_tx_queue_size for GATT client. all the for transmitter.  Why No for Receiver?

    What do you mean by this? By transmitter, I assume you mean the server, and by receiver you mean client, is that so?
    write_cmd_tx_queue_size is the configuration for the number of write without response commands that can be queued for the client, in the same way that hvn_tx_queue_size is used to configure the number of notifications that the server can queue for sending.

    wen jin zhang said:
    we change hvn_tx_queue_size  = 3, write_cmd_tx_queue_size  =3, but still only get 32KB/s == 256kbps.

    Do you still get the NRF_ERROR_RESOURCES with this configuration?
    With a queue size of 3 you will only be able to queue 3 notifications for sending each connection interval.
    Using the Online Power Profiler you can see that the sending of 3 such notifications would take around 2 ms to send. This means that you are using far from the full 7.5 ms interval to send packages.

    wen jin zhang said:
    the Device GATTS feed data as far as possible. same ATT MTU =247, Data Length=251.

    What is your connection event length configured to? Have you enabled DLE? To increase throughput you can increase connection event length in order to let the device use more of the time between connection events for sending data.
    Are you familiar with the nRF Sniffer? It is a powerful tool to wield when developing BLE applications. It would be very helpful to see a sniffer trace of the communication happening here, in order to pinpoint why you are not getting the expected throughput.

    Best regards,
    Karl

  • Sorry for my poor English. 

    About 1st my said,  I mean: the SoftDevice seem only support send queue.  both the GATTS and GATTC.  Why does Not SoftDevice  also support receive queue? if yes. the SoftDevice can receive data before Application handle the BLE_GATTC_EVT_HVX Event completely.

    About 2nd my said, answer:  No NRF_ERROR_RESOURCES  error because we handle BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event track free queue size.

    about 3rd my said, NRF_SDH_BLE_GAP_EVENT_LENGTH == 6.  here the sniffer info.

  • Hello again,

    I am sorry for the delay in answering. I have been out of office for some time, but now I am back. 

    wen jin zhang said:
    Sorry for my poor English. 

    No need to apologize - I am just making sure that I am understanding your issues and questions correctly.

    wen jin zhang said:
    I mean: the SoftDevice seem only support send queue.  both the GATTS and GATTC.  Why does Not SoftDevice  also support receive queue? if yes. the SoftDevice can receive data before Application handle the BLE_GATTC_EVT_HVX Event completely.

    No, there does not exist any such rx hvn queue, since the application can pull and handle these events while the next notification is incomming.
    When the radio is either in RX or TX all high-priority SoftDevice interrupts are disabled, which should leave enough time for the application to pull and handle the previous HVN while the radio is receiving the next one.

    wen jin zhang said:
    About 2nd my said, answer:  No NRF_ERROR_RESOURCES  error because we handle BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event track free queue size.

    Great, I am happy to hear that you resolved the NRF_ERROR_RESOURCES issue!

    wen jin zhang said:
    about 3rd my said, NRF_SDH_BLE_GAP_EVENT_LENGTH == 6.  here the sniffer info.

    I am glad to see that you now have the sniffer tool up and running, great!
    Could you share the complete sniffer trace file instead of screenshots? This would be very helpful since it enables me to see 'the full picture'. 
    Right now, I am unable to see how many notifications that are fit into each event, since I neither see the delta time nor connection event number column.

    Again I apologize for the long delay in answers to this ticket.

    Best regards,
    Karl

Related