NRF_SDH_BLE_GAP_EVENT_LENGTH

[Lee Daniel Crocker]

Using SDK14.2.

I'm trying to optimize the throughput of my ble_nus-based app (I'm getting about 5k/sec right now). I've read elsewhere on this forum that increasing NRF_SDH_BLE_GAP_EVENT_LENGTH from the default of 3 to 16 might help, and I also read that doing so requires increasing ram_start. I updated sdk_config.h, and the changed the RAM address in the linker script from 20002076 to 20002800, but I continue to get error 4 from nrf_sdh_ble_enable(). Is there some other setting that needs to be tweaked at the same time? Did I not change the ram start enough? Any other suggestions?

[hmolesworth]

Similar issues here, 6k/sec. I see from the throughput demo the following settings in sdk_config.h, main.c and --throughput--.icf:

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 320

#define CONN_INTERVAL_MIN               (uint16_t)(MSEC_TO_UNITS(7.5, UNIT_1_25_MS))    /**< Minimum acceptable connection interval, in 1.25 ms units. */
#define CONN_INTERVAL_MAX               (uint16_t)(MSEC_TO_UNITS(500, UNIT_1_25_MS))    /**< Maximum acceptable connection interval, in 1.25 ms units. */
#define CONN_SUP_TIMEOUT                (uint16_t)(MSEC_TO_UNITS(4000,  UNIT_10_MS))    /**< Connection supervisory timeout (4 seconds). */
#define SLAVE_LATENCY                   0                                               /**< Slave latency. */

define symbol __ICFEDIT_region_RAM_start__   = 0x20003128;
define symbol __ICFEDIT_region_RAM_end__     = 0x2000ffff;

Still experimenting ..

[Håkon Alseth]

Hi,

 

If you are getting err_code = 4 (_NO_MEM) back when trying to initialize the stack, you'll need to provide more RAM to the SoftDevice. 

in nrf_sdh_ble.c::nrf_sdh_ble_enable(), there is logging to provide you the expected RAM start, so if you have the NRF_LOG module enabled, it should print the required minimum RAM start address.

When adjusting the define NRF_SDH_BLE_GAP_EVENT_LENGTH, you will extend the amount of data that the peripheral can send, but this might still be restricted by the central side. if your connection interval is 100 ms, and the peer device does not support DLE, your overall throughput will be limited, as you are only able to send a lower amount of packets per interval (typically from 1 to 6).

 

Are you seeing 5 kBit/s or 5 kByte/s?

What is your connection interval?

 

Cheers,

Håkon

[Lee Daniel Crocker]

When I run it, nrf_sdh_ble.c reports "RAM starts at..." and just lists whatever the linker file is set to, so it is no help in determining actual ram usage. It never prints the "...can be adjusted to..." part, but when I move that log line out of the enclosing if, it just reports the same value.

When I say "5k", I mean whole bytes, so the throughput is reasonable, but that's still only 5% of the theoretical maximum bitrate. It would be nice to get 10-20%.

I have min/max connection interval set to 25 and 75 msec. Slave latency 0,

[Håkon Alseth]

Hi Lee,

 

I suspect that DLE is not used (not all central's support this) due to the low throughput. 

If that is the case, then going down to 7.5 ms connection interval should give you a better throughput.

 

If you still are seeing issues with the RAM, just set a higher value, as hmolesworth suggested.

You can read out the required RAM start by going into debug mode and breaking in the end of function nrf_sdh_ble.c::nrf_sdh_ble_enable(). Note that you likely need to set the optimization level to '-O0' in order to peek at the variables within the function scope.

 

Best regards,

Håkon

[Lee Daniel Crocker]

I think you missed my note above that all the variables in nrf_sdh_ble_enable() simply reflect the linker setting--there is no information there about actual RAM usage. I seem to recall that being different in earlier SDKs; the "...can be adjusted to..." line was actually useful. Currently it is very much not useful. Perhaps some change was made recently that works OK in the IDEs but not for armgcc?