How to calculate max payload size when using Shorter Connection Intervals (SCI)?

[Ben K]

I'm currently evaluating the Shorter Connection Intervals feature of BT 6.2, and its use for low-latency HID applications. I have seen the updated HID mouse sample (https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/samples/bluetooth/peripheral_hids_mouse/README.html) has SCI support, with a minimum of 750us connection interval. What I find strange in this sample is that the mouse data is split into 2 reports of 3 bytes each. Is this because the reduced interval limits the payload size? It would be great if the formula to calculate the effective GATT notification payload size was made available, so developers can understand the necessary tradeoffs between connection interval (or frame space if relevant) and usable payload size.

The bt_gatt_notify_cb() method returns -ENOMEM if the payload size exceeds what the MTU allows, is there a similar mechanism for SCI imposed limitations, or is the MTU adjusted to match the SCI parameters?

Thanks in advance.

[Amanda Hsieh]

What I find strange in this sample is that the mouse data is split into 2 reports of 3 bytes each. Is this because the reduced interval limits the payload size?

No. The sample defines two separate 3-byte HID input reports in the report map: Report ID 1 (buttons/scroll/pan) and Report ID 2 (12-bit X/Y movement). This is deliberate HID design, independent of SCI. A 3-byte notification fits easily within the default ATT MTU and LL PDU size at 750 µs. The button demo sends movement on Report ID 2 only.

It would be great if the formula to calculate the effective GATT notification payload size was made available, so developers can understand the necessary tradeoffs between connection interval (or frame space if relevant) and usable payload size.

SCI does not introduce a separate GATT payload limit; bt_gatt_notify_cb() is still bounded by ATT MTU and TX buffer availability. SCI constraints operate at the Link Layer: connection interval, frame space, connection-event length, PHY, and data length. For minimum SCI intervals, the SoftDevice Controller documentation states that 2M PHY, lowest ACL frame space, and 27-byte data length are required. MTU is not adjusted for SCI. If large Data Length Extension is negotiated, the controller may limit effective TX octets or reject very short intervals. Also check out the SoftDevice Controller changelog (DRGN-24488).

The bt_gatt_notify_cb() method returns -ENOMEM if the payload size exceeds what the MTU allows, is there a similar mechanism for SCI imposed limitations, or is the MTU adjusted to match the SCI parameters?

No. SCI-specific GATT check exists. bt_gatt_notify_cb() returns -ENOMEM when bt_att_create_pdu() fails — either payload exceeds ATT MTU or ATT TX buffers are unavailable (same error code). MTU is not adjusted for SCI. For the unmodified hid_sci sample (3-byte reports), -ENOMEM during continuous sending is typically buffer exhaustion; enable ATT logs to confirm. You can try to increase CONFIG_BT_ATT_TX_COUNT / CONFIG_BT_L2CAP_TX_BUF_COUNT. 

Do you get the error with the unmodified example peripheral_hids_mouse HID SCI build (-DFILE_SUFFIX=hid_sci)? If not, what did you modify?

Do you continuously send (button held >2 s) or single button press? If the error occurs on a single button press (not continuous send), please describe your application changes — that would be unexpected for the unmodified 3-byte movement report.

Did you pair with central_hids HID SCI central or another host?

Could you provide the error log (CONFIG_LOG=y) with ATT warnings (CONFIG_BT_ATT_LOG_LEVEL_WRN=y)?