nRF52840 SDK16 - High data rate Tx

RE: nRF52840 SDK16 - High data rate Tx

Susheel Nuguru — Tue, 10 Aug 2021 10:00:11 GMT

Sure Nikos, Have a nice summer break and hope to have promising results when you come back. The ticket will be open and visible to me once you reply with some results after the summer break.

RE: nRF52840 SDK16 - High data rate Tx

Nikosant03 — Tue, 10 Aug 2021 08:47:54 GMT

Thank you for your assistance Susheel, I will change the conenction parameters and I will let you know.

However, today I go to annual leave and I will return in the last week of August. So please keep the ticket open since then :)

RE: nRF52840 SDK16 - High data rate Tx

Susheel Nuguru — Tue, 10 Aug 2021 08:01:26 GMT

Hi Nick,

Thanks for very detail explanation. I am starting to get a good picture of your app design. I am starting to believe this is more related to your connection parameters than your processing time in the timer callbacks.

First thing to check is reduce connection interval, increase NRF_SDH_BLE_GAP_EVENT_LENGTH and update the phy to 2M. Using AUTO could sometimes change the PHY to 2M if your peer also supports and prefers that PHY. Use DLE(Data Length Extension) with bigger

NRF_SDH_BLE_GATT_MAX_MTU_SIZE (minimum of the size of the packet you send) and increase

NRF_SDH_BLE_GAP_EVENT_LENGTH to fit maybe have atleast two events in one connection interval with the selected MTU size.
Just a correction App_timer definitions APP_TIMER_DEF still uses the same RTC1 hardware instance and give application multiple software emulated timers to be able to use. In the core, you are still using RTC1 for both the timers. Which means that the RTC1 ISR will be processing both your SAADC sampling timeout processing + IMU timeout processing..
It seems like the IMU callback is too frequent than the ability of softdevice to handle HVX, most common reason is that the softdevice is unable to send enough data in one connection interval.

Change the connection parameters as suggested and please let me know how it goes.

I can suggest the connection parameters of

Connection interval 7.5ms,
MTU size of of atleast m_array
event length of 6.

RE: nRF52840 SDK16 - High data rate Tx

Nikosant03 — Mon, 09 Aug 2021 07:51:15 GMT

Hi Susheel,

Let me give a brief description of my application: The application reads 8 x analog pressure sensors by multiplexing them and it also acquires the position information from an IMU. I use two RTC timers to accomplish that.

RTC timer 1

I use this timer to read the pressure sensors. It expires every 800us and every time it expires I trigger sampling, convert the analog input and buffer it (meaning that I need approximately 800us x 8 sensors = 6.4ms to read all the sensors).

RTC timer 2

I use this timer to get the IMU data, buffer them, prepare the payload and finally notify the attribute value. This timer expires every 10ms (100Hz)

[quote userid="6207" url="~/f/nordic-q-a/78143/nrf52840-sdk16---high-data-rate-tx/323244#323244"]Yes, but the application probably is also preparing the packet to be sent? it would become a bit easier if you can share some code snippets of how you are getting/preparing your data to be transmitted[/quote]

Yes, here some code snippets:

I use 2 x timers for sampling the sensors, get the IMU data and notify the attribute value:

APP_TIMER_DEF(m_SAADC_timer_id);        // na - app_timer for SAADC captures
APP_TIMER_DEF(m_notification_timer_id); // na - app_timer for IMU capturs and BLE notifications

#define SAADC_INTERVAL APP_TIMER_TICKS_US(800)           /**< interval to read flexi force in us */
#define NOTIFICATION_INTERVAL APP_TIMER_TICKS(10)        /**< notification interval in ms */

When the m_SAADC_timer_id expires (every 800us):

1. I trigger the sampling

2. Convert the analog input

3. Multiplexing the pressure sensors

// Trigger sampling
void saadc_sample() {
  ret_code_t err_code;
  err_code = nrf_drv_saadc_sample();
  APP_ERROR_CHECK(err_code);
}

// Convert samples from analog to digital and buffer the digital values
void saadc_callback(nrf_drv_saadc_evt_t const *p_event) {

  if (p_event->type == NRF_DRV_SAADC_EVT_DONE) { // na - when the buffer is filled then the NRF_DRV_SAADC_EVT_DONE is generated
    ret_code_t err_code;

    err_code = nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAMPLES_IN_BUFFER);
    APP_ERROR_CHECK(err_code);

    ADC_RawData[callback_counter] = p_event->data.done.p_buffer[0]; // na - Buffer the ADC values from flexi force sensors (8 x sensors)

    if (callback_counter == NO_SENSORS - 1) {
    
      memset(ADC_RawData, 0, sizeof(ADC_RawData)); // na - Initialize the ADC_RawData buffer to 0
      callback_counter = 0;
      
    }

    else {
      callback_counter++;
    }
    selectMuxPin(callback_counter); // na - change MUX channel to read the next sensor
  }
}

// Multiplexing the pressure sensors
void selectMuxPin(int channel) {
  for (int i = 0; i < MUX_CTRL_CHA; i++) {

    if (channel & (1 << i)) {
      nrf_gpio_pin_set(ctrlPins[i]);
    } else {
      nrf_gpio_pin_clear(ctrlPins[i]);
    }
  }
}

When the m_notification_timer_id expires (every 10ms):

1. I get the IMU data

2. Prepare the payload

3. Send notification

static void notification_timeout_handler(void *p_context) {

  UNUSED_PARAMETER(p_context);
  ret_code_t err_code;

  m_xfer_done = false;

  bmi160_get_sensor_data((BMI160_ACCEL_SEL | BMI160_GYRO_SEL | BMI160_TIME_SEL), &s_accel, &s_gyro, &sensor);

  packet_counter++;

  int16_t msb_packet_counter = packet_counter >> 16;
  int16_t lsb_packet_counter = packet_counter;

  // Passing an array of data through notification to the central
  int16_t m_array[] = {s_accel.x, s_accel.y, s_accel.z, s_gyro.x, s_gyro.y, s_gyro.z, //bmm150.data.x, bmm150.data.y, bmm150.data.z
      ADC_RawData[0], ADC_RawData[1], ADC_RawData[2], ADC_RawData[3],
      ADC_RawData[4], ADC_RawData[5], ADC_RawData[6], ADC_RawData[7], msb_packet_counter, lsb_packet_counter}; // you can set either decimal or hex values

  err_code = ble_cus_custom_value_update(&m_cus, m_array);
  // Filter out some errors
  if (err_code != NRF_ERROR_INVALID_STATE && err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING && err_code != NRF_ERROR_RESOURCES  && err_code != NRF_ERROR_BUSY) { //
    APP_ERROR_CHECK(err_code);
  }

  err_code = app_timer_start(m_SAADC_timer_id, SAADC_INTERVAL, NULL); // na - Restart the SAADC sampling
  APP_ERROR_CHECK(err_code);
}

and just for reference this if where I implement the notification

//This is where we implement the notification
uint32_t ble_cus_custom_value_update(ble_cus_t *p_cus, int16_t custom_value[]) {

  if (p_cus == NULL) {
    return NRF_ERROR_NULL;
  }

  uint32_t err_code = NRF_SUCCESS;

  /** Send value if connected and notifying using sd_ble_gatts_hvx
   *  Verify that we have a valid connection handle, i.e. that we're actually connected to a peer, 
   *  if not we should return an error indicating that we're in an invalid state
   */
  if ((p_cus->conn_handle != BLE_CONN_HANDLE_INVALID)) // Here we check whether or not we are in a valid connection. If you try to send out notifications
                                                       // when not in a connection the SoftDevice will get grumpy and give you errors
  {
    ble_gatts_hvx_params_t hvx_params; // We declare a variable, hvx_params, of type ble_gatts_hvx_params_t
                                       // This will hold the necessary parameters to do a notification and provide them to the sd_ble_gatts_hvx()
                                       // hvx stands for Handle Value X where X symbolize either notification of indication

    memset(&hvx_params, 0, sizeof(hvx_params));

    uint16_t len = 32; // Set the length of bytes to be written. Remember that you must set the same len size for the characteristic attribute

    hvx_params.handle = p_cus->custom_value_handles.value_handle; // Provide the handle of our characteristic
    hvx_params.type = BLE_GATT_HVX_NOTIFICATION;                  // What "hvx type" we want to do, a notification or indication?
    hvx_params.offset = 0;                                        // Your characteristic value might be a sequence of many bytes. If you want to transmit only a couple
                                                                  // of these bytes and the  bytes are located in the middle of the sequence you can use the offset to extract them.
                                                                  // Since we want to update all of our four bytes we will set the offset to zero.
    hvx_params.p_len = &len;                                      // The current value is 2 bytes (sizeof(uint8_t))
    hvx_params.p_data = custom_value;                             // Here we add a pointer to the actual data

    /*
        After setting the hvx_params, we notify the peer by calling sd_ble_gatts_hvx()
        Parameters
        [in]         conn_handle	Connection handle.
        [in,out]     p_hvx_params	Pointer to an HVx parameters structure. If ble_gatts_hvx_params_t::p_data contains a non-NULL pointer 
                                        the attribute value will be updated with the contents pointed by it before sending the notification or indication. 
                                        If the attribute value is updated, ble_gatts_hvx_params_t::p_len is updated by the SoftDevice to contain the number 
                                        of actual bytes written, else it will be set to 0.

         sd_ble_gatts_hvx() not-only can change the internal value of the characteristic, but also sends it out as a notification/indication 
         to the other side which is subscribed to the characteristic

    */

    err_code = sd_ble_gatts_hvx(p_cus->conn_handle, &hvx_params); // Notify the peer by passing the connection handle as well as the hvx_params structure
  } else {
    err_code = NRF_ERROR_INVALID_STATE;
    //NRF_LOG_INFO("sd_ble_gatts_hvx result: NRF_ERROR_INVALID_STATE. \r\n");
  }

  return err_code;
}

[quote userid="6207" url="~/f/nordic-q-a/78143/nrf52840-sdk16---high-data-rate-tx/323244#323244"]Also try to change the PHY to 2M to have higher throughput[/quote]

I will try it, at the moment I use the BLE_GAP_PHY_AUTO

I hope this helps 🙂

RE: nRF52840 SDK16 - High data rate Tx

Susheel Nuguru — Wed, 04 Aug 2021 08:23:53 GMT

[quote user="Nikosant03"]The preprocessing is done by the SD when I call the sd_ble_gatts_hvx?[/quote]

Yes, but the application probably is also preparing the packet to be sent? it would become a bit easier if you can share some code snippets of how you are getting/preparing your data to be transmitted. Also try to change the PHY to 2M to have higher throughput.

RE: nRF52840 SDK16 - High data rate Tx

Nikosant03 — Wed, 04 Aug 2021 07:57:16 GMT

[quote userid="6207" url="~/f/nordic-q-a/78143/nrf52840-sdk16---high-data-rate-tx/323208#323208"]Every notification data packet your application queues, needs some pre processing (and most likely some post processing after sending) apart from other things your application does[/quote]

The preprocessing is done by the SD when I call the sd_ble_gatts_hvx?

[quote userid="6207" url="~/f/nordic-q-a/78143/nrf52840-sdk16---high-data-rate-tx/323208#323208"]It seems that the application is sometimes queueing the notifications too fast[/quote]

The queueing time is basically the time intervals between the sd_ble_gatts_hvx calls?

RE: nRF52840 SDK16 - High data rate Tx

Susheel Nuguru — Wed, 04 Aug 2021 06:10:56 GMT

Every notification data packet your application queues, needs some pre processing (and most likely some post processing after sending) apart from other things your application does. The CPU time used up by the softdevice is mostly fixed per BLE procedure and data transmit/receive. So you need to benchmark how much time your application is using the CPU on preparing each data packet and other logics that needs to maintain the housekeeping of your application.

In short, 6) points to the need to benchmark your application CPU time doing different things, you can use GPIOs to toggle at different logics to get an idea on application CPU usage. It seems that the application is sometimes queueing the notifications too fast (and hence get NRF_ERROR_RESOURCES in the HVX operation) and sometimes have idle periods where it is not utilizing the connection events to transmit data (as the application might be busy doing other stuff).

RE: nRF52840 SDK16 - High data rate Tx

Nikosant03 — Tue, 03 Aug 2021 14:59:51 GMT

Thank you for your prompt responce Susheel Nuguru

Could you elaborate more on 6. "minimal application post processing of data transmitted and or recieved"?

What do you mean by pre and post processing and how this affect the throughput? Could you provide an example?

RE: nRF52840 SDK16 - High data rate Tx

Susheel Nuguru — Tue, 03 Aug 2021 11:51:42 GMT

Hi Antoniou,

nRF52 is a single core chip. And you can have only only one strictly real time thread in it. When using BLE stack, which needs to follow very hard time constrained events, it takes up the highest interrupt priority reserved for it. When there is any BLE activity, there is both pre and post processing of that BLE data transmitted and or received. The throughput greatly depends on

Connection interval
Connect event length
Data size in the packet (using DLE and bigger packet size needs bigger event length)
PHY used
data to be sent out already being queued as fast as they can
minimal application post processing of data transmitted and or recieved to give maximum CPU time for application to queue data.

The suggestions for event length for a connection can be found here.

You need to understand how much time your application is spending on pre and post processing of data on notifications.
You also need to understand how many packets you are able to squeeze into one connection interval (how many connection events within a connection interval) based on the data size within a packet. In our thoughput examples we demonstrated that you can achieve very close to theoretical maximum throughput (1.4Mbps) with some room for application pre and post processing. But there is always a balance to make that an Architect of your application will be able to calculate/design and answer.

In your case, if you are getting NRF_ERROR_RESOURCES with that low throughput, means that you application has not calibrated the connection correctly OR spending a lot of time in pre or post precessing of data.