Speeding up application to send 24bit I2S data at 16 kHz via BLE

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Edvin — Thu, 01 Sep 2022 12:47:12 GMT

[quote user="Moritz_S"]I also tried increasing NRF_SDH_BLE_GAP_EVENT_LENGTH further (e.g. to 400 as it is in the ATT Max. Throughput example), but this did not increase throughput further.[/quote]

Increasing this will only give a higher throughput if it was the parameter that was blocking. Increasing it to more than the radio would have time to use every connection interval will not have any effect.

Glad to hear that you found something that seems to be working.

Best regards,

Edvin

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Moritz_S — Thu, 01 Sep 2022 10:03:53 GMT

Hi Edvin,

thanks for your answer and suggestions. I implemented the suggested changes into both, the application sending dummy data and the original I2S application. They compile without warnings now.

For both I'm using 2MBPS PHY and 50 ms connection interval.

When sending dummy data, I can achieve ~ 1060 kbps, which is a little less than the optimum, but that's okay for now. I will continue testing, if less 2.4 GHz devices in the environment will increase the throughput.

When enabling I2S however, throughput goes down to ~ 60 kbps, which is not sufficient at all. then I realized that when using I2S, my NRF_SDH_BLE_GAP_EVENT_LENGTH was set to 6 (I was using two different projects ^^). Increasing that value to 40 (as it is in the project sending dummy data) also increased my throughput to a number that seems to be close to what I need for sending my I2S data. I still loose some data, but that is due to my buffer and not the BLE - so I just need to improve my implementation of the buffer.

For anybody interested: I also tried increasing NRF_SDH_BLE_GAP_EVENT_LENGTH further (e.g. to 400 as it is in the ATT Max. Throughput example), but this did not increase throughput further.

Overall, it seems that my problem is solved. But what impact has the NRF_SDH_BLE_GAP_EVENT_LENGTH parameter on what is happening in the code? I mean the connection interval is still 50 ms, no matter how high the NRF_SDH_BLE_GAP_EVENT_LENGTH.

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Edvin — Wed, 31 Aug 2022 10:23:27 GMT

[quote user="Moritz_S"]The result was: The byte count reported on the sender side (534.114 bytes) was significantly higher than on the receiving side (277.020 bytes). [/quote]

That should not be possible. If so, there is something wrong with the way you are counting either received or sent bytes.

Notes from looking at your surag_sense.zip file:

Line 1133 in main.c:

err_code = ble_aas_value_update(&m_aas, &data);

should be:

err_code = ble_aas_value_update(&m_aas, data);
// or
err_code = ble_aas_value_update(&m_aas, &data[0]);

The same goes for m_array in 1034:

err_code = ble_aas_value_update(&m_aas, m_array);

Then go to ble_aas.c line 74, and change it to:

const ble_gatts_evt_write_t * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

First after doing these changes I can compile your application without warnings. In most cases you should treat warnings as errors, because it may lead to undefined behavior. The only exception I can think of is when variables are "set but not used", while you are adding and removing things for debugging.

[quote user="Moritz_S"]The result was: The byte count reported on the sender side (534.114 bytes) was significantly higher than on the receiving side (277.020 bytes). When calculating throughput from the log file, it was mostly between 30 and 39 KBps.[/quote]

If this is based on the log file from nRF Connect for Desktop, I would not trust that. I suggest you write a central application that can count the received bytes properly. The reason for this is that at least the GUI in nRF Connect for Desktop is not able to keep up with the throughput, and I believe that the log reflects the GUI, meaning it will not receive all the bytes.

Counting the sent_bytes from your peripheral (I used an app timer to trigger every 1 second, and saw that it had sent 3 058 884 bytes over 29 seconds which is roughly 105kB per second = 800kbps. This is roughly how much you can get on 1MBPS PHY in BLE.

Checking by setting the connection interval to 500ms, I get slightly above 800kpbs (noisy environment in the office), and that is above what is possible with 1MBPS.

Looking at the log from nRF Connect for desktop, I sometimes see:

1:17:52.043	Attribute value changed, handle: 0x10, value (0x): 03-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
11:17:52.043	Attribute value changed, handle: 0x10, value (0x): 17-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

Meaning that all the packets between 0x03 and 0x17 are not printed in the log. They are received if the peripheral can queue it successfully, because the only way that the packet are not acked is if they disconnect.

Best regards,

Edvin

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Moritz_S — Tue, 30 Aug 2022 09:05:43 GMT

Hi Edvin,

thanks for your response, I have tested two things now:

1. Measuring throughput while sending dummy data

I have removed the I2S code from the application (I2S still enabled in sdk_config.h) and implemented sending dummy data as shown in the ble_app_uart example into my application and tested it on an NRF52 DK as sender and an NRF52 Dongle as the receiver together with NRF Connect for Desktop Bluetooth 4.0 (on Ubuntu 20.04 LTS). The hard fault is now gone.

The result was: The byte count reported on the sender side (534.114 bytes) was significantly higher than on the receiving side (277.020 bytes). When calculating throughput from the log file, it was mostly between 30 and 39 KBps.

I counted the bytes on the receivers side from the log file of NRF Connect for Desktop. I noticed that in most cases the bytes counted on the receivers side are roughly 50 % of the bytes counted on the sender's side.

Here is my project with the code for sending dummy data (using SDK 17.0.1) and the log file related to the case described above.

devzone.nordicsemi.com/.../example_5F00_logfile.txt

devzone.nordicsemi.com/.../surag_5F00_sense.zip

2. Measuring throughput with original I2S code

I have used the same approach to count the bytes that are sent using my original application including I2S.

Now the byte count on the sender's and the receiving side are equal to each other (42.768 bytes) but throughput reduced significantly to ~ 8 KBps.

My Conclusions:

- it seems that I2S in fact has an impact on the achievable throughput?

- NRF Connect for Desktop seems to have problem with logging higher data rates?

What do you think about these conclusions? Can you suggest any next steps?

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Edvin — Wed, 17 Aug 2022 13:16:19 GMT

[quote user="Moritz_S"]I haven't been able to find out what that means and how to address this issue. Can you help me out?[/quote]

That is a hardfault. These are a bit tricky to debug.

The log (from nRF Connect) only states that the peripheral disappeared, and hence you got a timeout disconnection.

If you sent the appliication you are using, will I be able to replicate the issue (hardfault) without an external microphone attached?

In fact, I think you should try to reduce the application to only send dummy data, so that we can exclude the I2S operations for now. Just to see whether the I2S + the data processing is slowing down things at all.

If you strip it down, and send it so that I can try to run it on a DK, I can see what your connection parameters looks like.

In case you are interrested, I'll attach a couple of modified examples (ble_app_uart and ble_app_uart_c) which will just send dummy data from one device to the other based on some button presses.

devzone.nordicsemi.com/.../0825.nus_5F00_throughput.zip

It runs in SDK16.0.0, so please download and test it in SDK16.0.0. Just unzip it next to the ble_app_uart example in the folder structure. Flash one DK with the peripheral example and another with the central, and press button 1 (I think) on one of them, and monitor the RTT log output.

Best regards,

Edvin

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Moritz_S — Wed, 17 Aug 2022 06:19:08 GMT

Good morning,

after my answer from yesterday I checked again my connection parameters and, in fact, I was using 7.5 ms as event length. I changed that now to 50 ms by changing

#define CONN_INTERVAL_DEFAULT           (uint16_t)(MSEC_TO_UNITS(7.5, UNIT_1_25_MS)) 
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(50, UNIT_1_25_MS)

#define CONN_INTERVAL_DEFAULT           (uint16_t)(MSEC_TO_UNITS(50, UNIT_1_25_MS)) 
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(50, UNIT_1_25_MS)        /**< Minimum acceptable connection interval (0.1 seconds). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(50, UNIT_1_25_MS)

and according to nRF Connect for Desktop, my connection parameters should now allow maximum throughput (2 M PHY and optimal connection parameters). I'm attaching my log file from nRF Connect.devzone.nordicsemi.com/.../2022_2D00_08_2D00_17T06_5F00_13_5F00_35.488Z_2D00_log.txt

However, this did not improve the overall process so much - I'm still receiving less samples than I would expect when recording, e.g., 3 seconds (~ 48.000 samples expected). So I looked again at the maximum throughput example. One significant difference in the example's sdk_config.h is

// <o> NRF_SDH_BLE_GAP_EVENT_LENGTH - GAP event length. 
// <i> The time set aside for this connection on every connection interval in 1.25 ms units.

#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 400
#endif

this value is 6 in my application. I tried setting the value first to 400 and then to 40 (to achieve 50 ms), but I got the following warnings:

<warning> nrf_sdh_ble: Insufficient RAM allocated for the SoftDevice.
<warning> nrf_sdh_ble: Change the RAM start location from 0x20002AD8 to 0x20002BE0.
<warning> nrf_sdh_ble: Maximum RAM size for application is 0xD420.
<error> nrf_sdh_ble: sd_ble_enable() returned NRF_ERROR_NO_MEM.

I changed the RAM start location as I was told, but since then my application stops working after roughly 1 second without a clear error message. I can only see an arrow in the 'Disassembly' window of Segger emStudio pointing to

00000A60    4B01    ldr r3,

I haven't been able to find out what that means and how to address this issue. Can you help me out?

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Moritz_S — Tue, 16 Aug 2022 14:04:47 GMT

Hi Edvin,

thanks for youor answer.

Yes, the i2s buffer always provides 32 bit samples: "The size of the buffers is specified in a number of 32-bit words. Such a 32-bit memory word can either contain four 8-bit samples, two 16-bit samples or one right-aligned 24-bit sample sign extended to 32 bit." (from here). I'm quite sure that the casting works, since I'm expecting a sine wave to be sent and I'm receiving this (verified with nRF Connect for Desktop).

I tried to reduce the amount of code in my initial post, that's why I didn't post it. Here is the full BLE implementation including ble_aas_value_update(), which is based on the ble_app_template from the SDK and the nRF52-Bluetooth-Course (as is the overall project).

//  ble_aas.c

#include "sdk_common.h"
#include "ble_srv_common.h"
#include "ble_aas.h"
#include <string.h>
#include "nrf_gpio.h"
#include "boards.h"
#include "nrf_log.h"

uint32_t ble_aas_value_update(ble_aas_t * p_aas, uint8_t *value){
    
    if (p_aas == NULL)
    {
        return NRF_ERROR_NULL;
    }

    // Update value in the GATT table with the value that is passed to this function
    uint32_t err_code = NRF_SUCCESS;
    ble_gatts_value_t gatts_value;

    // Initialize value struct.
    memset(&gatts_value, 0, sizeof(gatts_value));

    //gatts_value.len     = sizeof(value);
    gatts_value.len = 243;
    gatts_value.offset  = 0;
    gatts_value.p_value = value;
    //gatts_value.p_value = m_array;

    // Update database.
    err_code = sd_ble_gatts_value_set(p_aas->conn_handle,
                                        p_aas->aas_value_handle.value_handle,
                                        &gatts_value);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    // Notify peer that value of the charactersitc has changed

    // Send value if connected and notifying.
    // 1. check if connection handle is valid
    if ((p_aas->conn_handle != BLE_CONN_HANDLE_INVALID)) 
    {
        ble_gatts_hvx_params_t hvx_params;

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

        hvx_params.handle = p_aas->aas_value_handle.value_handle;
        hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
        hvx_params.offset = gatts_value.offset;
        //hvx_params.offset = 0;
        hvx_params.p_len  = &gatts_value.len;
        //hvx_params.p_len  = 244;
        hvx_params.p_data = gatts_value.p_value;
        //hvx_params.p_data = &value;

        err_code = sd_ble_gatts_hvx(p_aas->conn_handle, &hvx_params);
    }
    else
    {
        err_code = NRF_ERROR_INVALID_STATE;
    }

    return err_code;
}

/**@brief Function for handling the Write event.
 *
 * @param[in]   p_aas       AAS Service structure.
 * @param[in]   p_ble_evt   Event received from the BLE stack.
 */
static void on_write(ble_aas_t * p_aas, ble_evt_t const * p_ble_evt)
{
    ble_gatts_evt_write_t * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
    
    // Check if the handle passed with the event matches the Custom Value Characteristic handle.
    if (p_evt_write->handle == p_aas->aas_value_handle.value_handle)
    {
        // Put specific task here.
        #ifdef BOARD_PCA10040
            nrf_gpio_pin_toggle(LED_4);
        #endif
    }

    // Check if the Custom value CCCD is written to and that the value is the appropriate length, i.e 2 bytes.
    if ((p_evt_write->handle == p_aas->aas_value_handle.cccd_handle)
        && (p_evt_write->len == 2)
       )
    {

        // CCCD written, call application event handler
        if (p_aas->evt_handler != NULL)
        {
            ble_aas_evt_t evt;

            if (ble_srv_is_notification_enabled(p_evt_write->data))
            {
                evt.evt_type = BLE_AAS_EVT_NOTIFICATION_ENABLED;
            }
            else
            {
                evt.evt_type = BLE_AAS_EVT_NOTIFICATION_DISABLED;
            }
            // Call the application event handler.
            p_aas->evt_handler(p_aas, &evt);
        }

    }
}

/**@brief Function for handling the Connect event.
 *
 * @param[in]   p_aas       AAS Service structure.
 * @param[in]   p_ble_evt   Event received from the BLE stack.
 */
static void on_connect(ble_aas_t * p_aas, ble_evt_t const * p_ble_evt)
{
    p_aas->conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

    ble_aas_evt_t evt;

    evt.evt_type = BLE_AAS_EVT_CONNECTED;

    p_aas->evt_handler(p_aas, &evt);
   
    // Request PHY update
    NRF_LOG_INFO("PHY update requested.");
    ble_gap_phys_t const phys =
    {
        .rx_phys = BLE_GAP_PHY_2MBPS,
        .tx_phys = BLE_GAP_PHY_2MBPS
    };

    ret_code_t err_code;
    err_code = sd_ble_gap_phy_update(p_aas->conn_handle, &phys);
    APP_ERROR_CHECK(err_code);

    // switch on LED 1
    nrf_gpio_pin_toggle(LED_1);

}

/**@brief Function for handling the Disconnect event.
 *
 * @param[in]   p_aas       AAS Service structure.
 * @param[in]   p_ble_evt   Event received from the BLE stack.
 */
static void on_disconnect(ble_aas_t * p_aas, ble_evt_t const * p_ble_evt)
{
    UNUSED_PARAMETER(p_ble_evt);
    p_aas->conn_handle = BLE_CONN_HANDLE_INVALID;

    // switch off LED 1
    nrf_gpio_pin_toggle(LED_1);
}

void on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    ble_aas_t * p_aas = (ble_aas_t *) p_context;
    
    if (p_aas == NULL || p_ble_evt == NULL)
    {
        return;
    }

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connect(p_aas, p_ble_evt);
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnect(p_aas, p_ble_evt);
            break;

        case BLE_GATTS_EVT_WRITE:
            on_write(p_aas, p_ble_evt);
        default:
            // No implementation needed.
            break;
    }
}

/**@brief Function for adding the characteristics.
 *
 * @param[in]   p_aas        AAS Service structure.
 * @param[in]   p_aas_init   Information needed to initialize the service.
 *
 * @return      NRF_SUCCESS on success, otherwise an error code.
 */
static uint32_t add_characteristic(ble_aas_t * p_aas, const ble_aas_init_t * p_aas_init)
{
    uint32_t            err_code;
    ble_gatts_char_md_t char_md;
    ble_gatts_attr_md_t cccd_md;
    ble_gatts_attr_t    attr_char_value;
    ble_uuid_t          ble_uuid;
    ble_gatts_attr_md_t attr_md;

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

    //  Read  operation on CCCD should be possible without authentication.
    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);
    
    cccd_md.vloc       = BLE_GATTS_VLOC_STACK;

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

    char_md.char_props.read   = 1;
    char_md.char_props.write  = 1;
    char_md.char_props.notify = 1; 
    char_md.p_char_user_desc  = NULL;
    char_md.p_char_pf         = NULL;
    char_md.p_user_desc_md    = NULL;
    char_md.p_cccd_md         = &cccd_md; 
    char_md.p_sccd_md         = NULL;

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

    attr_md.read_perm  = p_aas_init->initial_value_char_attr_md.read_perm;
    attr_md.write_perm = p_aas_init->initial_value_char_attr_md.write_perm;
    attr_md.vloc       = BLE_GATTS_VLOC_STACK;
    attr_md.rd_auth    = 0;
    attr_md.wr_auth    = 0;
    attr_md.vlen       = 0;

    ble_uuid.type = p_aas->uuid_type;
    ble_uuid.uuid = AUDIO_CHAR_UUID;

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

    attr_char_value.p_uuid    = &ble_uuid;
    attr_char_value.p_attr_md = &attr_md;
    // set initial size of the attribute
    // attr_char_value.init_len  = sizeof(uint8_t);
    attr_char_value.init_len = 243;
    attr_char_value.init_offs = 0;
    // set max size of attribute 
    // attr_char_value.max_len   = sizeof(uint8_t);
    attr_char_value.max_len = 243;

    err_code = sd_ble_gatts_characteristic_add(p_aas->service_handle, &char_md,
                                               &attr_char_value,
                                               &p_aas->aas_value_handle);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    return NRF_SUCCESS;
}

uint32_t ble_aas_init(ble_aas_t * p_aas, const ble_aas_init_t * p_aas_init)
{
    if (p_aas == NULL || p_aas_init == NULL)
    {
        return NRF_ERROR_NULL;
    }

    uint32_t   err_code;
    ble_uuid_t ble_uuid;

    // Initialize service structure
    p_aas->evt_handler = p_aas_init->evt_handler;
    p_aas->conn_handle = BLE_CONN_HANDLE_INVALID;

    // Add AAS Service UUID
    ble_uuid128_t base_uuid = {AAS_SERVICE_UUID_BASE};
    err_code = sd_ble_uuid_vs_add(&base_uuid, &p_aas->uuid_type);
    VERIFY_SUCCESS(err_code);

    ble_uuid.type = p_aas->uuid_type;
    ble_uuid.uuid = AAS_SERVICE_UUID;

    // Add the AAS Service
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &p_aas->service_handle);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }
    
    return add_characteristic(p_aas, p_aas_init);

And the BLE related definitions from my main.c file:

#define APP_ADV_INTERVAL                300                                     /**< The advertising interval (in units of 0.625 ms. This value corresponds to 187.5 ms). */ 18000                                   /**< The advertising duration (180 seconds) in units of 10 milliseconds. */ 3                                       /**< Application's BLE observer priority. You shouldn't need to modify this value. */ 1                                       /**< A tag identifying the SoftDevice BLE configuration. */ 27 251 (uint16_t)(MSEC_TO_UNITS(7.5, UNIT_1_25_MS)) MSEC_TO_UNITS(20, UNIT_1_25_MS)        /**< Minimum acceptable connection interval (0.1 seconds). */ MSEC_TO_UNITS(50, UNIT_1_25_MS)        /**< Maximum acceptable connection interval (0.2 second). */ 0                                       /**< Slave latency. */ MSEC_TO_UNITS(4000, UNIT_10_MS)         /**< Connection supervisory timeout (4 seconds). */ BLE_GAP_PHY_2MBPS APP_TIMER_TICKS(5000)                   /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */ APP_TIMER_TICKS(30000)                  /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */ 3                                       /**< Number of attempts before giving up the connection parameter negotiation. */ 1                                       /**< Perform bonding. */ 0                                       /**< Man In The Middle protection not required. */ 0                                       /**< LE Secure Connections not enabled. */ 0                                       /**< Keypress notifications not enabled. */ BLE_GAP_IO_CAPS_NONE                    /**< No I/O capabilities. */ 0                                       /**< Out Of Band data not available. */ 7                                       /**< Minimum encryption key size. */ 16                                      /**< Maximum encryption key size. */

From my understanding, and looking at the log above, the connection parameters should be fine. The theoretisch BLE throughput should also be fine to send the amount of data I require (16.000 Hz x 24 bits). This is why I came the conclusion that the BLE should not be the bottleneck. The receiving peer is btw a nrf52840 Dongle, so I'm also not expecting any problems there. However, I will have a look at nRF for Desktop logfiles and share that with you in a minute.

If you need more details on the implementation, I can share my project/ all files here as well.

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Edvin — Tue, 16 Aug 2022 13:32:21 GMT

Hello,

I don't think the bottleneck is the 24->32 bit casting.

I didn't look too much at the logic in your casting, and my I2S is a bit rusty, since there is no sound HW on the DKs. But is it correct that the p_released->p_rx_buffer in the data_handler() callback has samples of 32 bits, where the last 8 bits are blank (0x00 or 0xFF)? I.e. 0xAAAAAA00, and the next sample has 0xBBBBBB00, and 0xCCCCCC00 and so on?

If so, after you cast it to 32 bytes, are you left with this in the buffer?

0xAAAAAABB 0xBBBBCCCC 0xCCDDDDDD 0x... and so on? Or what does it look like after you cast it?

I assume that your bottleneck is currently the BLE, and not the CPU or I2S.

I see that some parts of the application are missing, such as the implementation of ble_aas_value_update(). What does it look like? Is this always sending a large buffer? The trick in BLE is to always send large buffers (to reduce the overhead/payload ratio). Then, you need to keep the buffers full at all times for maximum throughput.

If this is satisfied, the throughput is up to the rest of your connection parameters. This isn't straight forward, but you need an MTU that is large enough (looks good from your log). What is your connection interval, connection event length, and PHY?

To play around with the connection parameters, I suggest you take a look at the SDK\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput

I believe maxing the event length, using around 50ms connection interval, and using 2MBPS PHY will give the highest throughput.

Best regards,

Edvin

RE: Speeding up application to send 24bit I2S data at 16 kHz via BLE

Moritz_S — Tue, 16 Aug 2022 11:12:53 GMT

I was checking the CPU usage by enabling NRF_PWR_MGMT_CONFIG_LOG_ENABLED and NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED. The output in the debug window can be seen below. It seems the cpu usage never exceeds 4 %, so I guess there has to be a way to speed this process up?

<info> app_timer: RTC: initialized.
<info> pwr_mgmt: Init
TWI device detected at address 0x18.
 Accessing Page no : 00 
 Error in register 1. Write = 01 but Read = 00
 Accessing Page no : 01 
 Accessing Page no : 00 <info> I2S: Initialized.
<info> app: I2S successfully initialized.
<info> app: Fast advertising.
<info> pwr_mgmt: CPU Usage: 47%
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: PHY update requested.
<info> app: Connected.
<info> pwr_mgmt: CPU Usage: 0%
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> I2S: Started.
<info> app: I2S started.

<info> pwr_mgmt: CPU Usage: 4%
<info> pwr_mgmt: CPU Usage: 4%
<info> pwr_mgmt: CPU Usage: 5%
<info> pwr_mgmt: CPU Usage: 4%
<info> pwr_mgmt: CPU Usage: 3%
<info> pwr_mgmt: CPU Usage: 5%
<info> pwr_mgmt: CPU Usage: 3%
<info> pwr_mgmt: CPU Usage: 2%
<info> pwr_mgmt: CPU Usage: 2%
<info> pwr_mgmt: CPU Usage: 2%
<info> I2S: Stopped.
<info> app: package added to ble stack: 281
<info> app: samples sent: 60408
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%