about setting "NRF_SDH_BLE_GAP_DATA_LENGTH" value

[Bi_]

I've set "NRF_SDH_BLE_GAP_DATA_LENGTH" value to 27 on peripheral side, and it've changed to 251 after connection.
On the central side, the value is fixed as 27.
I believe the connection params affect each other, when it changes on peripheral side, the value also changes on the central side. Is it wrong?
Should I change the value on the central side?

[Einar Thorsrud]

Hi,

I believe the connection params affect each other, when it changes on peripheral side, the value also changes on the central side. Is it wrong?

All parameters start with "safe" values from Bluetooth 4.0, and any changes are based on a exchange/negotiation. If one of the peers support 251 and the other support 27, 27 will be used. If one support 251, and the other 150 for instance, 150 would be used.

Should I change the value on the central side?

If you want to use a data length of 251, both the peripheral and central needs to be configured to support and use 251. 

[Bi_]

However, the value has been changed after connection complete.
Then, what should I do? the NRF_SDH_BLE_GAP_DATA_LENGTH on central side should be defined as 251? The routine for changing the value is also placed on the central part?

[Einar Thorsrud]

Bi_ said:

However, the value has been changed after connection complete.
Then, what should I do?

I am not sure I understand. Can you elaborate?

Bi_ said:

the NRF_SDH_BLE_GAP_DATA_LENGTH on central side should be defined as 251?

If you want to support packet lenghts up to 251 bytes, then yes.

Bi_ said:

The routine for changing the value is also placed on the central part?

Yes. If you want an example of this, you can refer to the Nordic UART Service Client (this is a central example that corresponds to the peripheral example UART/Serial Port Emulation over BLE).

[Bi_]

I am using (1) nrf52832 as peripheral and (2) nrf52840 as central
(1) The peripheral defined the initial value of NRF_SDH_BLE_GAP_DATA_LENGTH as 27. This is because they thought that a large value was not necessary for advertising.
However, after connection, a large amount of data must be transmitted through NUS. So, when a connection event occurs, the data length is programmed to change to 251.

(2) central defined the initial value of NRF_SDH_BLE_GAP_DATA_LENGTH as 27. And the value doesn't change.
You said that it will be sent on 27 due to safety issues.
But I want to send it in 251 size after connection. If so, is there a need for a routine to change the data length after the connection event even in the case of (2) central?

As I understand it, I understood that the value of NRF_SDH_BLE_GAP_DATA_LENGTH is about how many pieces of data to send as a whole, right?
If this value is set to 251, it is understood that if you want to transmit 247 data, you only need to send one chunk.
If this value is 27, we know that 247 is divided into 27 and sent. right?
I wonder if it is correct that the higher this value, the faster the speed.

The example is often referred to, though

[Einar Thorsrud]

Hi,

I think there is a misunderstanding here DLE is not related to advertising at all, just the packet length when in a connection. (You can use longer advertising packets with extended advertising but that is a different and completely unrelated topic, so you can ignore that).

As you write that you want longer packets in a connection, but not longer advertising packets, set NRF_SDH_BLE_GAP_DATA_LENGTH to 251 in both the central and peripheral. If you refer to the NUS examples (central and peripheral) from a recent SDK, this will give you long packets in a connection out of the box.

Bi_ said:

But I want to send it in 251 size after connection. If so, is there a need for a routine to change the data length after the connection event even in the case of (2) central?

If you use the NUS examples, no, as it is supported and used out of the box. This is becasue the GATT module which is used in those examples will do the data length update procedure for you.

Bi_ said:

If this value is set to 251, it is understood that if you want to transmit 247 data, you only need to send one chunk.

Yes.

Bi_ said:

If this value is 27, we know that 247 is divided into 27 and sent. right?

Correct.

Bi_ said:

I wonder if it is correct that the higher this value, the faster the speed.

Yes, you can say that. Because there is less overhead. For maximum throughput you may also want to increase the event length as mentioned above, by setting NRF_SDH_BLE_GAP_EVENT_LENGTH to be longer in some cases (up to the same length as the connection interval). You also want to set NRF_SDH_BLE_GATT_MAX_MTU_SIZE set to 247, as is already done in the NUS examples.