The Wireless Core always operates in Time Division Multiple Access (TDMA) mode. It divides time into multiple slices called timeslots. Each timeslot is a portion of time reserved for a specific event. The sum of all the timeslots is called a schedule. This TDMA approach is very efficient in terms of power consumption. Most of the time, a device can be asleep. It will wake up only to transmit or receive a frame on its dedicated timeslot.
To maximize the usage of air time, the length of the timeslots in a TDMA schedule can be adjusted with a precision of 1 microsecond. On a given network, the schedule must be known to all the Nodes and cannot change at runtime. The schedule specifies when and for how long a given Node is allowed to transmit or receive a frame. When the schedule reaches the last timeslot, it loops back to the first one.
The illustration above shows a basic schedule which enables bi-directional communication between two devices. Information is exchanged in one direction during the first timeslot, and in the other direction during the second timeslot. The schedule repeats indefinitely.
Timeslot duration is determined by the frame air time and inter-frame spacing required for the MCU to fetch/retrieve and process data for each frame. The inter-frame spacing will mostly depend on the MCU performance characteristics and the effective SPI speed.
The figure above shows an example of a star network schedule where the air time (colored rectangles) and processing time periods are identified. The processing time must be included in a single timeslot for consecutive over-the-air events to occur for the same device (e.g. Coordinator Timeslot Index 1 to Index 2). If the over-the-air events are non-consecutive, processing can occur during the other devices Timeslot Index (e.g. Coordinator Timeslot Index 3).
The processing time can be measured using the Profiler Tool.
To optimize UWB spectrum usage and avoid breaking the regulatory emission limits, frequency switching is used.
The strategy consists of spreading pulse energy over a wider spectrum by cycling through selected frequencies at each timeslot.
The Wireless Core can be configured to use different frequencies in consecutive timeslots by providing it with a list of channels. For every timeslot, the Wireless Core will tune the radio to the next channel in the list. As a result, the list is cycled independently from the connections.
The Wireless Core addresses are 23-bit long. The first 15 most significant bits are used for the PAN ID and the remaining 8 least significant bits are used for the node address.
The PAN ID (Personal Area Network Identification) is used to group multiple nodes into logical networks. Nodes from different networks are not able to communicate with each other. It is one of the feature enabling concurrency.
Valid PAN IDs range from 0x001 to 0x7FFE. 0x000 and 0xFFFF are reserved.
A frame containing the 0xFF destination address will be treated as a broadcast in the selected PAN. Every node part of the PAN will receive the frame as if it was specifically sent to them.
A connection is defined by a unidirectional link between a source address and a destination address. A single device can use one or multiple connections. For a device to send data, a connection must be associated with one or more timeslots within the schedule. Since a connection defines a unidirectional data stream, a timeslot can contain two connections: one for the main transmission and one for the auto-reply (if enabled).
A connection between two devices must share the same network configuration. Within this configuration, a payload queue is assigned to the connection. When the connection’s active timeslot occurs, the oldest element is removed from the queue and scheduled for transmission.
It is possible to send data to multiple devices within the same network with one connection using a broadcast address: 255 (or 0xFF). The transmitting device will then communicate with every device within reach that are part of the same network (same PAN ID).
An over-the-air frame identifies who it is sent to (the destination address) but not who sent it. This is a constraint of both the SR1000 and SR1100 transceivers: the hardware frame format carries a single address field, so the Wireless Core cannot add a source address in software. A receiver therefore cannot discover the sender from the frame itself; it must already know, from the shared schedule, which device is expected to transmit in a given timeslot. As a consequence, each timeslot has exactly one transmitter, its owner. Two different devices cannot transmit in the same timeslot, because the receiver would have no way to tell them apart. For this reason, the Wireless Core does not support timeslot access contention; every timeslot is statically owned by a single transmitter.
This is the underlying reason for the timeslot-sharing constraint: several connections can share a single timeslot (see Connection Priority) only when they all originate from the same device (same local address), since they then share the one known transmitter. Connections that belong to different devices always require their own dedicated timeslots.
A remote node represents a peer device in the wireless network with which the local node communicates. When a connection is initialized, the Wireless Core automatically creates a remote node for the peer device identified by the connection’s remote address (i.e., the source address of an RX connection, or the destination address of a TX connection). If multiple connections to the same network share the same remote address, they are all associated with the same remote node object.
The remote node serves as a logical anchor for all connections to a given peer, allowing the Wireless Core to efficiently manage per-peer state.
Each channel defines the frequency and the power settings of the transceiver to use when a transmission occurs over said channel. The Wireless Core must be provided with an array of channels on which it will iterate; that is the channel sequence. Each connection has its own set of configurations for a given channel.
The SPARK transceivers have a built-in auto-reply functionality that allows a receiver to transmit a frame immediately after a successful reception. While generally used for acknowledgements only, this auto-replied frame can also contain a payload. The reply packet is sent automatically by the hardware, without requiring any host processor intervention. This feature can be useful in applications where low-latency, non-critical back-channel communication is desired. While the Wireless Core allows transmission of data inside them, it does not support acknowledgements of auto-replied frames. A data stream transmitted through auto-replied frames is considered “best-effort” since no retransmission mechanism can be leveraged in case of frame loss.
When enabled, the receiver of a main frame will auto-reply an acknowledgement (ACK) to notify the transmitter that the reception was successful. This allows the Wireless Core to put a retransmission mechanism in place in case a main frame is not acknowledged, enabling guaranteed delivery or limited retransmission links. The ACK frame does not contain a payload.
A connection can make use of the auto-reply to transmit data in a best-effort manner. The auto-replied frame can also optionally contain an acknowledgement of the main frame alongside the payload, keeping the ability of the main frame transmitter to use a retransmission mechanism. However, the Wireless Core does not offer the possibility to acknowledge auto-replied frames, making this type of data transmission a best-effort one.
The auto-reply payload is pre-staged. It is loaded into the radio before the main frame is received. The receiver cannot inspect the incoming main frame and decide which auto-reply data to send back. The auto-reply must be enqueued in advance, similar to how main TX payloads are selected from their queue at frame preparation time.
Consequences:
Each auto-reply payload can be up to the auto-reply connection’s max_payload_size. The actual length is chosen at enqueue time, so successive auto-replies may carry different content and different sizes. The oldest enqueued payload is sent on the next main frame successfully received in a timeslot allocated to that auto-reply connection.
If the auto-reply queue is empty when the timeslot is prepared, an empty auto-reply
(ACK only) is sent.
ReTX (ARQ) is not supported on the auto-reply payload: lost auto-replies frames are not retransmitted by the Wireless Core.
An auto-reply cannot be computed from the received request. Because the payload is pre-staged, it is committed before the main frame is inspected.
Applications that need to answer with data derived from the received frame (for example, a query that returns a matching record) must use separate application TX/RX connections on distinct timeslots so the receiver has time to process the request and enqueue a targeted response.
Note
Auto-replied frames cannot be acknowledged. There is no way to retransmit a lost auto-reply payload. Applications that require reliable bidirectional communication should not use auto-reply for the return path. Instead, use two dedicated application-payload TX connections (one per direction), both with ACK enabled and the desired Stop-and-Wait mode (limited retry, deadline, or guaranteed delivery). The two connections can share the same timeslot pair, alternate across timeslots, or be scheduled independently depending on latency and throughput requirements. This pattern is also the way to implement request-response exchanges where the answer must be derived from the received request.
Upon power up, the Node will listen for a message from the Coordinator. If none is received, it will go to sleep for a predetermined amount of time and then retry listening. This method will limit power consumption of the receiver by duty cycling the listening periods instead of listening continuously for a message from the Coordinator which might not be active yet. This method usually allows the device pair to achieve synchronization in a short period of time when the frame rate on the Coordinator is high.
Upon power up, the Node will continuously listen for a message from the Coordinator until it successfully receives a frame. This synchronization method is less power efficient, but will yield faster synchronization because the Node should catch frames from the Coordinator as soon as they are sent. This method should be used when the frame rate on the Coordinator is too low for the standard sync to maintain a reliable synchronization or to ensure a quick synchronization at startup.
Note
The synchronization delay depends on the defined RF schedule and the RF conditions, regardless of the synchronization method. A schedule with shorter timeslots or more synchronization frames and good RF conditions will result in a short synchronization delay. On the other hand, a schedule with longer timeslots or less frequent transmissions from the Coordinator will lead to longer node synchronization delays.
In applications where antenna placement is challenging, two transceivers can be used to increase coverage. Since this allows both transceivers to redundantly receive frames, the Wireless Core is free to choose which transceiver to use for transmission based on the received signal strength.
Note
Enabling this feature will increase the processor load of the Wireless Core by about 1.5 times the equivalent single radio scenario (varies depending on application).
The second transceiver must use a dedicated SPI bus and DMA channel, independent of the first one, to allow for simultaneous data transfers. A 16-bit timer running at +/- 5% of the chip rate (e.g., 20.48 MHz) provided by the MCU is also required. The timer period must be configurable by the Wireless Core. The timer priority must be the highest in the system. It must exceed the radio’s IRQ and SPI DMA IRQ priority.
To use the certification mode with dual radio, the swc_set_multi_radio_select_mode function can be used to select which radio to use. Otherwise, only the main radio would transmit packets.
In any topology, the link between two Nodes can be either unidirectional or bidirectional. A given Node should always receive frames from its syncing Node at least every 10 ms in order to maintain synchronization on the network. Note that the topology of the network is entirely defined by the user configuration. Different topologies are discussed in the sections that follow.
See also
For the 10 ms synchronization limit, its loss-tolerance margin, and how the beacon (sync timeslot) maintains it, see Sync Timeslot (Beacon).
Note
Routing is not currently supported by the Wireless Core and must be handled by the application.
In a peer-to-peer network, each Node can communicate with any other Node, but the Coordinator must send a frame to every other Node at least every 10 ms to maintain synchronization (see Sync Timeslot (Beacon) for the margin behind this limit). In most cases, this frame will be sent in the form of a broadcast and is often referred to as a beacon.
In a cluster tree network, Nodes can sync on a child Node of the Coordinator rather than on the Coordinator itself. The support of this configuration is still limited and the relaying of a frame through multiple Nodes must be handled by the application.
The Wireless Core supports a set of features that can be used to optimize link quality in environments where interferences from other devices are present. Those devices can either be other SPARK-enabled devices or not, such as Wi-Fi routers. The concurrency features are described in the next sections.
The PAN ID, is used to logically split the addressing space into networks. This ensures that transceivers with a certain PAN ID do not receive frames sent by devices that have a different PAN ID, even if the destination node address matches.
A random channel sequence can be generated by the Wireless Core to reduce the probability of collisions in the frequency domain. The sequence is generated using the PAN ID as the seed and overrides the channel sequence specified by the user. Other channel properties are maintained.
Note
The Wireless Core will override the channel sequence provided by the user with its own auto-generated random sequence when this feature is enabled.
Clear Channel Assessment (CCA) is a mechanism used to determine if a given frequency is currently in use or not. This mechanism is used by the Wireless Core to avoid collisions resulting from concurrent transmissions. Collision avoidance is achieved by delaying the transmission within the same timeslot. If the connection’s timeslot ends and the CCA did not succeed, the transmission can be postponed to the next connection’s timeslot or it can be transmitted anyways depending on the CCA configuration.
See also
The retry_time delay is quantized at the register level. See CCA Retry Delay Quantization for the per-radio quantization step and configuration guidance.
CCA Fail Action
Each CCA-enabled connection configures a fail action (fail_action in swc_connection_concurrency_cfg_t) that decides what happens when all try_count CCA attempts fail (channel remains busy):
SWC_CCA_ABORT_TX — abort the transmission. The packet is not sent in this timeslot and
stays in the TX queue. The Wireless Core will attempt to send it again at the connection’s
next timeslot. This avoids risking a collision with another device on the channel, at the
cost of one inter-opportunity gap of extra latency.
SWC_CCA_FORCE_TX — do all try_count CCA readings; if all fail, apply one more
retry_time delay without any CCA reading and then transmit anyway. This bounds the
worst-case in-slot delay to Nxretry_time+airtime and, more importantly, lets the
connection keep transmitting when CCA reports the channel busy for reasons that are not an
actual in-band transmission (see the note below). The trade-off is a higher risk of
colliding with a real transmission from another device (typically a node of a
concurrent network) that genuinely owns the channel.
Note
Fail action and the maximum try count. Both fail actions perform exactly try_count CCA readings; the fail action only decides what happens after the last reading fails. On SR1120, however, the two actions do not share the same maximum try_count: SWC_CCA_ABORT_TX allows up to 16 tries while SWC_CCA_FORCE_TX is capped at 15. On SR1000 the retries are software-driven, so no such per-action cap applies.
Note
Why FORCE_TX exists. CCA is an energy detector and is deliberately very sensitive, and the receiver listens over a bandwidth wider than the transmit bandwidth. As a result, CCA often reports the channel busy when there is no real in-band transmission to collide with, for example:
strong energy in an adjacent band bleeding into the wide CCA measurement window, or
receiver saturation from a nearby strong emitter, which produces harmonics that fall in
our band and are read as in-band energy.
In these conditions SWC_CCA_ABORT_TX keeps deferring the packet even though the channel is actually usable, which can stall the link. SWC_CCA_FORCE_TX lets the link push the frame through. Use it when favoring latency matters more than avoiding a collision, accepting the risk of colliding with a genuine transmission from another network, which would corrupt both transmissions.
Figure 67: Comparison of SWC_CCA_ABORT_TX and SWC_CCA_FORCE_TX for the same scenario (three CCA attempts, channel busy for all three). ABORT_TX bounds the slot’s CCA time but adds an inter-opportunity gap of latency; FORCE_TX bounds total latency in the slot but risks collision.
See also
Detailed CCA timing values (on-time, default retry configurations, worst-case formulas per platform) are in the CCA Timing section of the latency documentation.
The Random Datarate Offset (RDO) feature intentionally adds a small amount of jitter to the link timings. This timing offset helps CCA performance in situations where devices listen at the same time and then transmit at the same time. The offset does not affect the overall link throughput and has the most impact when concurrent networks have the exact same schedules.
The jitter magnitude is user-configurable via swc_init_rdo(rollover_value,step_ms) and enabled with swc_enable_rdo. The maximum offset added per timeslot is bounded by the configured rollover_value; the step at which the offset is updated is controlled by step_ms.
See also
RDO appears in the Wireless Latency jitter sources table as a bounded per-slot jitter contribution.
The Distributed De-Synchronization algorithm aims to optimize the air-time allocation of concurrent networks by de-synchronizing the Coordinator of an network from other transmissions. To do so, the transmission will be delayed to reduce the amount of CCA retry required for a transmission. To ensure that the node stays synchronized to the Coordinator, only a small amount of delay is applied for each transmission. By default, this delay is 48 PLL cycles (~2.34 us at 20.48 MHz).
This small per-slot delay is what applies during normal, healthy operation of the link. Once transmissions succeed regularly, DDCM keeps injecting this ~2.34 us offset per TX slot on the network node to spread concurrent networks apart in the time domain.
If the link degrades to the point where no successful transmission is achieved for a certain period, a larger recovery offset of 1024 PLL cycles (~50 us at 20.48 MHz) is applied instead to help the node find a free slot in the air-time allocation. This larger offset only kicks in during link recovery and does not contribute to per-packet latency during normal data streaming.
This algorithm works particularly well when all networks timeslot durations are integer multiples of each other. For example, a network with timeslots of 100 us (10 kHz) will work well with a network with timeslots of 200 us (5 kHz). When timeslots are not integer multiples, the algorithm struggles to maintain the optimal phase between networks.
See also
The steady-state ~2.34 us DDCM offset appears in the Wireless Latency jitter sources table. See Wireless Latency for how it composes with the other per-slot components.
SPARK transceivers support 3 sleep modes which are, from the lightest to the deepest, idle, shallow and deep. The transceiver will automatically fall into the selected sleep mode once it has completed a transmission or reception and wake up for the next event, enabling considerable power savings. The deeper the sleep mode, the higher the wake-up delay is. This has to be taken into consideration when configuring the timeslots duration. For example, the idle sleep mode will enable the use of shorter timeslots since the transceiver can wake up much faster than when using the other sleep modes. Please refer to the transceiver’s datasheet for more information on sleep modes.
See also
For how each sleep mode’s wake-up delay sets the minimum timeslot duration, see Timeslot Sizing.
Shallow sleep usage requires the timeslots duration to be higher than 185 us. Deep sleep usage requires the timeslots duration to be higher than 3062 us.
Shallow sleep usage requires the timeslots duration to be higher than 185 us. Deep sleep usage requires the timeslots duration to be higher than 3062 us.
Note
The sleep modes can only be set globally for all timeslots since the transceiver can’t switch between modes without losing synchronization. Consequently, the Wireless Core must be completely reset and reconfigured to be able to change the global sleep mode setting. Doing so requires a considerable amount of time (several milliseconds), so application downtime is to be expected if it must be done at runtime.
The SR1100 support four different modulations. Each of these modulation schemes has its benefits and drawbacks. For example, it will take half the time to transmit a frame in IOOK when compared to 2-bit PPM, but a better link budget is expected when using 2-bit PPM.
The coding for both these schemes is shown below:
IOOK: Use IOOK modulation for high data rate applications.
OOK: Use OOK modulation for low power applications.
2-bit PPM: Use 2-bit PPM to obtain higher link budget.
PPM: Use PPM for maximum link budget at the cost of maximum power.
Two modulation schemes are available which are Inverted On-Off Keying (IOOK) and 2-bit Pulse Position Modulation (2-bit PPM). Each of these modulation schemes has its benefits and drawbacks. For example, it will take half the time to transmit a frame in IOOK when compared to 2-bit PPM, but a better link budget is expected when using 2-bit PPM.
The coding for both these schemes is shown below:
IOOK: Use IOOK modulation for high data rate applications.
2-bit PPM: Use 2-bit PPM to obtain higher link budget.
The chip repetition parameter is a setting at the PHY (Physical) layer, determining the level of redundancy applied to each chip within a frame. For all chip modulation codes except for OOK modulation codes, this parameter dictates the number of times each chip is repeated to construct a symbol within the frame data. The frame data encompasses every symbol following the Start-of-Frame Delimiter (SFD), without exception.
By allowing multiple repetitions of chips, this feature offers a trade-off between bandwidth, energy consumption, and increased link margin. This trade-off enables achieving a significant boost in link margin, which might not be achievable otherwise.
The goal of the FEC is to correct errors which might occur during over-the-air transmissions, making the RF link more resilient. To do so, redundant bits are automatically added to the bitstream before it is sent out by the transmitter. Since the frame size increases because of the extra bits, the air time also increases which may impact the minimal timeslot length required and the concurrency performance. The output power settings must be also be considered, as more overall energy is outputted.
See also
For the quantitative effect of the FEC ratio on frame airtime (fixed overhead and per-byte slope), see Packet Airtime.
The SPARK Radio can support many ratios of FEC. Each ratio is defined by its redundancy rate. The redundancy rate is the factor by which the frame size is inflated. The FEC ratio 1 corresponds to disabling it, and as such, will not inflate the frame. At its maximum ratio, the FEC will double the frame size.
ISI mitigation is a parameter of the SPARK Radio that ensures seamless data exchange by managing Inter-Symbol Interference. It is achieved by adding ISI mitigation pauses, which are brief intervals inserted before each symbol to prevent interference caused by the channel impulse response extending beyond one chip clock period. These pauses help separate symbols, ensuring data integrity.
Users can adjust the number of ISI mitigation pauses using a PHY layer parameter. This parameter determines the frequency of pauses.
Different values provide flexibility in managing ISI. Options like ISI Mitigation level 1 or 2 allow users to observe channel responses while conserving bandwidth and energy by adjusting the number of pauses. This adaptability is crucial for environments where ISI risk may vary over time.
Suitable when ISI risk is low but may increase over time.
2 and 3
Useful for observing channel responses and making informed decisions to optimize bandwidth and energy usage.
In essence, ISI mitigation ensures reliable data transmission by strategically managing interference, providing users with the flexibility to adapt to changing channel conditions while optimizing performance at the cost of increased air time.
The chip rate setting determines the frequency at which the internal chip clock operates within the transceiver. This frequency directly affects the rate at which data is transmitted over the air.
Users can select from three available clock frequencies, depending on the radio model.
The chip rate optimizes data transmission by controlling the internal chip clock frequency, ultimately influencing the timing and efficiency of communication over the airwaves at the cost of immunity to Inter-Symbol Interference.
The Stop and Wait control mechanism handles frame retransmissions automatically when a frame is not acknowledged. The acknowledgements on the connection must be enabled to use this feature. There are two modes for the Stop and Wait mechanism: “Retry Count” and “Deadline”. The first mode will count the number of retransmission attempts before deciding to discard a frame. The second mode will discard a frame if it is not delivered after a certain amount of time. The timeout for the second mode is set in number of ticks. The tick duration is defined by the user depending on the HAL implementation.
For a guaranteed delivery quality of service, both timeout settings must be set to 0. That way, the stop and wait module will retransmit the frame indefinitely until the frame is acknowledged. This mode is used both for non-real-time transfers (e.g. file transfers, firmware updates) and for real-time audio and video streaming. When it is used with a real-time stream, the Wireless Core keeps retrying the head packet, and any frame drop is handled upstream by the application layer (typically the audio pipeline).
See also
For the latency impact of each Stop-and-Wait mode (best-effort, retry count, deadline, guaranteed) with a side-by-side timeline, see Retransmission Impact (Stop-and-Wait ARQ).
The credit-based flow control mechanism provides flow control for data rate transmission. Prevents the network from losing frames in case of congestion, as in the following scenario.
To control the flow, the frame header contains a field with the number of credits. The credit value will represent the number of packets that device can send during the connection. Each packet transmission consumes one credit. When the credit reaches zero, the receiver must grant more credits to allow more packets to be sent. If there are no available credits, the device may send a frame with only header data to update the current credit status. The acknowledgements on the connection must be enabled to use this setting. An example credit flow control sequence is presented below.
The frame fragmentation mode enables users to transmit payloads that exceed the maximum payload size of the connection. The Wireless Core will automatically segment the application payload into multiple fragments and enqueue them as multiple frames in the connection’s TX queue. Upon reception, fragments are buffered in the RX queue until the last fragment is received. The reception of the last fragment triggers reconstruction of the frame and the Wireless Core then notifies the user through an RX callback. The biggest payload that can be sent is limited by the size of the connection queue and the connection’s maximum payload size. The fragmentation adds 4 bytes to the header of the first fragment and 2 bytes to the header of subsequent fragments.
Every fragment carries a control byte (identifying the transaction and the fragment type) and a fragment index. The first fragment additionally carries the total size of the reassembled payload, so the receiver can size its reassembly buffer before the remaining fragments arrive. This extra 2-byte size field is what makes the first fragment’s header 4 bytes instead of 2. The following table summarizes the header content of each frame type:
Control byte, fragment index, total payload size (2 bytes)
Subsequent fragment (middle or last)
2 bytes
Control byte, fragment index
See also
For how fragmentation multiplies per-payload latency and a timeline diagram of the multi-slot delivery, see the Fragmentation section in the latency documentation.
For how fragmentation consumes TX timeslots and reduces the effective payload capacity in a schedule, see Fragmentation Impact.
The Wireless Core gives the user the possibility to define alternative settings for a packet size smaller or equal to the threshold. This allows an increase of power and CCA try count when the application reduces its throughput by providing smaller payloads. This fallback capability can be enabled using the swc_connection_set_fallback_cfg API call. The CCA try count can be set using the cca_try_count parameter. The fallback channel settings are recommended to be configured with swc_channel_list_init (or swc_channel_list_init_from_base) and applied using swc_connection_set_fallback_channels. This allows the system to tradeoff throughput for increased range or robustness in suboptimal environmental conditions. See Configure Fallback for more details.
This feature allows the user to limit the predefined throughput of the schedule by disabling a portion of its timeslots. The Wireless Core achieves this by making the transceiver sleep over the normally active transmission periods of the schedule. In other words, the Wireless Core can disable timeslots on-the-fly. This allows the transceiver to sleep for longer periods of time while freeing up MCU resources. MCU power saving methods can also be applied during that time (e.g., lowering MCU core clock or using MCU sleep modes).
Link throttling can be enabled on a per connection basis via the Wireless Core API. Link throttling is implemented by specifying an active timeslot ratio (%) used for transmissions.
For example, let’s assume a bidirectional link containing 3 connections:
Connection #1: Device #1 -> Device #2
Connection #2: Device #2 -> Device #1
Connection #3: Device #1 -> Device #2
By defining a 20% active timeslot ratio on Connection #1 of the Device #1, only 1 timeslot out of 5 will be used and the rest will be disabled. Link throttling only affects the timeslots linked to the connection where it is applied. Other connections will remain unchanged. In this example Connection #2 and Connection #3 will remain with a 100% active timeslot ratio. In summary, the Device #1 will:
Be able to transmit in only 1 timeslot out of 5 over the Connection #1 (and sleep for the remaining 4).
Always wake up and listen for a packet on timeslots assigned to Connection #2. (Unaffected by link throttling on Connection #1)
Transmit in every timeslot assigned to Connection #3. (Unaffected by link throttling on Connection #1)
Link throttling will have an impact on the Wireless Core latency since it reduces the transmission opportunities in a defined period of time. Consideration to latency requirements should be made before using this feature. See Wireless Latency for the quantitative impact of throttling on the inter-opportunity gap.
Also, since the maximum sleep duration possible using idle sleep is 3.19 ms, the throttling should not be set to a ratio where the transceiver does not wake up within this maximum sleep duration. The link throttling feature evenly distributes the active timeslot based on the configured ratio to help with this limitation, but it can sometimes not be enough when using a low active timeslots ratio combined with long timeslot durations.
Another limitation of this feature is that a given connection can only be throttled on one device. For example, if Device #1 throttles Connection #1 to 20%, Device #2 will have to keep the active ratio at 100% for Connection #1. This limitation is due to the fact that the Wireless Core does not have a way to know if the peer device is throttling the connection or not. If both devices throttle the same connection, the Wireless Core will not be able to transmit in that connection.
If throttling is enabled on an RX connection, in guaranteed delivery mode, the transmitter will have to adjust the application datarate to match the throttling ratio. If the transmitter does not adjust its datarate, the RX queue will overflow and the Wireless Core will drop frames. There is no automatic mechanism to adjust the datarate on the transmitter side. The application must implement a mechanism to send RX throttling information to the transmitter and adjust the datarate accordingly.
See also
For the per-slot latency impact of throttling and the effective gap formula, see the Throttling section in the latency documentation.
During normal operation, the Wireless Core will be able to send a frame in any of the timeslots. However, when an active timeslot ratio lower than 100% is configured, some timeslots will be disabled. For example, when setting the active timeslots ratio to 90%, the Wireless Core has 10% less transmission opportunities:
Figure 73: Link Throttling Example - 90% Active Ratio
Applying the same principle, throttling the connection even more by setting the active timeslot ratio to 50%, the Wireless Core throughput for that connection is effectively halved:
Figure 74: Link Throttling Example - 50% Active Ratio
In short, a connection normally allowing transmission of 1000 packets per second configured with an active timeslot ratio of 50% will see its packet rate reduced to 500 packets per second. In that case, if the application is generating packets at a rate higher than 500 per second, the Wireless Core will be forced to drop excess packets, causing data loss. One must consider the application packet rate before enabling the throttling feature and selecting an active timeslot ratio. Please refer to the Retransmission Margin section for more details on the relationship between application packet rate and the Wireless Core’s schedule packet rate.
The Wireless Core allows the user to set a priority for each defined connection. This priority is used by the Wireless Core to determine which connection should be scheduled first when multiple connections are assigned to the same timeslot.
The priority is set by the user when the connection is created, while the connection’s ID is defined by the order in which the connections are initialized. The ID is used by the receiver to decode the incoming frame and determine which connection it belongs to. Both devices need to initialize the connections in the same order to ensure that the connection ID matches on both sides. The priority of a connection is independent of its ID, so a connection with a higher ID can have a higher priority than a connection with a lower ID.
See also
For the latency impact of priority contention (blocking rate, extended gap, expected extra wait) and a timeline diagram of how a high-priority connection steals slots from a lower-priority one, see the Priority Blocking section in the latency documentation.
For using priority to share timeslots between connections when designing a schedule (with an audio + data example), see Connection Priority and Timeslot Sharing.
When preparing to receive a frame on a timeslot with multiple connections, the receiver is not aware of which connection the incoming frame will belong to. Therefore, the radio will be configured with the parameters of the first connection added to that timeslot. If the reception is successful, the Wireless Core will check which connection the received frame belongs to and update it accordingly.
This means that all connections must have compatible parameters. Specifically:
All local addresses should match (TX source address and RX destination address).
All connections should have the same acknowledgement settings (acknowledgement enabled or disabled, stop and wait).
All connections should have the same MAC header features enabled.
Connection priority
Credit-based flow control
RDO
etc.
All connections should have the same Fragmentation settings.
All connections should have the same frame configuration (modulation, FEC).
For some parameters, the wireless core will automatically use the biggest value among the connections linked to the same timeslot. This is the case for the maximum payload size and the CCA retry parameters.
If auto-reply connections are used, only one remote device can be linked to a timeslot. Otherwise, any connection can be linked to any device on the network.
Here are some use cases:
Audio streaming with periodic data payload.
In this use case, an audio streaming application uses about 75% of the transmission timeslots which gives it 25% of re-transmission margin. This connection transmits time sensitive payloads, so it should be the highest priority. The data connection can then be set to a lower priority and would only be transmitted on timeslots not used by the audio connection.
If the link quality degrades, the audio connection will use a bigger percentage of the transmission timeslots. This could limit the ability of the data connection to transmit its payload.
This use case allows the audio connection to stop transmitting its payload if nothing needs to be transmitted (audio paused) since the data connection would keep the sync between the Coordinator and the Node. When the audio connection is idle, the data connection becomes the only synchronization source, so its period must not exceed 10 ms (see Sync Timeslot (Beacon)): at 10 ms the node tolerates the loss of one data frame, and shorter periods add tolerance.
Star Network with a periodic beacon.
In this use case, a Coordinator transmits data to one node and receives data from other nodes. To maintain the synchronization of all the nodes in the network, a beacon must be sent periodically to all the nodes, respecting the beacon margin rule (see Sync Timeslot (Beacon)). The beacon can be added to one of the dongle’s transmission timeslots as the highest priority to guarantee its transmission.
Multiple low frame rate connections.
In this use case, multiple low frame rate connections can share one timeslot. For example, three connections generating 500 packets per second could share one 2000 frames per second timeslot.
Auto-sync is a per-connection feature of the Coordinator’s TX connections. When enabled, the Wireless Core automatically transmits a header-only sync frame whenever the connection’s transmission queue is empty at the start of one of its transmission timeslots, instead of keeping the transceiver asleep. This guarantees a minimum transmission rate from the Coordinator on that connection, so the Nodes always receive synchronization frames within the beacon interval limit (see Sync Timeslot (Beacon)) even when the application has no data to send.
The intended use is a dedicated low rate beacon connection: a connection whose application traffic is sparse or absent, but whose timeslots must still provide the network synchronization reference. Such a connection can have a FIFO size of 0 and rely entirely on auto-sync to generate its frames.
Warning
Auto-sync trades power and spectrum usage for synchronization robustness. Every otherwise-idle timeslot of the connection becomes a transmission: the transceiver wakes and transmits instead of sleeping, increasing the Coordinator’s power consumption, and the sync frames occupy air time on every idle timeslot, increasing the over-the-air channel occupancy seen by concurrent networks (more CCA failures for neighbors). Do not enable auto-sync on high-timeslot-count connections as a substitute for a properly paced beacon; enable it on a connection whose timeslot allocation matches the desired beacon rate.
The Wireless Core provides an optional optimization to reduce the latency of a specific
connection by delaying the transceiver’s wake-up when there is no data available for
transmission.
See Optimized Latency Feature for a detailed description of the mechanism, constraints,
and impact on latency.
See also
For the full mechanism (with diagram), schedule constraints, and compatibility
restrictions, see Optimized Latency Feature in the wireless latency documentation.
There are three types of frames that can be generated by the Wireless Core which are data frames, sync frames and acknowledgement frames. It’s important to note that a few bytes of the PHY payload will be utilized for the MAC layer. The exact number of bytes depends on the configured header for the specific connection.
Sync frames are used when auto-sync mode is enabled on a connection. When the queue of a connection is empty, a frame containing only a header will be sent to keep the network synchronized.
The Wireless Core packet header is composed of a variable amount of fields which are determined at connection creation, and depends on the enabled features. Fields are sub-byte packed (bit-level) and some have dynamic sizes that depend on the configuration. Here is the list of possible fields:
Note
The header format changed in SDK 2.3. Prior versions used fixed-size fields (e.g. 7-bit Timeslot ID, 1-bit Stop and Wait, 8-bit Channel Index) and included a dedicated Header Size field. Applications built with SDK versions earlier than 2.3 are not over-the-air compatible with 2.3+ unless legacy mode is used. Starting with SDK 2.4, a legacy header mode is available to maintain over-the-air compatibility with devices running SDK versions prior to 2.3.
The SPARK Wireless Core provides users with the capability to activate certification mode. In this mode, the device utilizes application-defined settings to transmit at maximum power during all designated timeslot using the maximum payload size defined for each connections. Additionally, certification mode emulates the transmission of auto-reply payloads, if applicable to reflect a normal utilization of the rf channel even without being paired to any other devices.
If Connection Priority is used, the wireless core initialization must be modified to be able to certify low priority connections. The certification mode will enqueue packets on the first connection assigned to a timeslot. To certify a connection, it must thus be assigned first to a timeslot and its priority must be the highest.
The transceiver implements multiple layers of data protection in a frame to ensure proper transmission. These mechanisms are handled automatically by the Wireless Core.
Only frames with destination address matching the local address are passed on to the Wireless Core. Frames with a non-matching address are discarded by the transceiver.
