Bandwidth
When designing the schedule, the user must consider the bandwidth requirements for every device. The peak data rate of a specific connection can be determined from the number of allocated timeslots within the schedule. The diagram below illustrates a scenario where a device with the address 0xCD01 has 3 times more link bandwidth than the device at the address 0xAAAA (assuming equally sized payloads and equal timeslot durations).
Figure 83: Wireless Core data rate
The timeslot duration and the schedule period itself are other factors that come into play for the bandwidth. The user must configure the duration of every timeslot when configuring the schedule.
The maximum datarate in kbps of a connection is given as :
\(datarate\,(kbps) = \frac{nTs \times Ps \times 8 \times 1000}{Sl \times Tt}\)
where \(nTs\) is the number of timeslots allocated to the connection in the schedule, \(Ps\) is the maximum payload size in bytes of the connection, \(Tt\) is the timeslots duration in microseconds and \(Sl\) is the total number of timeslots in the schedule.
Worked Example: Bidirectional Hello World (31-byte payload)
Based on the hello_world example application. A Coordinator transmits on the first timeslot and a Node transmits on the second, so each device’s connection uses a single timeslot.
Schedule:
Timeslot |
Duration |
Connection |
Direction |
|---|---|---|---|
0 |
500 us |
Coordinator TX |
Coordinator to Node |
1 |
500 us |
Node TX |
Node to Coordinator |
Schedule period = 1000 us (2 timeslots of 500 us).
Parameters:
Symbol |
Value |
Meaning |
|---|---|---|
\(nTs\) |
1 slot |
Timeslots allocated to the device’s connection |
\(Ps\) |
31 bytes |
Maximum payload (30-byte message plus its null terminator) |
\(Sl\) |
2 slots |
Total timeslots in the schedule |
\(Tt\) |
500 us |
Timeslot duration |
Datarate:
This 248 kbps is the datarate for a single device (one direction). Each device transmits in only one of the two 500 us timeslots (\(nTs = 1\)), while the denominator spans the full 2-timeslot schedule period (\(Sl = 2\)). The other device achieves the same 248 kbps on the opposite timeslot, for a combined 496 kbps across both directions.
Retransmission Margin
The retransmission margin consists of normally unused timeslots that can be used for retransmissions when the link starts to degrade. By accounting for a retransmission margin in the wireless schedule, we are in fact designing a link which allows for a higher throughput than what the application requires. A higher retransmission margin will increase the robustness of the link. The concept of retransmission margin only applies when the connection is using the Stop and Wait feature.
The retransmission margin is given as:
\(margin = \frac {cD - aD}{cD}\times100\)
where \(cD\) is the maximum data rate of the connection and \(aD\) is the data rate of the application for a given connection.
- Example:
Given a maximum connection data rate of 512 kbps and an application data rate of 384 kbps:
\(cD = 512kbps\);
\(aD = 384kbps\);
\(\frac {512kbps - 384kbps}{512kbps}\times100 = 25\%\)
Connection Priority and Timeslot Sharing
Multiple connections can share the same timeslots by assigning them different priorities (see Connection Priority). The highest-priority connection is served first; lower-priority connections transmit only when higher-priority connections have nothing to send.
This is a powerful schedule design tool. Instead of dedicating separate timeslots to each connection, timeslot sharing allows:
Combining audio and data on the same slots. A high-priority audio connection uses most timeslots, while a low-priority data connection opportunistically uses the remaining capacity.
Reducing the total number of timeslots in the schedule, which shortens the frame period and improves latency for all connections.
Dynamic bandwidth allocation. When the high-priority connection is idle (no audio playing), the full timeslot bandwidth is available to the lower-priority connection.
Impact on schedule calculations:
When connections share timeslots via priority, the bandwidth and latency formulas must account for the effective usage:
Bandwidth: The lower-priority connection’s effective bandwidth is the unused capacity of the shared timeslots. If the high-priority connection uses 75% of the timeslots on average, the low-priority connection gets at most 25%.
Latency: The lower-priority connection experiences priority blocking, which increases its effective inter-opportunity gap. See the priority blocking formulas in the latency guide.
Example: Audio + Data
An audio application uses 7 coordinator TX timeslots for both audio and data:
Connection |
Priority |
Usage |
Effective Slots |
|---|---|---|---|
Audio (stereo 48 kHz) |
0 (highest) |
~75% of timeslots |
~5.25 slots/frame |
Data (button, link margin) |
1 (lower) |
Remaining ~25% |
~1.75 slots/frame |
Both connections are initialized with the same 7 timeslots. The Wireless Core dynamically selects the highest-priority connection that has data to send at each timeslot.
Note
All connections sharing a timeslot must have compatible configurations (same local address, same ACK/SAW settings, same header features, same modulation/FEC). See Connection Priority for the full list of constraints.
Star Network Scaling
In a TDMA star network, every node added to the network requires additional timeslots in the schedule, directly increasing the frame period. This has a linear impact on bandwidth, latency, and power for all nodes.
Because each timeslot has a single transmitter, two different nodes cannot share an uplink timeslot to the coordinator: the coordinator would not know which node transmitted. Every node therefore needs its own dedicated TX timeslot, which is what forces the linear growth described below.
Example: keyboard and mouse to one dongle. A wireless keyboard and a wireless mouse are two independent devices (two transmitters) reporting to the same USB dongle, which is a small star network. Both are latency-sensitive. Ideally they would contend for the same pool of timeslots: whichever device has data would take the next available slot and reach the air at the earliest opportunity, keeping its inter-opportunity gap (and therefore its latency) as small as possible. Getting on air sooner is exactly what contention-based shared access buys you.
The single-transmitter rule prevents this. A frame carries only the destination address (the dongle), not the source, so the dongle cannot tell which device sent a frame in a shared slot, nor arbitrate a collision if both transmit at once. With no way to resolve contention on the receive side, the two devices cannot share timeslots.
The schedule must instead interleave dedicated slots between them (for example, keyboard on the even slots, mouse on the odd slots). Each device then only has an opportunity in its own slots, so its inter-opportunity gap is the spacing of those slots, roughly double what a shared, contended pool would give, and its latency grows accordingly. This is the same effect that makes per-node latency in a star network grow with the number of devices. See Wireless Latency for how the inter-opportunity gap drives latency.
For a star network with \(N\) nodes, each requiring a bidirectional link (1 TX + 1 RX timeslot per node) plus 1 sync timeslot for the coordinator:
The effects of adding nodes are:
Parameter |
Effect of Adding Nodes |
|---|---|
Frame period |
Grows linearly: \((2N + 1) \times T_{\text{slot}}\) |
Per-node bandwidth |
Decreases as \(1/N\) of the point-to-point case |
Worst-case latency |
Grows linearly with frame period (see Wireless Latency) |
Typical latency |
Grows linearly: \(E[\text{wait}] = \text{frame_period} / 2\) |
Power consumption |
Coordinator: increases (active every timeslot). Node: unchanged (sleeps during other nodes’ timeslots) |
Sync constraint |
Frame period must remain < 10 ms to maintain synchronization |
Example:
For 250 us timeslots with a bidirectional link per node:
Nodes |
Frame Period |
Per-Node Bandwidth (120 B) |
Typical Latency (per node) |
|---|---|---|---|
1 |
750 us |
1280 kbps |
~375 us |
2 |
1250 us |
768 kbps |
~625 us |
4 |
2250 us |
427 kbps |
~1125 us |
8 |
4250 us |
226 kbps |
~2125 us |
16 |
8250 us |
116 kbps |
~4125 us |
20 |
10250 us |
Exceeds 10 ms sync limit |
Note
For star networks approaching the 10 ms sync limit, consider:
Reducing timeslot duration (use faster PHY settings or smaller payloads)
Sharing timeslots between multiple nodes using connection priority
Using shorter timeslots for low-bandwidth nodes (timeslots need not be equal)
Sync Timeslot (Beacon)
The Sync Timeslot, or beacon, consists of a timeslot where the coordinator sends either a normal frame which contains a header and a payload or an empty frame which only contains a header. The transmission period for this beacon must not exceed 10 ms (see below). Having a longer interval will result in a loss of sync between the coordinator and the receiving node. If the coordinator does not have data to send at the time of the sync timeslot, the auto-sync feature can be used. The auto-sync feature lets the Wireless Core handle the transmission of the sync frame automatically, at the cost of additional power consumption and air time on otherwise idle timeslots. If the coordinator does not have data to send, its sync connection can have a FIFO size of 0. In a star or peer-to-peer network, this sync frame should be sent by the coordinator as a broadcast, eg with the address 0xFFFF.
Why 10 ms?
The Wireless Core monitors the time elapsed since the last successful frame reception. If no frame is received within an internal timeout (default: 21 ms, a 20 ms synchronization window plus a 1 ms scheduling buffer), the node declares synchronization lost and enters the re-syncing state.
The beacon period must be chosen so that at least two beacon transmissions fit within this timeout, including an allowance for scheduling jitter: \(\text{beacon_period} \leq (\text{sync_timeout} - \text{jitter}) / 2\). With the default 21 ms timeout, a 10 ms beacon period provides two reception opportunities (at 10 ms and 20 ms) after the last successful reception, so the node tolerates the loss of one beacon. Shorter periods increase the loss tolerance further: a 5 ms period tolerates three consecutive losses, making a desynchronization event statistically negligible on a healthy link. Periods above 10 ms leave a single reception opportunity, where a single lost beacon desynchronizes the node.
Warning
Declaring synchronization lost is not free even if the node is still physically able to receive. While re-syncing, a node suppresses transmission on all of its connections until synchronization is recovered, so all node-to-coordinator traffic stalls and the node’s transmission queues can overflow (audio pipelines will report consumer buffer overflows). In addition, when concurrency (DDCM) is enabled, the coordinator stops receiving acknowledgements from the silent node and, after its own sync-loss duration elapses, starts applying timeslot offsets to search for free air time, which moves its transmissions away from the timing the re-syncing node expects and further delays recovery. Choosing a beacon period with adequate loss tolerance avoids this failure mode entirely.
The 20 ms synchronization window itself is sized for the worst-case supported hardware. The receiver opens its reception window 7 us before the expected frame arrival (and the reception timeout extends a matching 2 x 7 us across it), so the accumulated timing error between the two devices must stay within this margin for a frame to be caught. Crystals with a tolerance of up to 100 ppm per device (200 ppm relative between two devices) accumulate approximately 4 us of drift over 20 ms, which fits within the 7 us margin. With typical 20 ppm crystals, the drift over the same window is only around 0.8 us. The re-sync threshold is therefore calibrated so the worst supported crystal remains receivable at the moment it trips: a node that declares synchronization lost is usually still within timing tolerance, but it must receive a frame to confirm its timing before it resumes transmitting.
Concurrency Considerations
The following figure shows 2 timeslots of a generic schedule operating with concurrency:
Figure 84: Generic concurrency schedule
During the first timeslot, the Network #1 transmitter executed CCA and determined that the air was free, so started to transmit on Channel #0. Network #2 transmitter also did a CCA, but slightly after Network #1 transmitter started to transmit, thus resulted in a failed CCA because Channel #0 was in use. Network #2 Transmitter then waited for a predetermined delay before retrying. At some point, its CCA succeeded, and it was able to transmit over Channel #0 because the other transmitter had completed its transmission.
During the second timeslot, both transmitters were able to transmit simultaneously as their CCA both succeeded. This is because the frequency separation (between Channel 3 and Channel 1) is high enough (at least 1 GHz separation). thanks to the random channel sequence mechanism managed by the Wireless Core.
In order to achieve proper concurrency, the following equations must be true:
\(T_{CCA} >= T_{AIR}\)\(T_{SLOT} - (T_{CCA} * Retry_{COUNT}) - T_{AIR} - T_{PROC} >= 0\)
Where \(T_{CCA}\) is the CCA delay, \(Retry_{COUNT}\) is the number of times the CCA check is done, \(T_{AIR}\) is the air time of the frame, \(T_{SLOT}\) is the timeslot duration and \(T_{PROC}\) is the processing time required by the Wireless Core. The processing time can be measured using the Profiler Tool.
The number of links supported without any frame delivery degradation \(N\) is equal to the following, rounded down:
\(N = \frac {(T_{CCA} * Retry_{COUNT})}{T_{AIR}}\)
CCA Retry Delay Quantization
The CCA retry delay (swc_connection_concurrency_cfg.retry_time) is quantized to multiples of
32 PLL cycles at the register level (~1.56 us at 20.48 MHz; truncated down, values below 32 become
0). Configure a multiple of 32 so \(T_{CCA}\) in the equations above matches the value the
radio actually applies.
The CCA retry delay (swc_connection_concurrency_cfg.retry_time) is quantized to multiples of
4 PLL cycles at the register level (~0.20 us at 20.48 MHz). Configure a multiple of 4 so
\(T_{CCA}\) in the equations above matches the value the radio actually applies.
Latency
Wireless latency is affected by schedule design, CCA configuration, and delivery mode. The Wireless Core does not provide deterministic latency; multiple sources of jitter affect packet delivery time.
See Wireless Latency for the complete latency evaluation guide including formulas, platform-specific values, and worked examples.
Packet Airtime
The over-the-air transmission time of a frame is a linear function of the SWC payload size:
\(\text{airtime} = \text{overhead} + \text{slope} \times N\)
Where \(N\) is the SWC payload size in bytes (the max_payload_size configured on the connection) and the overhead and slope depend on the radio family, modulation, and FEC level.
The slope scales as:
Where the base byte time at 20.48 MHz chip rate is:
0.3906 us/byte for IOOK (1 chip per bit)
0.7813 us/byte for 2-bit PPM (2 chips per bit)
The overhead captures the fixed part of the frame that doesn’t scale with \(N\). It aggregates two contributions:
Physical-layer synchronization (preamble + sync word) — emitted at a fixed chip count regardless of modulation or FEC.
Fixed header fields (address, packet-size field, CRC, FEC tail) — transmitted with the same modulation and FEC as the payload, so their effective on-air time scales with those settings.
Because the header bits pass through the same \(\text{mod} \times \text{fec}\) expansion as the payload, the overhead is not a single constant; it grows with the modulation and FEC level. It is computed as:
where \(\text{sync_chips}\) is the pre-header chip count (fixed) and \(\text{header_bits}\) is the total fixed-header bit count. The tables below give the resulting overhead values per (modulation, FEC) combination for each radio family.
Values at 20.48 MHz chip rate. Maximum payload: 255 bytes.
IOOK:
FEC |
Overhead (us) |
Slope (us/byte) |
Formula |
|---|---|---|---|
x1.0 |
14.99 |
0.3906 |
14.99 + 0.391 x N |
x1.25 |
15.97 |
0.4883 |
15.97 + 0.488 x N |
x1.5 |
16.80 |
0.5859 |
16.80 + 0.586 x N |
x1.75 |
17.63 |
0.6836 |
17.63 + 0.684 x N |
x2.0 |
18.46 |
0.7813 |
18.46 + 0.781 x N |
Figure 85: SR1120 IOOK airtime vs payload (one line per FEC ratio).
2-bit PPM:
FEC |
Overhead (us) |
Slope (us/byte) |
Formula |
|---|---|---|---|
x1.0 |
17.58 |
0.7813 |
17.58 + 0.781 x N |
x1.25 |
19.53 |
0.9766 |
19.53 + 0.977 x N |
x1.5 |
20.90 |
1.1719 |
20.90 + 1.172 x N |
x1.75 |
22.66 |
1.3672 |
22.66 + 1.367 x N |
x2.0 |
24.02 |
1.5625 |
24.02 + 1.563 x N |
Figure 86: SR1120 2-bit PPM airtime vs payload (one line per FEC ratio).
Values at 20.48 MHz chip rate. Maximum payload: 128 bytes.
IOOK:
FEC |
Overhead (us) |
Slope (us/byte) |
Formula |
|---|---|---|---|
x1.0 |
8.45 |
0.3906 |
8.45 + 0.391 x N |
x1.33 |
9.15 |
0.5208 |
9.15 + 0.521 x N |
x1.67 |
9.85 |
0.6510 |
9.85 + 0.651 x N |
x2.0 |
10.55 |
0.7813 |
10.55 + 0.781 x N |
Figure 87: SR1020 IOOK airtime vs payload (one line per FEC ratio).
2-bit PPM:
FEC |
Overhead (us) |
Slope (us/byte) |
Formula |
|---|---|---|---|
x1.0 |
10.35 |
0.7813 |
10.35 + 0.781 x N |
x1.33 |
11.75 |
1.0417 |
11.75 + 1.042 x N |
x1.67 |
13.15 |
1.3021 |
13.15 + 1.302 x N |
x2.0 |
14.55 |
1.5625 |
14.55 + 1.563 x N |
Figure 88: SR1020 2-bit PPM airtime vs payload (one line per FEC ratio).
Fragmentation Impact
When Frame Fragmentation is enabled on a connection, payloads larger than max_payload_size are automatically split across multiple timeslots. This has direct consequences on schedule design.
Bandwidth consumption:
Each fragment occupies one TX opportunity. A fragmented payload consumes \(N_{\text{frag}} = \lceil \text{payload_size} / \text{max_payload_size} \rceil\) consecutive timeslots before the next payload can be sent. During this time, no other payload can be transmitted on that connection (Stop-and-Wait holds the queue until all fragments are acknowledged).
The effective data rate for fragmented payloads is:
\(\text{datarate}_{\text{frag}} = \frac{\text{datarate}}{N_{\text{frag}}}\)
Latency impact:
The receiver does not deliver the payload to the application until all fragments have arrived. The total delivery latency is approximately \(N_{\text{frag}} \times \text{gap}\) (see Wireless Latency for the full formula).
Header overhead:
Fragmentation adds header bytes to each fragment: 4 bytes for the first fragment and 2 bytes for subsequent fragments. This reduces the effective payload capacity per fragment:
\(\text{effective_payload} = \text{max_payload_size} - \text{frag_header_size}\)
Design recommendation:
When possible, choose a max_payload_size large enough to avoid fragmentation. If
fragmentation is required, ensure the schedule provides enough TX timeslots to deliver all
fragments within the application’s latency budget. For example, a 500-byte payload fragmented
into 5 fragments of 100 bytes requires 5 consecutive TX opportunities per delivery.
Timeslot Sizing
The timeslot duration must be large enough to accommodate all over-the-air and processing activities that occur within it. The minimum feasible timeslot duration is:
Where:
Component |
Description |
Typical Value |
|---|---|---|
\(T_{\text{wake}}\) |
Transceiver wake-up time from sleep mode |
0.5 us (idle), 62 us (shallow), 3062 us (deep) |
\(T_{\text{proc}}\) |
MCU processing time (SPI transfer + ISR + frame prepare) |
50-106 us (payload-dependent, see below) |
\(T_{\text{CCA}}\) |
CCA budget (all retries, assumes |
|
\(T_{\text{air}}\) |
Main frame airtime (see Packet Airtime) |
Payload-dependent |
\(T_{\text{ACK}}\) |
ACK turnaround + ACK frame airtime (if ACK enabled, 0 otherwise) |
2.44 us (SR1120) + ACK airtime |
\(T_{\text{margin}}\) |
Safety margin for jitter and clock drift |
10-20% of the sum above |
Note
With SWC_CCA_FORCE_TX, add one extra retry_time delay to \(T_{\text{CCA}}\) for the
forced transmission after the last failed reading.
Processing Time
The MCU processing time depends on the payload size and the SPI clock speed. The following values are for the QUASAR platform (STM32U5, 160 MHz core, 40 MHz SPI):
Configuration |
Min (us) |
Avg (us) |
Max (us) |
|---|---|---|---|
TX only, 2 B payload |
49.5 |
49.9 |
50.2 |
TX only, 128 B payload |
77.9 |
78.3 |
78.6 |
TX only, 250 B payload |
105.4 |
105.7 |
106.0 |
RX only, 2 B payload |
54.0 |
54.3 |
54.7 |
RX only, 128 B payload |
67.6 |
67.6 |
67.7 |
RX only, 250 B payload |
95.0 |
95.0 |
95.2 |
Bidirectional (TX after RX) |
60.3 |
60.9 |
61.2 |
Note
Processing time must be included in a single timeslot only when consecutive timeslots belong to the same device. If the device has non-consecutive timeslots (other devices transmit in between), processing occurs during the intervening timeslot and does not need to be included.
Tip
For accurate measurements on your hardware, use the Profiler Tool which outputs processing time formulas for any payload size. A margin of 10% is recommended on profiler measurements.
Sleep Mode Constraints
The sleep mode imposes a minimum on timeslot durations because the transceiver needs time to wake up before it can participate in the over-the-air event. The minimum timeslot must accommodate the wake-up delay plus all other components:
Sleep Mode |
Wake-Up Delay |
Effect on Minimum Timeslot |
|---|---|---|
Idle |
0.5 us |
Negligible addition |
Shallow |
62 us |
Adds 62 us to the minimum |
Deep |
3062 us |
Adds 3062 us to the minimum |
The minimum timeslot duration for any sleep mode is:
\(T_{\text{slot,min}} = T_{\text{wake}} + T_{\text{proc}} + T_{\text{CCA}} + T_{\text{air}}\)
There is no fixed constant. The minimum depends entirely on the connection configuration (payload size, modulation, FEC, CCA settings) combined with the chosen sleep mode.
Important
By default (no sleep-level API call), all timeslots use IDLE. The application can:
Set one sleep level for the whole schedule via
swc_node_set_sleep_level(), orSet a level per timeslot via
swc_set_time_slots_sleep_level()(SR1100 only). The array must contain exactly one entry per timeslot in the configured schedule; the Wireless Core readsschedule.sizeentries and does not accept a length parameter, so passing a shorter array is undefined behavior. The API returns:SWC_ERR_NULL_PTRif the pointer isNULL.SWC_ERR_INVALID_TIMESLOT_SLEEP_LEVELif any entry is not one ofSWC_SLEEP_IDLE/SWC_SLEEP_SHALLOW/SWC_SLEEP_DEEP. Entries are fully validated before any write, so a failure leaves the previous per-timeslot configuration untouched.
Each timeslot must be at least as long as the minimum required for the sleep level entered before it. If any timeslot is shorter than that minimum, the transceiver will not wake in time and synchronization will be lost.
Worked Example
For a bidirectional link using IOOK FEC x1.25 at 20.48 MHz, 64-byte payload, with ACK, CCA enabled (4 retries, 96 PLL retry_time), shallow sleep:
Wake-up (shallow) |
62 us |
Processing (TX 64 B) |
~66 us |
CCA budget (96/20.48 * 3 retries) |
14.1 us |
Main frame airtime (15.97 + 0.488 * 64) |
47.2 us |
ACK turnaround |
2.44 us |
ACK airtime (15.97 + 0.488 * 0) |
16.0 us |
Subtotal |
207.7 us |
Margin (15%) |
31.2 us |
Minimum timeslot |
~239 us |
A timeslot duration of 250 us would be appropriate for this configuration.
Auto-Reply with Data Payload
When Auto-Replied Payload is enabled, the auto-reply frame carries application data in addition to (or instead of) a simple ACK. This increases the \(T_{\text{ACK}}\) component in the timeslot sizing formula because the auto-reply airtime grows with the payload size:
\(T_{\text{ACK}} = \text{ACK_turnaround} + \text{airtime}(\text{auto_reply_payload_size})\)
For example, with a 32-byte auto-reply payload using IOOK FEC x1.25 with the SR1120:
ACK turnaround: 2.44 us
Auto-reply airtime: 15.97 + 0.488 * 32 = 31.6 us
Total T_ACK: 34.0 us (vs 18.4 us for an empty ACK)
This adds ~16 us to the minimum timeslot in this example. For large auto-reply payloads, the impact can be significant and must be included in the timeslot sizing calculation.
Note
The auto-reply payload size is determined by the auto-reply connection’s max_payload_size configured at initialization. Both the transmitter and receiver must use timeslots large enough to accommodate the main frame plus the auto-reply frame.
Schedule Design Trade-off
There are always trade-offs between latency, maximum data rate and link budget for any schedule design.
From the Wireless Latency formulas, frame air time and the connection refresh period should be decreased in order to reduce latency. However, decreasing those parameters can result in lower maximum data rate and/or link budget.
The 3 main factors that impact frame air time and connection refresh period are modulation, FEC ratio and payload size. For modulation and FEC ratio, there are 2 recommended configurations:
2 bit PPM, FEC x1.334: This will yield better link budget but longer frame air time.
IOOK, FEC x1.667: This will yield lower link budget but shorter frame air time.
There are five main factors that impact frame air time and connection refresh period on the SR1120:
Payload size
Refer to each of these factors for more in-depth explanations of their impacts on airtime. For modulation and FEC, the recommandation for SR1120 is:
IOOK, FEC x1.25: This will yield optimal link budget with shorter frame air time.
Increasing FEC, symbol averaging and ISI mitigation will also increase the link budget at the cost of higher frame airtime.
A large payload which minimizes PHY overhead results in higher application data rates at the expense of higher latency and lower link budget.
A smaller payload with shorter air-time results in lower latency and higher link budgets at the expense of lower application data rates due to higher PHY overhead.
The table below, summarizes the effects that payload size and Modulation/FEC have on Link Budget, latency and data rate.
Figure 89: Schedule design trade-offs