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).
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.
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.
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. 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.
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 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).
Furthermore, the delay is only applied if successful transmissions are achieved. When no successful transmissions are achieved for a certain amount of time, an offset of 1024 PLL cycles (~50 us at 20.48 MHz) is applied to help find a free slot in the air time allocation.
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.
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.
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.
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 type of service is commonly used for non-real time data transfers (e.g. file transfers or firmware updates)
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 3 bytes to the header of the first fragment and 2 bytes to the header of subsequent fragments.
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 power settings can be set with the swc_connection_add_fallback_channel API call. 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.
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.
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 53: 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 54: 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.
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 data payload every 10 ms.
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.
Star Network with a beacon every 10 ms.
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. 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.
The Wireless Core provides users with the option to activate an optimization aimed at reducing the overall latency of a specific connection. When enabled, this feature delays the transceiver’s wake-up when there is no data available for transmission, providing more time for the application context to generate a frame. This additional time reduces the minimum latency possible by shortening the duration it takes for the Wireless Core to begin processing the frame.
The delay is determined by the connection configuration parameters such as payload size, acknowledge payload size, modulation, FEC, and CCA parameters (CCA try count and CCA retry time).
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. Here is the list of possible fields:
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.
