Wireless Latency

Wireless latency measures the time from when a packet is enqueued for transmission (via swc_connection_send()) to when the RX success callback fires on the receiving device.

Figure 90: Wireless latency components in three enqueue scenarios (best, typical, worst) sharing the same TDMA schedule. Latency is determined by whether the enqueue arrives before the next frame-prepare event for this connection (the ISR that selects the payload for the next assigned slot). Missing a prepare event forces a wait until the following prep, which adds one inter-opportunity gap to the transmission time. The fixed budget (CCA, packet airtime, post-RX decode, RX processing) is identical across all three cases; only the wait to catch the next prep changes.

Note

The proc and prep blocks shown in each slot correspond to the two MAC-layer activities documented in Figure 81: Wireless Core timing diagram:

• proc – end-of-frame processing (process_main / auto_frame_outcome), executed right after the TX+ACK IRQ to handle the outcome of the just-completed frame.

• prep – start-of-next-frame preparation (prepare_frame), which selects and writes the payload for the next scheduled slot.

Components

Component	Symbol	Description
Inter-opportunity gap	gap	Wait time from packet enqueue to the next TX preparation point
Wait for slot	wait_for_slot	Delay between the prep event (end of the preceding slot’s ISR processing) and the start of over-the-air activity in the target slot. Approximately prev_slot_duration - prev_TX+ACK - prev_processing. Not strictly constant: it varies per frame with the preceding slot’s payload size (airtime + SPI readout scale with payload) and retry outcome, typically over a range of tens to hundreds of us bounded by the preceding slot’s minimum and maximum possible payloads.
CCA delay	cca	CCA check(s) before transmission
Packet airtime	packet_airtime	Over-the-air transmission time of the packet
Post-RX decode	post_rx_decode	Radio hardware CRC verification and IRQ assertion after last bit received
RX processing	rx_processing	SPI readout, ISR processing, and context switch to deferred callback on the receiver

Formulas

Minimum (best case):

\[L_{\text{wireless,min}} = \text{wait_for_slot} + \text{CCA}_{\text{best}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing}\]

Best case assumes the packet is enqueued exactly before the next TX preparation point and the first CCA check passes immediately. Even with a near-zero wait to the prep event, the radio still idles for \(\text{wait_for_slot}\) before the target slot boundary.

Maximum (worst case):

\[L_{\text{wireless,max}} = \text{max_gap} + \text{wait_for_slot} + \text{CCA}_{\text{worst}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing}\]

Worst case assumes the packet just missed its TX preparation point and must wait the longest inter-opportunity gap, plus all CCA retries are consumed.

Typical (median):

\[L_{\text{wireless,typ}} = E[\text{wait}] + \text{wait_for_slot} + \text{CCA}_{\text{best}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing}\]

Where the expected wait is derived from the gap distribution:

\[E[\text{wait}] = \frac{\sum g_i^2}{2T}\]

\(g_i\) = duration of each inter-opportunity gap, \(T\) = total schedule period (sum of all gaps).

Note

The \(g_i^2\) term comes from weighting each gap by how likely a packet lands in it. Because enqueues are uniformly distributed in time, the probability of arriving in a gap of duration \(g_i\) is \(g_i / T\), and the expected wait within that gap is \(g_i / 2\). Summing the joint contribution over all gaps gives \(E[\text{wait}] = \sum_i \frac{g_i}{T} \cdot \frac{g_i}{2} = \frac{\sum_i g_i^2}{2T}\). The square means uneven gaps (a few large ones) inflate the expected wait more than an equal-gap schedule with the same period, which is why spreading timeslots evenly lowers typical latency.

Note

\(\text{wait_for_slot}\) is bounded, not constant. L_min uses its smallest value (preceding slot ran the longest possible TX+ACK + processing), L_max uses its largest value (preceding slot ran the shortest), and L_typ uses the expected value. The spread is driven by variance in the preceding slot’s payload size and retry outcome; see the Jitter Sources table below.

Non-Deterministic Nature

The Wireless Core does not provide deterministic latency. Packet delivery time varies from frame to frame due to multiple sources of jitter:

Table 75: Jitter Sources

Source	Cause	Impact
Enqueue timing	Application sends at arbitrary time relative to the TDMA schedule	Dominates: 0 to full gap
CCA contention	Shared spectrum; other transmitters may occupy the channel	0 to full CCA retry budget
Priority blocking	Higher-priority connections preempt lower-priority TX slots	0 to multiple gaps
Retransmission	Frame loss due to interference or fading requires re-sending	0 to retry count x gap
ISR jitter	Variable MCU interrupt latency and SPI transfer time	Microsecond-scale
Preceding-slot payload	Variable airtime + SPI readout in the preceding slot shifts the prep event within that slot, changing wait_for_slot for the target slot	Bounded by the preceding slot’s payload range; tens to hundreds of us
Link throttling	Runtime slot disabling changes effective gap	Increases gap unpredictably
RDO (Random Datarate Offset)	Intentional per-slot jitter injected to spread CCA attempts across concurrent networks	Small (bounded by the configured RDO step)
DDCM per-slot offset	Distributed De-Synchronization adds a small delay to each TX slot on network nodes to spread concurrent networks	~2.34 us per slot at 20.48 MHz (48 PLL cycles); the 1024-cycle (~50 us) recovery offset only triggers when the link has no recent successful transmission, so it does not affect steady-state data streaming

The formulas above provide bounds (min, max) and a statistical expectation (typical). The actual latency of any single packet is not predictable and will fall somewhere within the min-max range. Applications requiring hard real-time guarantees must design for the worst case and use buffering to absorb jitter.

Note

Under typical clean-link conditions (low PER, non-bursty interference), the dominant jitter source is the enqueue timing relative to the TDMA schedule. Because the application and the wireless schedule are asynchronous, the wait time from enqueue to the next TX opportunity is uniformly distributed over the inter-opportunity gap. This alone produces jitter equal to the full gap duration.

During interference bursts this bound no longer holds. Every retransmission adds one gap of latency, so a run of failed attempts easily produces jitter that far exceeds the worst-case latency derived from the gap alone. Application buffering must be sized for these loss bursts, not for the clean-link jitter (see Buffer as Burst-Bridge for the audio pipeline’s approach). Lower-latency applications are the most sensitive because their buffers are smaller and drain faster during a loss run.

Inter-Opportunity Gap

The inter-opportunity gap is the time between two consecutive selection points for the same connection. If a packet arrives in the TX queue immediately after a selection point, it must wait until the next one. This wait is the gap contribution to latency, and is the dominant variable component of wireless latency, so understanding it is key to schedule design.

Packet Selection vs. Transmission

The Wireless Core prepares each timeslot’s TX payload during the ISR processing phase that follows the preceding timeslot’s over-the-air event. The sequence is:

1. The application enqueues a packet (e.g., swc_connection_send()).

2. The radio IRQ fires at the end of the current timeslot’s air event.

3. In the ISR, the MAC processes the outcome of the current timeslot, then advances to the next timeslot.

4. During this advance, the MAC selects (peeks at) the head packet from the TX queue for the upcoming timeslot.

5. The packet is transmitted over the air when the connection’s timeslot actually begins.

6. After successful transmission (or unconditionally for best-effort), the packet is removed from the queue.

How Schedule Design Affects the Gap

The gap is determined by how the connection’s timeslots are distributed across the schedule:

Schedule design	Gap pattern	Latency impact
Single slot per schedule period	Gap = full schedule period	Max latency = schedule period
N evenly-spaced slots	Gap = schedule period / N	Latency reduced by N times
Clustered slots (e.g., slots 0,1,2)	Large gap between last and first slot of next schedule period	Worst-case latency approximately equals schedule period
Spread slots (e.g., slots 0, 4, 8 of 12)	Uniform gaps	Consistent low latency

Key insight: For a connection with multiple slots, spreading them evenly across the schedule period minimizes worst-case latency. Clustering them together provides no latency benefit over a single slot.

STAR Networks

In a STAR topology, every node added to the network increases the schedule period (more timeslots), which directly increases the inter-opportunity gap for all nodes. Worst-case wireless latency grows linearly with the number of devices sharing the schedule.

Important

STAR latency scaling rule.

In a symmetric STAR schedule with \(N\) nodes and per-node timeslot duration \(T_{\text{slot}}\), the schedule period is \(T_{\text{schedule}} = N \times T_{\text{slot}}\). Each node has one TX opportunity per schedule period, so its inter-opportunity gap equals \(T_{\text{schedule}}\) and its worst-case wireless latency is:

\[L_{\text{max}} \approx N \times T_{\text{slot}} + L_{\text{fixed}}\]

Concrete example at \(T_{\text{slot}} = 500\,\mu s\):

STAR size (N)	Schedule period	Worst-case wireless latency
2 nodes	1.0 ms	~1.0 ms + L_fixed
4 nodes	2.0 ms	~2.0 ms + L_fixed
8 nodes	4.0 ms	~4.0 ms + L_fixed
16 nodes	8.0 ms	~8.0 ms + L_fixed

The linear growth is the primary reason why real-time streaming applications limit STAR size and prefer shorter per-node timeslots or multi-slot allocations for critical connections (see the schedule-design rules above).

Optimized Latency Feature

The optimized latency feature (swc_connection_optimized_latency()) is an optional per-connection setting that is not enabled by default. It must be explicitly activated during connection initialization.

Mechanism. When a connection’s TX queue is empty at the moment the MAC prepares one of its timeslots, the Wireless Core delays that timeslot’s radio wakeup by empty_queue_max_delay. The delay equals the on-air duration of a full frame for that connection:

• With acknowledgement: main_frame_airtime + ACK_turnaround + ack_airtime + CCA_retry_budget

• Without acknowledgement: main_frame_airtime + CCA_retry_budget

Where CCA_retry_budget = cca_retry_time_pll_cycles x (cca_try_count - 1) (the primary CCA attempt is folded into the frame airtime; only retries contribute here).

Delaying the empty slot’s radio wakeup also delays the ISR that runs at the end of that slot’s brief wakeup activity. That ISR is where the MAC selects (peeks) the payload for the immediately-following timeslot. By pushing this peek later by empty_queue_max_delay, the feature gives the application an extra window to enqueue a packet that can still be transmitted in the very next timeslot.

The next timeslot’s sleep duration is then reduced by the same amount, so the absolute wakeup time of every subsequent slot is unchanged. Only the current empty slot’s activity and the peek that immediately follows it are shifted.

Figure 91: Optimized latency feature effect on a dedicated schedule where Conn A owns every slot and has the feature enabled; Conn A’s slot 1 queue is empty. Without optimization (top): the peek for slot 2 fires at its normal time during the empty slot 1, just before the enqueue, so slot 2 transmits empty; the packet is not selected until the following peek (fired during slot 2) and its transmission slips one slot to slot 3. With optimization (bottom): the empty slot 1 radio wakeup is delayed by empty_queue_max_delay, so the peek it triggers for slot 2 fires later and catches the enqueue; the packet is transmitted in slot 2, one slot earlier.

Important

Schedule constraint: the delayed peek is the peek for the slot that comes right after the empty one. That peek is only useful to this connection if it also owns that immediately-following slot. In practice the feature helps latency when:

• The connection owns consecutive slots in the schedule (e.g., slots 0 and 1).

• The connection owns every slot of a dedicated schedule.

For connections that own non-adjacent slots (e.g., [Conn A, Conn B, Conn A, Conn C]), the delayed peek is for another connection and this connection sees no latency benefit from the optimization. Slots further ahead are peeked at the normal absolute time because the compensation applied to the next slot’s sleep restores the schedule.

Timeslot-duration constraint. The feature requires each timeslot to be large enough to absorb the delay. If empty_queue_max_delay >= min_timeslot_duration, swc_connection_optimized_latency() returns SWC_ERR_OPTIMIZATION_DELAY_TO_HIGH.

Warning

Additional constraints:

• Only supports CCA fail action SWC_CCA_ABORT_TX.

• Must only be enabled on TX connections that are NOT auto-reply.

• Not compatible with ISI mitigation levels > 2 (enforced by API on SR1120).

• Not compatible with certification mode (enforced by API).

• Not compatible with dual radio mode. The multi-radio timer operates independently and is not aware of the delay applied to the main TDMA timer, causing radio desynchronization after delayed empty timeslots.

Initial Connection Latency (Fast Sync)

The latency discussed in the sections above is the steady-state per-packet latency once the link is synchronized. A separate concern is the initial connection latency - the time between the Node powering up and the first successful frame reception from the Coordinator.

Synchronization is asynchronous to the schedule: the Node listens for a Coordinator frame, and the frame arrives whenever the Coordinator’s TDMA slot for that Node comes around. This asynchrony makes the initial connection much faster than a strict “wait-for-schedule-alignment” would suggest, but it does not affect the latency of any subsequent frames.

Two modes are available (see Standard Sync and Fast Sync in the concepts documentation for the full mechanism):

Mode	Behavior	Initial connection latency
Standard Sync	Node duty-cycles its listener (sleep, wake, listen briefly, sleep again) and induces drift relative to the Coordinator to sweep the listen window until it lands on a Coordinator TX slot.	Up to one full duty-cycle period per attempt; bounded by the RF schedule period times the number of missed attempts
Fast Sync	Node listens continuously until a frame is received	Bounded by ~1 schedule period on average; typically catches the first Coordinator TX within one schedule cycle

Note

In Standard Sync, only Coordinator TX slots can be detected, so the Node’s RX-to-TX slot ratio in the schedule directly impacts sync time. A Node with a higher share of RX slots (frames coming from the Coordinator) syncs faster than one dominated by TX slots (Node-to-Coord traffic), which offer no sync opportunities.

Note

Fast Sync keeps the Node’s receiver powered continuously until it hears the Coordinator, so an unsynchronized Node draws significantly more power than in Standard Sync (which duty-cycles its listener). This trades power for a shorter and more predictable initial connection latency. It matters most for battery-powered Nodes that may spend a long time waiting for an absent or out-of-range Coordinator, where the continuous listen can drain the battery.

Note

Fast Sync only affects the initial synchronization phase. Once the link is established, per-frame wireless latency is governed by the formulas in Wireless Latency regardless of which sync mode was used at startup.

Note

Fast Sync is not compatible with dual radio mode (SWC_ERR_FAST_SYNC_WITH_DUAL_RADIO).

CCA Timing

See also

For the conceptual overview of CCA and the difference between the SWC_CCA_ABORT_TX and SWC_CCA_FORCE_TX fail actions (with diagram), see Clear Channel Assessment (CCA).

The CCA on-time (single energy reading duration) differs between platforms:

SR1120

The CCA on-time is a fixed 3.125 us regardless of chip rate. The API expresses cca_on_time / cca_retry_time as PLL cycles referenced to 20.48 MHz, and the Wireless Core rescales them internally at PHY-configure time so the on-wire time stays constant across 20.48, 27.30, and 40.96 MHz.

Note

The 3.125 us value is chosen to be longer than the ACK turnaround (~2.44 us on SR1120), so a single CCA sample window always overlaps either the main frame or the auto-reply. The sampling cannot fall into the silent gap between them and miss an ongoing concurrent transmission.

The retry_time parameter in swc_connection_concurrency_cfg_t specifies the total interval between readings (includes the on-time). The firmware subtracts the on-time before programming the radio register.

CCA retries are handled automatically in hardware. The radio performs all retry attempts autonomously within a single timeslot.

Default configurations (at 20.48 MHz chip rate):

Configuration	retry_time (PLL cycles)	Total try time (us)
Low-power default	96	4.6875
High-priority default	512	25.0

SR1020

Parameter	PLL cycles	At 20.48 MHz
CCA on-time	17	0.83 us

The retry_time parameter specifies the pause between readings (does not include the on-time).

CCA retries are manual (software-driven). Each retry requires MCU intervention via SPI to re-initiate the energy reading. This adds MCU overhead (SPI transaction time + ISR latency) to the effective retry delay, making the actual CCA worst-case time longer than the PLL cycle count alone suggests.

Default configurations (at 20.48 MHz chip rate):

Configuration	retry_time (PLL cycles)	Total try time (us)
Low-power default	0 (single attempt)	0.83 (on-time only)
High-priority default	512	25.83

CCA Worst-Case Formulas:

CCA Mode	Worst Case
Disabled	0
Abort (N retries)	\((N-1) \times \text{total_try_time} + \text{on_time}\)
Force TX (N retries)	\(N \times \text{total_try_time}\)

Where:

• SR1120: \(\text{total_try_time} = \text{retry_time_pll} / \text{chip_rate_MHz}\) (retry_time already includes on-time)

• SR1020: \(\text{total_try_time} = (\text{retry_time_pll} + \text{on_time_pll}) / \text{chip_rate_MHz}\)

Post-RX Decode Time

After the last bit of a frame is received, the radio hardware performs CRC verification and asserts the IRQ. This is a fixed silicon property.

SR1120

Chip rate	Post-RX decode
20.48 MHz	~2.64 us
27.30 MHz	~1.98 us
40.96 MHz	~1.32 us

SR1020

TBD (to be measured).

ACK Turnaround Time

When auto-reply (ACK) is enabled, the radio inserts a fixed turnaround delay between the end of the main frame reception and the start of the auto-reply transmission. This is handled entirely in hardware.

Platform	ACK turnaround (PLL cycles)	At 20.48 MHz
SR1020	18	0.88 us
SR1120	50	2.44 us

RX Processing Time

RX processing spans from the IRQ assertion to the application’s RX callback being invoked. It includes:

1. SPI/QSPI transfer of the received payload from radio to MCU

2. ISR state machine processing (frame outcome, next timeslot preparation)

3. Context switch from ISR to deferred callback context

The total can be approximated with a linear model:

\[\text{rx_processing} \approx \text{base_time} + (\max(0,\; \text{payload_bytes} - \text{threshold}) + \text{overhead_bytes}) \times \text{us_per_byte}\]

Note

The processing time is platform-dependent. The values below are representative for QUASAR (STM32U5 at 160 MHz SPI clock).

Example values (QUASAR, STM32U5, 160 MHz SPI):

• base_time = 58.0 us

• threshold = 80 bytes (SPI FIFO pre-fetch depth)

• overhead_bytes = 5 (1 command byte + 4 MAC header bytes, connection-dependent)

• us_per_byte = 0.2 us/byte (8 bits / 40 MHz effective rate)

Example with 64-byte payload:

\[\text{rx_processing} = 58.0 + (\max(0,\; 64 - 80) + 5) \times 0.2 = 58.0 + 1.0 = 59.0\,\mu s\]

Example with 128-byte payload:

\[\text{rx_processing} = 58.0 + (48 + 5) \times 0.2 = 58.0 + 10.6 = 68.6\,\mu s\]

Priority Blocking

When multiple connections share the same timeslots with different priorities, higher-priority connections are served first. A lower-priority connection may have its TX opportunity stolen.

See also

For the conceptual overview of connection priority (configuration, compatible-parameter constraints, use cases), see Connection Priority.

Figure 92: Priority blocking effect on a shared schedule. Top row: when the high-priority connection (Conn H) has no packets, Conn L uses every shared slot and its inter-opportunity gap is one slot. Bottom row: when Conn H bursts three packets, it steals slots 0, 1, and 2, extending Conn L’s effective gap to three slots before it finally transmits in slot 3.

The blocking rate \(B\) is:

\[B = 1 - \prod_{i \in \text{higher-priority}} (1 - \text{usage}_i)\]

This extends the effective maximum gap:

\[\text{max_gap_blocked} = \text{max_gap} \times \left(1 + \left\lceil \frac{\ln 0.01}{\ln B} \right\rceil \right)\]

And adds expected extra wait to typical latency:

\[E[\text{blocking_wait}] = \frac{B}{1 - B} \times \text{avg_gap}\]

Retransmission Impact (Stop-and-Wait ARQ)

The latency formulas above assume first-attempt success. When acknowledgement and Stop-and-Wait ARQ are enabled on a connection, failed transmissions are retried, extending worst-case latency.

See also

For the conceptual overview of the Stop-and-Wait ARQ mechanism (Retry Count vs Deadline vs Guaranteed modes), see Stop and Wait.

Figure 93: Comparison of the four delivery modes for the same “first TX fails” scenario. Best-effort sends once with no confirmation. Limited retry (try_deadline) retries up to N times. Deadline retry (time_deadline) retries until a wall-clock deadline expires and drops the packet if not delivered by then. Guaranteed delivery retries indefinitely and can block the connection queue.

There are three delivery modes:

Best effort (no ACK, no SAW):

No retransmissions. A frame is sent once; if lost, it is dropped. Latency bounds are as described in the formulas above.

Limited retransmission (retry count mode):

A frame is retransmitted until acknowledged or a maximum retry count is reached.

\[L_{\text{max}} = L_{\text{min}} + \text{gap} + \text{RetxCount} \times \text{gap}\]

Where RetxCount is the configured maximum number of retransmissions (try_deadline).

Limited retransmission (deadline mode):

A frame is retransmitted until acknowledged or a deadline timer expires.

\[L_{\text{max}} = L_{\text{min}} + \text{gap} + \text{DeadlineDelay}\]

Where DeadlineDelay is the configured timeout value (time_deadline).

Guaranteed delivery:

A frame is retransmitted indefinitely until acknowledged. At the level of a single frame’s ARQ, there is no upper bound on delivery latency:

\[L_{\text{max}} = \infty\]

This mode is nevertheless used routinely for real-time streaming (all SDK audio applications use it). Frame drops are handled upstream: when retries stall the head packet, the application layer (typically the audio pipeline’s producer queue) is what fills up and drops frames.

Throttling

Throttling (swc_connection_set_throttling()) selectively disables a portion of a connection’s timeslots at runtime. This reduces power consumption and frees MCU resources but directly increases the effective inter-opportunity gap.

See also

For the conceptual overview of link throttling (per-connection API, active-timeslot ratio, bidirectional constraints, complete example), see Link Throttling.

If a connection originally has \(N\) timeslots per schedule period and throttling disables a fraction \(R\) of them, the effective number of active slots becomes:

\[N_{\text{active}} = N \times (1 - R)\]

The effective inter-opportunity gap increases accordingly:

\[\text{gap_throttled} = \frac{\text{schedule_period}}{N_{\text{active}}}\]

All latency formulas use this throttled gap value when link throttling is active.

Note

Throttling will have a direct impact on the Wireless Core latency since it reduces the transmission opportunities in a given period of time. Consider latency requirements before using this feature.

Fragmentation

When a payload exceeds the connection’s max_payload_size, it is fragmented across multiple timeslots. Each fragment occupies one TX opportunity, and the receiver reassembles the full payload only after all fragments arrive.

See also

For the conceptual overview of frame fragmentation (segmentation, reassembly, header overhead), see Frame Fragmentation.

Figure 94: Fragmentation multiplies the number of slots required for one payload. Top: an un-fragmented payload delivers the RX callback after one TX+ACK. Bottom: a 3-fragment payload occupies three slots; the RX callback fires only after the last fragment is received and the full payload is reassembled.

The total latency for a fragmented payload is approximately:

\[L_{\text{fragmented}} \approx N_{\text{fragments}} \times \text{gap} + L_{\text{fixed}}\]

Where \(N_{\text{fragments}} = \lceil \text{payload_size} / \text{max_payload_size} \rceil\) and \(L_{\text{fixed}}\) is the single-frame fixed latency (CCA + airtime + post-RX + processing).

Fragmentation is disabled by default and must be enabled with swc_connection_set_fragmentation().

The packet airtime used in the latency formulas can be computed from the payload size and PHY configuration. See Packet Airtime for the calculation formula and tables.

Worked Example: Bidirectional HID (64-byte payload)

A coordinator and a peripheral exchange 64-byte packets over a 1 ms schedule with 2 timeslots (one per direction). PHY is IOOK at 20.48 MHz chip rate, FEC x1.25. CCA enabled with 1 retry (abort mode), minimum retry time (96 PLL cycles).

Schedule:

Timeslot	Duration	Connection	Direction
0	500 us	HID TX	Coordinator to Peripheral
1	500 us	HID RX	Peripheral to Coordinator

Schedule period = 1000 us. Each connection has 1 slot, so the inter-opportunity gap = 1000 us.

Component Values:

Component	SR1120 (IOOK 20.48 MHz)	SR1020 (IOOK 20.48 MHz)
CCA on-time	3.125 us (64 PLL cycles)	0.83 us (17 PLL cycles)
CCA worst (N=1, abort)	3.125 us	0.83 us
Packet airtime (64 B)	47.22 us (15.97 + 0.488 x 64)	TBD
Post-RX decode	~2.64 us	TBD
ACK turnaround	2.44 us (50 PLL cycles)	0.88 us (18 PLL cycles)
RX processing (64 B)	59.0 us (QUASAR)	59.0 us (QUASAR, same MCU)
Max inter-opportunity gap	1000 us	1000 us

Note

The SR1020 packet airtime is shorter than SR1120 for equivalent settings due to smaller preamble (94 vs 210 bits), SFD (32 vs 64 bits), address (8 vs 16 bits), CRC (16 vs 31 bits), and FEC trail (3 vs 4 symbols).

Note

With N=1 retry in abort mode, there is only one CCA attempt. If it fails, transmission is aborted. The worst-case CCA delay equals the best case because there are no retries. To see CCA retries add latency, configure try_count > 1.

Wireless Latency (SR1120):

Minimum (packet ready exactly at selection point, CCA passes):

\[L_{\text{wireless,min}} = \text{CCA}_{\text{best}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing}\]

\[L_{\min} = 3.125 + 47.22 + 2.64 + 59.0 = 111.99\,\mu s\]

Maximum (packet just missed selection point):

\[L_{\text{wireless,max}} = \text{CCA}_{\text{worst}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing} + \text{max_gap}\]

\[L_{\max} = 3.125 + 47.22 + 2.64 + 59.0 + 1000 = 1111.99\,\mu s\]

Typical (uniform arrival, single gap of 1000 us):

\[E[\text{wait}] = \frac{\sum g_i^2}{2T}\]

\[E[\text{wait}] = \frac{1000^2}{2 \times 1000} = 500\,\mu s\]

\[L_{\text{wireless,typ}} = \text{CCA}_{\text{best}} + \text{packet_airtime} + \text{post_rx_decode} + \text{rx_processing} + E[\text{wait}]\]

\[L_{\text{typ}} = 3.125 + 47.22 + 2.64 + 59.0 + 500 = 611.99\,\mu s\]

Wireless Latency (SR1020):

The same formulas apply. Replace the SR1120-specific constants with SR1020 values:

• CCA on-time: 0.83 us instead of 3.125 us

• ACK turnaround: 0.88 us instead of 2.44 us

• Packet airtime: TBD (shorter than SR1120 for equivalent configuration)

The inter-opportunity gap dominates latency in both cases. The fixed components (CCA + airtime + post-RX + processing) are smaller on SR1020 due to shorter CCA on-time, ACK turnaround, and airtime, yielding a lower minimum latency.

Reducing Latency:

If the HID TX connection is given 2 evenly-spaced slots (slots 0 and 2 in a 4-slot schedule of 1000 us), each gap becomes 500 us:

\[E[\text{wait}] = \frac{\sum g_i^2}{2T}\]

\[E[\text{wait}] = \frac{2 \times 500^2}{2 \times 1000} = 250\,\mu s\]

SR1120:

\[L_{\text{typ}} = 3.125 + 47.22 + 2.64 + 59.0 + 250 = 361.99\,\mu s\]

Doubling the slot count halves the typical latency contribution from the inter-opportunity gap.

See also

For audio-specific latency (pipeline stages, buffering, queue sizing), see Audio Latency.