Making changes in "Server Setup" for "nRF52840 Dongle" in "nRF Connect for Desktop Bluetooth Low Energy" doesn't save changes to dongle.

[GameCodingNinja]

The "nRF52840 Dongle" defaults to a max length of 20 in all of the "General Access" characteristics and I'm trying to change that to a higher number. I change it to 60 for each of the characteristics, save each characteristic and then apply the changes to the device. Reload the dongle and the values are back to 20. I tried creating a new service and once again, the new service not saved.

I'm trying to get the dongle to transmit and receive more then just 20 bytes at a time.

Any idea of how to do this?

[Amanda Hsieh]

Hi, 

You can save the setup and load it when you need. See Configuring server setup. 

Regards,
Amanda H.

[GameCodingNinja]

Yep, I've done that but that's not the problem. The changes don't seem to be getting saved to the dongle. Even though I changed the max data length to 60, the BLE code in my 52840 still reports 20 when making a connection to the dongle.

Also, see the attached screen shot above.

//
// BLE connected callback
//
static void connected_cb(struct bt_conn *conn, uint8_t err)
{
    char addr[BT_ADDR_LE_STR_LEN];

    if (err)
    {
        LOG_DBG("Connection failed (err %u)", err);
        return;
    }

    bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
    current_conn = bt_conn_ref(conn);

    LOG_INF("Connected %s; Max data length: %u", addr, bt_nus_get_mtu(current_conn));
}

[Amanda Hsieh]

You need an extra device to run the sniffer.

-Amanda H. 

[GameCodingNinja]

I'll try again tomorrow when I bring my work laptop in from home.

[GameCodingNinja]

I captured these logs. Filter on source d3:f1:4b:b8:32:d6. If you scroll down about half way, that's all you'll see. It advertises Orbis_HQEA100052. It does show 23 bytes which means the Python is ignoring the self.adapter.default_mtu = 250 setting. On Android it shows 53 bytes.

nrf52840 to nRF52 Dongle.pcapng

nrf52840 to android.pcapng

[Amanda Hsieh]

Hi, 

From your log, I don't see any connect event. You should see something like this if the center or peripheral requests MTU update.  

You should check if the MTU exchange has actually happened or not. In some of our examples where the peripheral is configured to automatically initiate MTU exchange, the Python script central will automatically give a MTU Exchange Response with the value in default_mtu.

If the peripheral does not initiate, then the central has to.

-Amanda H.

[GameCodingNinja]

I think we are onto something here. I added the missing code to the connected_cb callback function. I'm not getting a connect event as you describe above but I suggests 63 bytes now instead of the 23 before. At least we are moving in the right direction.

This can now be seen in the RTT Console when I connect.

Question is... where is it picking up this 65 when my default_mtu value in the Python app 250?

I've confirmed that I can now transmit 61 bytes.

[Amanda Hsieh]

Could you capture the sniffer log while you are getting the RTT log?

-Amanda H.

[GameCodingNinja]

nrf52840 connect.pcapng

I think this might be what you are looking for.

[GameCodingNinja]

Found it. The below defaulted to...

#define CONFIG_BT_L2CAP_TX_MTU 65

#define CONFIG_BT_BUF_ACL_TX_SIZE 27

#define CONFIG_BT_BUF_ACL_RX_SIZE 69

...in the autoconf.h. That's where my 65 limit came from.

In my prj.conf, added the below...

CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_BUF_ACL_RX_SIZE=251

CONFIG_BT_BUF_ACL_TX_SIZE=251

...and like magic...

...I can send even more bytes.

I think our work here is done. Thanks you so much!