BLE Throughput

Step 1: Define the transfer contract

DEFINE slow-transfer diagnosis | target throughput | firmware update | sensor stream | latency/power tradeoff | iOS/Android interoperability | embedded-to-embedded | GATT versus L2CAP CoC.
IDENTIFY direction, useful bytes, transfer size/duration, latency/deadline, loss/retry semantics, central/peripheral and client/server roles, foreground/background state, peer/controller/stack/OS versions, supported Core features, RF range/environment, power budget, and concurrent radios/connections.
SELECT the metric before tuning: useful application bytes accepted by the receiver per elapsed steady-state second. Record latency, energy, failures, retries, and memory separately.
TREAT PHY headline rates and article/device examples as context, never guarantees. Historical iOS/Android packet-count/MTU limits are not current platform constants.
READ references/source-notes.md to distinguish current specification/platform facts from empirical guidance.

Completion: workload, direction, useful-byte boundary, device matrix, tradeoffs, and acceptance thresholds are explicit.

BUILD a release-like sender/receiver with sequence numbers, useful-byte counters, monotonic timestamps, queue depth/high-water marks, and explicit completion/checksum.
WARM the connection through service discovery, security, MTU, data-length, PHY, and connection-parameter procedures before the measurement window.
RECORD requested and effective PHY per direction, ATT MTU, LL max TX/RX octets/time, connection interval/rate, peripheral latency/subrate, event duration, data packets per event, operation type, payload size, encryption, RSSI, retries, and app callbacks/backpressure.
CAPTURE an over-the-air trace when effective parameters, retransmissions, More Data behavior, or event closure is uncertain. Host logs alone cannot prove on-air scheduling.
RUN repeated long-enough trials across device/OS/RF/background/Wi-Fi/concurrency conditions; report distribution and failures, not the best run.