The nRF5 SDK's throughput sample (ble_app_throughput) provided very convenient shell commands to configure key parameters affecting throughput in a connection, such as ATT MTU size, Data Length, Connection Interval, and Preferred PHY (reference the SDK instructions here).
The NCS nrf sample "throughput" has no such run-time configurability. Instead, you must accomplish any parameter change by changing CONFIG parameters, rebuilding, and then reflashing the image into one or both boards under test (reference the NCS instructions here).
1. Why wasn't the NCS version of the throughput sample written to allow such run-time configurations?
- Is the reason for that to cover the nRF5340 because for that board the sample app runs on the application CPU, requiring consistent configuration settings as the network CPU? For example, CONFIG_BT_L2CAP_RX_MTU has to be less than CONFIG_BT_CTLR_DATA_LENGTH_MAX, otherwise hci.c's host_buffer_size() says "fragmentation from controller to host not supported".
- Aren't such CONFIG constraints not present for the nRF52 boards since they have one CPU and BT_RECV_IS_RX_THREAD=y for those chips? That is, at least for the nRF52 boards, aren't shell commands possible for the parameters as was for the nRF5 SDK?
2. Will the NCS throughput sample eventually support runtime configuration control?
- If this is considered a roadmap question that can't be answered here, can I rephrase the question as "Is there any reason preventing such runtime control in the nRF52"?
