BLE stream communication LOG errs

[Sam-IIT]

Hi all,

I've been developing a BLE application on my laptop to communicate with the 52840. I manage to understand how to create and run a BLE connection through the really nice tutorial that has been posted a couple of years ago on youtube.
https://www.youtube.com/watch?v=hY_tDext6zA 

Maybe this is nothing or maybe I'm using the system wrong, but I created a specific characteristic for stream data. Whenever I activate it, my terminal gets flooded with the messages in the attached pic.

My question is, are those only related to the Loggin framework and I should not be (at a certain level) worried? is this an issue about streaming too fast? If the latter, maybe this BLE is not indicated for data streams?

thank you all

[EDIT]

some extra info that may be of use.
I am streaming data out from a worker that runs at 1ms and sends a single uint16 packet over a dedicated characteristic. This error occurs when I enable such stream. Writing/reading single characteristics with manual inputs (using the evk buttons) does not give any issues. Ideally I'd like to stream an array of 16 uint16 elements.

This is my current configuration file

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_FPU=y
CONFIG_NEWLIB_LIBC=y
CONFIG_CBPRINTF_FP_SUPPORT=y

# Set CONFIG_NEWLIB_LIBC_FLOAT_PRINTF if printf should be able to print float
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# Configure logger
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_LOG_PRINTK=y
CONFIG_LOG_MODE_DEFERRED=y

# Configure Bluetooth
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="XYZ"
CONFIG_BT_DEVICE_APPEARANCE=0
CONFIG_BT_MAX_CONN=1
CONFIG_BT_LL_SOFTDEVICE=y

CONFIG_ASSERT=y

[Sigurd]

Hi!

You could try to increase some BLE related buffers.

CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_ATT_TX_COUNT=10
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CONN_TX_MAX=10
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY_2M=y

[Sam-IIT]

Hi Sigurd,

thanks for the reply. Unfortunately that had no effect, I still have missing data.

[Sam-IIT]

Hi Sigurd,

I mistakenly debugged the err value and it actually returns -12 (ENOMEM).
I'm trying the sniffer but I have issues on filtering through wireshark since I cannot see the UUID.

[Sam-IIT]

here's also the log of the captured stream.

the UUID of the characteristic used for streaming is (0xf26200f3, 0xbcb8, 0x4366, 0x9a9b, 0xa757edad68dc)

3617.capture.pcapng

I see holes in the actual stream too.

[Sam-IIT]

After searching around and testing different solutions, I still haven't found anything useful unfortunately.
I tested my worked and found out that can reach 25 ms stream (sill using a 16 element u16 array since this will be my actual output structure). below 25 ms the errors will start to arise. 

Any help would be much appreciated.

[Sigurd]

Hi!

At the start of the connection event, you as the peripheral have packets queued up, and the MD bit is set. But after a sending a few packets, the packet queue is empty, you don't have more data to send, and the connection event ends. Then you need to wait until the next connect event starts to send data. The connection interval is 45ms. Maybe you can try requesting a lower connection interval.

[Sam-IIT]

Hi Sigurd,

thank you for taking the time to go through the log. I tried editing the connection interval through code and that actually brought some improvements (min 7.5ms max 10ms)

bt_conn_le_param_update(current_conn, BT_LE_CONN_PARAM(6, 8, 0, 20));

which brings me to the question why editing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT didn't gave me the same effect?

given this behavior I went through implementing a manual MTU negotiation right before updating the parameters above 

// full callback on connection

void on_connected(struct bt_conn *conn, uint8_t err)
{
        if (err)
        {
                LOG_ERR("connection err: %d", err);
                return;
        }
        LOG_INF("Connected.");
        current_conn = bt_conn_ref(conn);

        /* maximize ATT MTU at peer side (CONFIG_BT_L2CAP_TX_MTU)*/
	static struct bt_gatt_exchange_params exchange_params;
        exchange_params.func = exchange_func;

        LOG_INF("sending ATT MTU to peer..");
        int rc = bt_gatt_exchange_mtu(current_conn, &exchange_params);
        if (rc)
        {
                LOG_ERR("failed to negotiate maximum mtu with peer [%d]", rc);
        }

        bt_conn_le_param_update(current_conn, BT_LE_CONN_PARAM(6, 8, 0, 20));
        
        dk_set_led_on(CONN_STATUS_LED);
}

in combination with the following prj.conf, I managed to have a stable stream of 1khz for 32 bytes with a worker running at 15 ms

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=7500

CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_ATT_PREPARE_COUNT=10
CONFIG_BT_L2CAP_TX_MTU=1024
CONFIG_BT_BUF_ACL_TX_SIZE=512
CONFIG_BT_BUF_ACL_RX_SIZE=512
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY_2M=y

But the question is the same as above, why didn't CONFIG_BT_L2CAP_TX_MTU allowed a higher MTU buffer? Also the negotiated MTU is 505, not 1024. 

Of course I managed this with a nrf52840 Dongle with the hci_usb project and the prj.conf edited to resemble the one of my project.