Wireless Core

Introduction

The Wireless Core uses a custom network stack built to take the most advantage of the unique capabilities of the SPARK transceivers. It makes it possible to fully optimize the settings of the transceiver to maximize data rate, minimize latency and minimize power consumption.

The Wireless Core manages wireless functionalities within the SDK. It has a top-level API (the Wireless Core API) and two main components: the Wireless Protocol Stack (WPS) and the SR1000 Series Driver. Both of these components provide their own API as well. The following block diagram shows the general system architecture.

Figure 7: General system architecture block diagram.

Wireless Core API

The Wireless Core API is the Wireless Core top-level Application Programming Interface. It sits on top of the two other lower level APIs, the WPS API and the SR API. It aims to provide a simpler, more coherent entry point to the SDK wireless functionalities. This API tries to hide as much complexity as possible to offer a more straight forward way to use and configure all elements of the Wireless Core. Many rarely changed configuration values have been set to default values and blocks of initialization code have been grouped together in a more organized way.

This API is at its debut and will evolve throughout SDK releases. The lower level APIs can still be called by applications while features are being added to the Wireless Core API, but the ultimate goal is that the vast majority of applications won’t need those anymore.

sdk_spark_vx.y.z/
└──core/
   └── wireless/
       └── api/
           ├── wireless_api.h
           └── wireless_error.h

File or folder	Description
wireless_api.h	The API itself. This header file must be included in the user’s application in order to use the API.
wireless_error.h	Wireless Core error codes.

References:

• wireless_api.h
• wireless_error.h

Wireless Protocol Stack

Introduction

This section aims at introducing the user to the SPARK Wireless Protocol Stack.

Note

The Wireless Protocol Stack will be referred to as WPS for the rest of this document. In addition, the word “transceiver” refers to the SR1010 or the SR1020 integrated circuit.

Overview

Network Components

There are two types of device on a SPARK network: Coordinator node and Node. There is only one coordinator per network. The role of the coordinator is to serve as the time base. Every node in the network will synchronize on it.

Time Division Multiple Access

The wireless core always operate in Time Division Multiple Access (TDMA) access mode. It divides time into multiple slices called timeslots. Each timeslot is a portion of time that can be reserved for a specific event. The sum of all the timeslots is called a schedule. To minimize power consumption, the WPS always operates using TDMA. Most of the time, the radio is asleep. It will wake up only to transmit a frame or when it expects to receive a frame on a dedicated timeslot.

Schedule

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 has to be known by all the nodes of the network and cannot change at runtime. It will determine when and for how long a given node is allowed to transmit or receive a frame. Only one pair of nodes is allowed to transmit data in a timeslot. When the schedule reaches the last timeslot, it loops back to the first one.

Figure 8: Basic schedule

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.

Frequency Switching

In order to optimize UWB bandwidth usage, and to avoid breaking the regulatory emission limit, frequency switching is used.

The strategy consists of spreading the energy over a wider spectrum by cycling through the available frequencies at each timeslot.

The WPS offers the possibility to change frequency for every timeslot. To do so, the user must configure the WPS with a list of channels to be used. The order in which the channels are entered in this list will result in the switching sequence. For every timeslot, the WPS will tune the radio to the next channel in the list. As a result, that list is cycled through independently of the connections as shown in the illustration below.

Figure 9: Frequency switching sequence example

Connection

A connection is defined by a unidirectional link between a source address and a destination address (An address can target multiple devices with broadcast or multicast). One device can use one or multiple connections.

For a device to send data, a connection must be associated with one or more timeslots inside the schedule. The data is sent or received during the connection’s active timeslots.

There are 2 types of timeslot a connection can use: - Main timeslot: will use the main portion of the timeslot to transfer data. - Auto reply timeslot: will use the auto reply portion of a timeslot to transfer data.

See Timeslot Types for more information.

A connection between two devices will 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 with one connection using a broadcast address as the destination address. If the destination address is 0xFFFF, the transmitting device communicates with every devices within reach. It is also possible to broadcast to a subnetwork by using 0x**FF as the destination address. For example, devices using an address within the range 0xCD00 to 0xCDFE are reachable with the broadcast address 0xFFFF (to all devices) or 0xCDFF (to devices in the 0xCD00 network only).

Figure 10: Connections and broadcast

The figure above shows three unique connections in the three timeslots forming the schedule. The first connection shows a data transfer between transmitting device at source address 0xCD02 and receiving device at destination address 0xAAAA. The second connection shows a data transfer between transmitting device at source address 0xCD01 and receiving device at destination address 0xAAAA. It can be observed that it is the same device (0xAAAA) that receives data from both transmitters. The third connection shows a data transfer between transmitting device at source address 0xAAAA and two receiving devices at destination address 0xCD01 and 0xCD02. This is because the broadcast subnetwork specified by 0xCDFF was used as the destination address. This broadcast mechanism can be used for basic communication or to create a beacon connection. A beacon is simply a regular frame carrying no data used only for synchronization purposes.

Synchronization Method

Standard Sync With standard sync, nodes will power cycle the radio during the synchronization phase until a frame is received from the coordinator. This synchronization method is the most power efficient and will yield short synchronization delays as long as the frame rate coming from the coordinator is high enough.

Fast Sync When fast synchronization is enabled, the transceiver of a node will continuously listen (active RX state) until a frame from the coordinator is received. This synchronization method is less power efficient, but it will greatly reduce the synchronization delay when the frame rate coming from the coordinator is low.

Dual Radio

In order to obtain a better signal in applications where the antenna placement is challenging, the WPS supports the usage of two transceivers on one system. In this mode, the two transceivers are redundant in reception events. The transceiver that receives the payload with a stronger RSSI signal will be used for any transmissions, if applicable. The payload received by the transceiver with the weakest reception signal will be discarded while the one from the strongest receiving one retained. The drawback to this feature is that your maximum throughput will be reduced, and CPU load will multiply by 1.5. (This is an approximation, The exact number will vary depending on your specific configuration.)

The second transceiver will use a dedicated SPI bus and DMA channel, independent of first one, to allow for simultaneous data transfers. A 16-bit timer running at 20.48 MHz provided by the MCU is also needed. The timer period has to be configurable by the WPS.

Topology

In every topology, the link between two nodes can be either unidirectional or bidirectional. In order to keep a proper synchronization on the network, a given node should always receive frames from its syncing node at least every 10 ms. Note that the topology of the network is entirely defined by the user configuration. Routing is not currently supported by the WPS and must be handled by the application.

Star Network Topology In a star network, all communications are established directly between a central node configured as coordinator and several other nodes.

Figure 11: Star network Topology

Peer to Peer Network Topology In a peer-to-peer network, each node can communicate with any other node, but the coordinator must send a frame to every node at least every 10 ms to keep synchronization. In most case, this frame will be sent in the form of a broadcast.

Figure 12: P2P Network Topology

Cluster Tree Network Topology In a cluster tree network, nodes can sync on a child node of the coordinator instead of 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.

Figure 13: Cluster Tree Network Topology

Configuration

This section describes settings that can be configured by the user through the Wireless Protocol Stack API or the Wireless API.

Network Configuration

Schedule The schedule configuration determines the length of each timeslot in microseconds. To determine the right timeslot length, the air time of the frame sent on this timeslot and the interframe spacing required for the CPU to process the frame must be taken into account. The interframe spacing will be different for each MCU and will mostly depend on its general performance and the configured SPI speed.

Figure 14: Interframe spacing

This example of a star network shows that even if the time between two over-the-air frame transfers is very short, each node always have a rest period between two active timeslots.

Channel Sequence The channel sequence determines the sequence of the frequency switching in the network. The channel sequence is defined as an array of channel index. Each connection defines their own set of configuration for a given index. Every node in the network needs to share the same channel sequence.

The example below show how the channel sequence impacts the channel configuration.

Figure 15: Channel Sequence

Example Channel Configuration
Channel Index	Connection 1	Connection 2	Connection 3
0	6.72 GHz	7.29 GHz	7.29 GHz
1	7 GHz	7.58 GHz	7.58 GHz
2	7.29 GHz	6.72 GHz	6.72 GHz
3	7.58 GHz	7 GHz	7 GHz

Node Configuration

Role Coordinator: There is only one coordinator in a SPARK network. This is the node used as time base to synchronize the time base for the TDMA scheme.

Node: All other devices in the network should be configured as nodes. Nodes adjust their clock to the coordinator to stay synchronized to the network.

Local Address Each node has an address of 16 bits. This address should be unique to all the nodes in a given network. On an active timeslot, a node in RX mode will filter out all messages with the wrong destination address.

Syncing Address The syncing address is the address of the device on which the node will synchronize itself. On a star or peer-to-peer network, this is the address of the coordinator.

Concurrency Concurrent networks can be configured by enabling concurrency and selecting a network mask size which defines the address space for that network. Each network is expected to contain a coordinator and one or more nodes within its addressing space. Each network uses a different sync word. When enabling concurrency, the Clear Channel Assessment feature (CCA) also needs to be enabled.

Sleep Modes There are three different supported sleep modes: idle, shallow and deep. The selected sleep mode changes the behavior of the radio between active phases. This setting is shared by all connections of a node.

• Idle Sleep Mode: The receiver and transmitter are turned off.

• Shallow Sleep Mode: The 1V power domain is turned off. The bias and PLL domains are still powered on.

• Deep Sleep Mode: All domains are powered off except the 32 kHz crystal oscillator and associated internal timer. Depending on the packet rate, the radio can transition in either deep sleep, shallow sleep or idle sleep in between frames. The figure below illustrates the state transitions in these three modes.

Figure 16: Sleep mode timing

The three sleep modes offer different trade-offs between power consumption, startup energy, and startup time. At a packet rate below 250 Hz, deep sleep offers a low sleep current at the cost of a higher energy consumption when the radio wakes up. At a packet rate of 250 Hz up to 1 kHz, shallow sleep offers medium sleep power at a low startup cost. At packet rates above 1 kHz, the startup time from shallow sleep can become disadvantageous, and idle sleep can be used.

Figure 17: Power consumption VS data rate for different sleep modes

Example of power consumption at 1.8V supply with 64-byte frames using FEC 1.

Connection Settings

A connection can use one or many timeslots in the schedule to transfer or receive frames. Each connection has its own set of configurations.

Connection Configuration The configuration of a given connection should be the same for all the nodes that uses it. The behavior of the device for a given connection will change depending on the relation of its local address with the source and destination address of the connection.

Source Address This is the local address of the node that transmits the frames on the connection.

Destination Address This is the local address of the node that receives the frames on the connection. To set up the connection as broadcast, the destination address has to be set to 0xFFFF for a global broadcast or 0x**FF for a local broadcast, where ** is the subnetwork part of the 16-bit address.

Modulation

Modulation determines which one of the two available digital modulations is used by the modem. It translates the entire stream of bits contained in each frame into symbols during transmission, and the reverse operation is done at reception.

It will take half the time to transmit a frame in IOOK when compared to 2 bit PPM, but you can expect a better link budget when using 2 bit PPM.

• IOOK: Use IOOK modulation for high data rate applications.

• 2-bit PPM: Use 2-bit PPM to obtain higher link budget.

Figure 18: Modulation bit sequence

Forward Error Correction (FEC) Level

The goal of the FEC is to correct errors occurring during over-the-air transmissions. To do so, it adds redundant bits and thus increase the frame size.

The SPARK radio supports four levels of FEC. Each level is defined by its redundancy rate. The redundancy rate is the factor by which the frame size is increased. The FEC level 0 corresponds to disabling it, and as such, will not inflate the frame. At its maximum level of 3, the FEC will double the frame size.

FEC level	FEC rate
0	1
1	1.33
2	1.66
3	2

Buffer Size

The FIFO size for each connection can be configured. A bigger queue allows you to transmit in burst on the TX side and pull more data less frequently on the RX side.

Maximum Payload Size

The maximum payload size represents the size of the biggest payload you want to transmit on the connection. Each element of the FIFO will have a buffer of the payload size plus the header size.

Callbacks

Each connection can have unique callbacks to notify of a frame received, a completed frame transmission, a frame dropped or a stack error to the user.

See Callback Documentation for more information.

Acknowledgement

When acknowledgements are enabled on a connection, it means that every frame is acknowledged by transmitting an auto-reply frame. If the stop and wait setting is disabled, a frame not acknowledged will raise a frame dropped callback.

Stop and Wait

The stop and wait module handles retransmissions automatically in case a frame is not acknowledged. To use this setting, you must also enable the acknowledgement on the connection. There are two modes for the stop and wait : “Retry Count” and “Deadline”. The first one will count the number of retransmissions before dropping a frame. The second one will drop a frame if it was not delivered after a certain amount of time. The timeout for the second mode is set in increments of 250 microseconds.

For guaranteed delivery, both timeout settings have to be set to 0. That way, the stop and wait module will retransmit the frame indefinitely until the frame is acknowledged.

Auto Sync

When the auto sync mode is enabled, even if the queue of the connection is empty, a frame containing only a header will be sent. It is very useful to enable this setting on a coordinator TX connection to keep the network synchronized in case the coordinator is not sending application data for a certain period of time on which node usually synchronize on.

CCA

Clear Channel Assessment (CCA) is a mechanism integrated to the transceiver to determine if the air space is currently free or already used by another unexpected transmitter actively transmitting. It is typically used to avoid collisions that would result from having multiple transmitters transmitting at the same time.

Every connection can be configured to do the following:

• Allow the user to enable and disable the CCA feature.

• Allow the user to set the CCA threshold.

• Allow the user to set a period at which CCA retries will occur at the time of transmission.

• Allow the user to set the number of retries after which an action will be executed.

• Allow the user to set the action that will be executed if the last CCA fails (either abort or transmit anyway).

A transmission can be delayed within a timeslot if the CCA detects another device currently transmitting on the same band. If the time allowed for a connection expires, and the CCA didn’t succeed, the transmission will be postponed to the next connection’s timeslot or will be transmitted forcefully depending on the configuration.

Active Timeslots

This setting defines which of the timeslots in a schedule are used by a given connection. You can set the connection to use main timeslot or auto-reply timeslot. Note that you cannot use auto-reply timeslot on connections with acknowledgements enabled since auto-reply timeslots cannot be acknowledged. A connection with more active timeslots can reach higher data rates.

Figure 19: Active timeslots

Connection Throttle

Connection throttle allows to throttle down the frame rate of a connection at run time to save on power consumption. It is important to note that throttling the connection will not necessarily reduce the data rate. It will only lower the maximum available throughput of the connection.

Channel Settings

Each connection has a unique definition of configuration for each channel index of the channel sequence.

Channel Configuration

The frequency of a code is given as:

\(Freq = Code \times 40.96\)

Figure 20: Frequency code VS frequency

This diagram shows an example of frequency table with 5 channels.

The SPARK transceiver has three parameters that have an impact on the transmitting power:

• The number of pulses in each symbol

• The duration of each pulse

• The amplitude of each pulse

These 3 elements form what we will call the “symbol pattern”. Each connection can have their unique set of parameters for their symbol pattern. The user must set the symbol pattern parameters such as they are within the targeted limits (mask) as set by UWB regulations bodies. The WPS does not automatically sense and adjust the transmitted power.

These settings have to be configured per connection for each channel index.

Data Transfer

This section describes how to transmit frames wirelessly and gives an overview of internal functionality of the WPS.

Queue

Each frame sent with the WPS passes through two queues (FIFO). The first one is on the TX side and the second one is on the RX side. If frames are enqueued too quickly in the TX FIFO and it becomes full, the wps_send() function will return an error and will not enqueue the new frame. If the RX FIFO cannot be emptied quickly enough by the application, the WPS will raise an error callback with an overrun flag. There is a unique queue for each connection of a node and the size of the queue can be configured during initialization.

Send Frame

To send a frame using the WPS, the first step is to get a buffer to store the frame. The user can either use a custom buffer or automatically get one by calling wps_get_free_slot(). Once the buffer is filled by the application, the wps_send() function is called to enqueue the frame in the TX FIFO. There are two possible outcomes to the transmission. The payload has been transmitted and acknowledged and a TX ACK callback is raised, or the frame was not acknowledged and a TX NACK callback is raised. Note that if acknowledgements are not enabled on a given connection, the NACK callback means that the frame has been successfully sent. Make sure not to modify the frame buffer after calling the wps_send() function if the callback was not trigger yet to avoid risks of frame data corruption.

Receive Frame

Each new frame received notifies the user with a RX callback. The wps_read() function has to be called to read the new incoming frame. Once the frame has been consumed by the application, wps_read_done() must be called to free the element from the RX FIFO.

Data retention of the frame is not guaranteed once the wps_read_done() function is called. The payload must be fully consumed before calling this function to avoid data corruption.

Frame Structure

There are three types of frame that can be generated by the WPS.

• Data frames are the frames that contain the application payload. They can be either sent as main frames or in an auto-reply.

  

  Figure 21: Data frame

• Sync frames are used when the 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.

  

  Figure 22: Sync frame

• Acknowledgement frames can only be sent in an auto-reply. This type of frame only contains the PHY part of the header.

  

  Figure 23: Acknowledged frame

Data Validation

There are multiple layers of protection in a frame implemented by the radio to ensure proper transmission. These mechanisms are handled automatically by the WPS.

• CRC: A frame with a failing CRC is discarded and not acknowledged.

• Address filtering: Only frames with destination address matching the local address are passed on to the WPS. Frames with a non-matching addresses are discarded by the transceiver directly.

• Syncword match: Frame with the wrong syncword are automatically discarded by the transceiver.

• Max frame size: Each connection has a maximum frame size, which is the size allocated for each element of the queue. If a bigger frame is received by the transceiver, it will be automatically discarded to avoid buffer overflows.

Timeslot Types

• NACK timeslots are unidirectional. Since there is no acknowledgement, there is no guarantee that the frame has been successfully transmitted. Nack timeslots happens when a timeslot is used by a connection with acknowledgement disabled.

  

  Figure 24: NACK frame

• ACK timeslots are bidirectional. After the transmission of the main frame, a second frame with no payload is automatically transmitted by the receiver. ACK timeslots happens when a timeslot is used by a connection with acknowledgements enabled.

  

  Figure 25: ACK frame

• Auto-reply timeslots are bidirectional. After the transmission of the main frame, a second frame with a payload is automatically transmitted by the receiver. The reception of this frame by the original transmitter is used as an acknowledgement. Note that it is not possible to acknowledge the second frame. Auto-reply timeslots happens when a timeslot is used by two connections. One on the main frame and the second one on the auto-reply. The auto-reply frame is used by the main frame as an acknowledgement.

  

  Figure 26: Auto-reply frame

Statistics Module

The WPS API provides communication performance statistics.

Such as:

• Payload sent count

• Payload ACK count

• Payload dropped count

• Payload ACK ratio

• Payload received count

• Payload overrun count

• Empty count

• RX sync count

• TX link usage ratio

• RX link usage ratio

• TX data rate

• RX data rate

Phy Statistics / Link Statistics / Channel Statistics:

• RSSI Average

• RNSI Average

• Link Margin Average

• NACK frame count

• ACK frame count

• Received frame count

• Missing frame count

• Rejected frame count

• Duplicated frame count

• Retry frame count

• ACK frame ratio

• NACK frame ratio

• Received frame ratio

• Missing frame ratio

• Rejected frame ratio

• Packet Error Rate (PER)

• Missing/Rejected Ratio (MRR)

MCU Requirements

To use the WPS, your MCU must support DMA SPI full duplex transfers, SPI blocking read and write, 1 GPIO interrupt input and two GPIO output. For the complete list of BSP requirements, please refer to radio_hal_t structure documentation.

MCU Footprint

Memory The memory usage can vary a lot depending on your application. The memory usage will be mostly dictated by the size of the FIFO and the number of connections on the link.

CPU CPU usage will vary a lot depending on your MCU. The WPS is entirely driven by interrupts from the transceiver IRQ pin and from the SPI DMA. The interrupt handlers from these two interrupts will call the functions that process the WPS state machine. These interrupts should always be processed as fast as possible. Delaying the handling of these interrupts could greatly reduce the performances of the wireless link.

This diagram describes the processor usage and the interrupt model of the WPS.

Figure 27: WPS timing diagram

Function Process Hook

The WPS is entirely event driven. The user has to implement the functions that are called by these events. There are three events that can trigger the processing of the WPS. The first one is the interrupt of a GPIO event coming from the transceiver IRQ pin. The WPS can also trigger this interrupt by software internally for context switching purposes. The second one is the interrupt coming from the completion of an SPI transfer through the DMA module. The last one is the context switch triggered by the WPS to handle callbacks. It can either be handled in a low priority interrupt like a pendSV interrupt if the WPS is used in bare metal or in a high priority OS task if the application is using an RTOS.

Callback Process

• RX Callback: This callback is raised every time a new frame is received from the WPS. This is usually where the read function and the processing of the received frame will be executed.

• TX NACK Callback: This callback is raised every time a frame have been transmitted but not acknowledged. Depending on the configuration of the connection, it does not always mean that the transmission failed. If acknowledgements are disabled, this callback means that the transmission is done. If the stop and wait is enabled, this callback is only called when the frame does not meet the requirements to be sent and is dropped by the WPS.

• TX ACK Callback: This callback is raised every time a frame has been acknowledged. The frame is automatically dequeued from the FIFO.

• Error Callback: This callback is raised when an error occurred on the WPS. The most frequent error is an overrun of the RX FIFO. When this happens, the received frame is acknowledged by the transceiver, but the data is flushed since there is no free space to store it. The second one is a PHY error. It happens if the WPS detects an undefined behavior at the PHY level. This usually means that the board support package is not working as intended.

IRQ Callback

The WPS processing function should be called every time the transceiver IRQ pin is raised. This pin is used by the transceiver to notify the MCU of a new event. The processing of the event is handled automatically by the WPS.

DMA Callback

The WPS processing function should be called every time a DMA SPI transfer has been completed. This will indicate to the WPS that the DMA is free to initiate the next transfer.

Schedule Design Consideration

Bandwidth

When designing the schedule, the user must consider the bandwidth requirements for every device. The peak data rate of a specific connection is affected by the sum of allocated timeslots within the schedule. The schedule must be designed to consider applications with higher data rate requirements. The diagram below illustrates a scenario where a device with the address 0xCD01 has 3 times more link bandwidth than the device at the address 0xAAAA (assuming equally sized payloads and equal timeslot durations).

Figure 28: WPS data rate

The timeslot duration and the length of the schedule itself are other factors that come into play for the bandwidth. The user must configure the duration of every timeslot when configuring the schedule.

The maximum datarate in kbps of a connection is given as :

\(datarate = \frac{nTs\times Ps \times 8}{Sl \times 1000} kbps\)

where \(nTs\) is the number of timeslots allocated to the connection in the schedule, \(fs\) is the maximum payload size of the connection and \(Sl\) is the total schedule length

Retransmission Margin

The retransmission margin consists of normally unused timeslots that can be used for retransmissions when the link starts to degrade. By accounting for a retransmission margin in the wireless schedule, we are in fact designing a link which allows for a higher throughput than what the application requires. A higher retransmission margin will increase the robustness of the link. The concept of retransmission margin only applies when the connection is using the stop and wait feature.

The retransmission margin is given as:

\(margin = \frac {cD - aD}{cD}\)

where \(cD\) is the maximum data rate of the connection and \(aD\) is the data rate of the application for a given connection.

Sync Timeslot (Beacon)

It is important to implement a syncing connection if a given application does not require the syncing node to transmit payloads at least every 10 ms to the child node. This can use the auto-sync mode to let the WPS handle the transmission of the sync frame automatically. This connection can have a FIFO size of 0 if the user does not want to use this connection to transmit data. In a star or peer-to-peer network, this sync frame should be sent by the coordinator as a broadcast.

Wireless Protocol Stack API

The WPS API is the set of public functions the application can use to access the Wireless Protocol Stack functionalities.

sdk_spark_vx.y.z/
└──core/
   └── wireless/
       └── protocol_stack/
           ├── wps.h
           ├── wps_stats.h
           ├── wps_error.h
           └── wps_def.h

File or folder	Description
wps.h	The API itself. This header file must be included in the user’s application in order to use the API.
wps_stats.h	Wireless Protocol Stack statistics.
wps_error.h	Wireless Protocol Stack error codes.
wps_def.h	The API types definitions. Where the user can see all of the API structures.

References:

• wps.h
• wps_stats.h
• wps_error.h
• wps_def.h

SR1000 Driver Module

The SR1000 Driver Module contains low-level code to configure and use a SR1000 Series Transceiver.

Figure 29: MCU and SPARK ASIC

SPARK Radio API

The SPARK Radio API (SR API) is the set of functions a module can use to access the SR1000 Driver Module functionalities. It has been developed to be used by wireless protocol stacks like the SPARK WPS rather than applications directly as it exposes some cryptic transceiver’s internal mechanisms.

sdk_spark_vx.y.z/
└──core/
   └── wireless/
       └── transceiver/
           └── sr1000/
               ├── sr_api.h
               └── sr_api_hal.h

File or folder	Description
sr_api.h	The API itself. This header file must be included by the calling module in order to use the API.
sr_api_hal.h	Contains the SPARK radio hardware abstraction layer type structure.

References:

• sr_api.h
• sr_api_hal.h

Wireless Core Changelog

v0.4.0 - 2022-02-04

Added

• New Wireless Core API call wireless_core_get_allocated_bytes().

• New Wireless Core API call wireless_set_syncing_address().

• New Wireless Core API call wireless_free_memory().

• SR API which is a merge of the SR1000 API and SR1000 API advance.

• Syncword length can be adjusted through the syncword_len field of the wps_node_cfg_t type.

Changed

• Wireless Core processing time optimization.

• NVM instance is now in the wps_radio_t type.

• Calibration instance is now in the wps_radio_t type.

Removed

• SR1000 API and SR1000 API advance.

Fixed

• Doxygen comment header of wireless_connection_init().

v0.3.0 - 2021-12-16

Added

• Wireless Core API.

• Dual radio feature.

• Link throttling feature.

• Fast synchronization feature.

• An SPI timing setting which compensates for high capacitive loads on the SPI bus.

• Auto-reply with user payload capabilities

• Phase fetching , use for ranging. See stdspi in the wps_radio_t type.

Changed

• Rename wps_l1.c/h source files to wps_phy.c/h.

• Rename wps_l2.c/h source files to wps_mac.c/h.

• Split wps_phy.c/h source files in wps_phy_common.c/h, wps_phy_def.h, multi_radio/wps_phy.c/h and single_radio/wps_phy.c/h.

• Rename wps_set_coordinator_address() to wps_set_syncing_address().

• Add sr1000/ folders for SR1000 Series transceiver specific code.

• Add api/ folder for the Wireless Core API.

• Inline sr1000_access_adv functions (function definitions are now in the header file).

• Inline sr1000_api_adv functions (function definitions are now in the header file).

Removed

• sr1000_access_adv.c source file.

• sr1000_api_adv.c source file.

• wps_radio_calibrate() from the WPS API.

• wps_phy_init() from the WPS API.

• wps_modem_phy_init() from the WPS API.

• wps_modem_phy_t type from the WPS API.

Fixed

• Issue with shutdown mode that could cause the WPS to hang.

• Issue when using small payloads into an auto-reply frame.

v0.2.0 - 2021-11-09

Added

• Changelog.

v0.1.0 - 2021-09-30

Initial release.