Wireless Core¶

Introduction¶

The Wireless Core is implemented as a custom network stack. Its purpose is to facilitate transceiver setup, making it possible to optimize performance for data rate, latency and power consumption.

The Wireless Core manages wireless functionalities within the SDK. It has a top-level API (the Wireless Core API) and two main sub-components: the Wireless Protocol Stack (WPS) and the SR1000 Series Driver. Both sub-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 WPS API and the SR API. It aims to provide a simple, coherent entry point to the SDK wireless functionalities. Many of the transceiver complexities are abstracted using this API. Initialization code blocks have been grouped together in an organized fashion.

The lower level APIs can still be called by applications that require finer control of complex features. The Wireless Core API will continue to grow with time, hopefully minimizing the amount of lower level occurrences.

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 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 devices on a SPARK network: a Coordinator Node and a Node. There can only be one Coordinator per network. The role of the Coordinator Node is to serve as the time base. Every other Node in the network will synchronize to it.

Time Division Multiple Access¶

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.

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 must be known by all the Nodes on the network and cannot change at runtime. The schedule specifies when and for how long a given Node is allowed to transmit or receive a frame. Only one pair of Nodes is allowed to exchange 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¶

To optimize UWB spectrum usage and avoid violating the regulatory emission limits, frequency switching can be implemented.

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

The WPS can be configured to use a different frequency in consecutive timeslots. This is implemented in 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 frequency switching sequence. For every timeslot, the WPS will tune the radio to the next channel in the list. As a result, the list is cycled independent of the connections as shown in the illustration below.

Figure not found: Frequency switching sequence example

Figure 9: Frequency switching sequence example¶

Connection¶

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 a schedule.

The number of connections per timeslot will depend on the timeslot type. There are three types of timeslots.

Timeslot Types¶

NACK: These timeslots are unidirectional. Therefore, the number of connections for this type of timeslot is one. Since there is no acknowledgement, there is no guarantee that this type of frame has been successfully transmitted. Nack timeslots occur when a timeslot is used by a connection with acknowledgement disabled.

Figure 10: NACK frame¶
ACK: These timeslots are bidirectional. Therefore, the number of connections for this type of timeslot is two. After the transmission of the main frame, a second frame (Acknowledge Frame) with no payload is automatically transmitted by the receiver. ACK timeslots occur when a timeslot is used by a connection with acknowledgements enabled.

Figure 11: ACK frame¶
Auto-reply: These timeslots are bidirectional. Therefore, the number of connections for this type of timeslot is two. After the transmission of the Main Frame, a second frame (Auto-reply Frame) with a payload is automatically transmitted by the receiver. The reception of the Auto-reply Frame indicates that the Main Frame has been received. Note that it is not possible to acknowledge the Auto-reply Frame.

Figure 12: Auto-reply frame¶

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 with one connection using a broadcast address as the destination address. If the destination address is 0xFFFF, the transmitting device communicates with every device 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 or 0xCDFF.

Figure not found: Connections and Broadcast

Figure 13: 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 a transmitting device at source address 0xCD02 and a receiving device at destination address 0xAAAA. The second connection shows a data transfer between a transmitting device at source address 0xCD01 and a 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 a 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 Methods¶

Standard Sync: Upon power up, the Node will listen for a message from the Coordinator. If none is received, it will go to sleep for a given amount of time and then try again later. This method will save power when the Coordinator is not powered on yet, it is power efficient and will usually allow the devices pair to achieve synchronization in a short period of time when the frame rate on the Coordinator is high.
Fast Sync: Upon power up, the Node will continuously listen (active RX state) for a message from the Coordinator. This synchronization method is less power efficient, but it will be faster because the Node should immediately start to receive frames from the Coordinator when both devices become active. This method should be used when the frame rate on the Coordinator is low.

Dual Radio¶

In applications where antenna placement is challenging, the WPS can support the implementation of two transceivers in one system. In this mode, the two transceivers are redundant in reception events. The transceiver that receives the payload with the strongest RSSI signal will be kept and the one with the weakest RSSI signal will be discarded. This approach will significantly improve the packet delivery ratio at the expense of reduced throughput. The CPU load is expected to be approximately 1.5 times greater than single radio (application specific).

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 20.48 MHz provided by the MCU is also needed. The timer period must be configurable by the WPS.

Topology¶

In every 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 keep a proper synchronization on the network. Note that the topology of the network is entirely defined by the user configuration.

Note

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 14: 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 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.

Figure 15: 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 not found: Cluster Tree Network Topology

Figure 16: 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 defines the length of each timeslot in microseconds. Timeslot duration is determined based on air time of the frame sent over the air and interframe spacing required for the CPU to fetch/retrieve and process data for each frame. The interframe spacing can be different with different MCU devices and will mostly depend the MCU general performance characteristics and the configured SPI speed.

Figure 17: Interframe spacing¶

The figure above shows an example of a star network schedule. The diagram shows air time (colored) and processing time. 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).

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 18: Channel Sequence¶

The table below offers another perspective of the channel configuration shown above.

Table 1: Channel Configuration¶
~	Schedule index 0	Schedule index 1	Schedule index 2
Channel 0	6.72 GHz	7.29 GHz	7.29 GHz
Channel 1	7.00 GHz	7.00 GHz	7.58 GHz
Channel 2	7.29 GHz	6.72 GHz	6.72 GHz
Channel 3	7.58 GHz	7.00 GHz	7.00 GHz

Node Configuration¶

Role: The role is set to either Coordinator or Node.
Local Address: Each Node is assigned a 16-bit address. This address must be unique on a given network. During an active timeslot, a Node in receive mode will ignore all messages that are not destined to the Node’s Local Address.
Syncing Address: This field specifies the address of a device which will provide synchronization information. On a star or peer-to-peer network, this is the address of the Coordinator.
Concurrency: Concurrent networks are configured by enabling concurrency and selecting a network mask size which defines the address space for the network. Each network is expected to contain a Coordinator and one or more Nodes. Each network must use a different sync word. When enabling concurrency, the Clear Channel Assessment feature (CCA) also needs to be enabled.
Sleep Modes: There are three different sleep modes that are supported: idle, shallow and deep. The selected sleep mode will change the behavior of the radio between active phases. This setting is shared by all connections of a Node.

Note

Please refer to the device datasheet for more information about sleep modes.

Connection Settings¶

A connection is established for the purpose of transferring frames. A device can be a transmitter or a receiver during a connection. The same connection can occur in one or many timeslots in a schedule. Each connection has a predetermined set of configurations.

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.
Connection Configuration: The configuration of a connection must be the same for all the Nodes that use it. Connection configurations are defined by modulation type, FEC level, buffer and payload sizes, callback methods, and flow control mechanisms.

Modulation¶

Two modulation schemes are available, Inverted On-Off Keying (IOOK) and 2-bit Pulse Position Modulation (2-bit PPM). Each of these modulation schemes has their merits. 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.

figure not found: Modulation bit sequence

Figure 19: Modulation bit sequence¶

Forward Error Correction (FEC) Level¶

The goal of the FEC is to correct errors which might occur during over-the-air transmissions. FEC adds redundant bits to a bitstream and thus increases the frame size.

The SPARK radio can support 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¶

Frames are buffered in a First-In First-Out (FIFO) Memory. The FIFO size for each connection can be configured. A bigger queue allows you to transmit in burst on the TX side and pull data less frequently on the RX side.

Maximum Payload Size¶

The maximum payload size defines the largest payload that can be transmitted on the connection.

Callbacks¶

Each connection can have unique callbacks to notify of a frame received activity. Events such as received packet, completed frame transmission, frame drops or stack errors can all be configured to have callbacks.

See Callback Documentation for more information.

Acknowledgement¶

Frame acknowledgement can be enabled or disabled on a connection. When enabled, a device will automatically transmit an auto-reply frame upon successful reception of a frame. If the Stop and Wait setting is disabled, a frame that has not been acknowledged will raise a frame dropped callback.

Stop and Wait¶

The Stop and Wait control mechanism handles frame retransmissions automatically when a frame is not acknowledged. The acknowledgement on the connection must be enabled to use this setting. 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 drop a frame. The second mode will drop a frame if it is not delivered after a certain amount of time. The timeout for the second mode is set in increments of 250 microseconds.

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 transfer of firmware updates)

Auto Sync¶

Auto sync mode is used to maintain synchronization between a Coordinator and a Node. When this mode is enabled, a frame containing only a header will be sent when there is no payload data available for transmission. This empty frame will serve to keep the network synchronized in cases where the Coordinator is not sending any application data for a certain period of time.

CCA¶

Clear Channel Assessment (CCA) is a mechanism used to determine if the air space is currently free or in use. This mechanism is 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 that the channel is busy. If the time allowed for the connection expires, and the CCA didn’t succeed, the transmission can be postponed to the next connection’s timeslot or it can be transmitted anyways, depending on the configuration.

Active Timeslots¶

This setting associates connections with timeslots in a schedule. The connection can be setup to use main timeslot or auto-reply timeslot. Note that acknowledgements can not be enabled in connections that uses auto-reply timeslots. A connection with more active timeslots can reach higher data rates.

Figure 20: Active timeslots¶

Connection Throttle¶

Connection throttle allows a user to lower 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 configuration. This configuration can be different for each channel in the channel sequence.

Channel Configuration¶

A channel configuration contains a frequency code and some pulse power settings.

The center frequency for a given code is calculated as follows:

\(Freq = Code \times 40.96\)

Figure 21: Frequency code VS frequency¶

The example above illustrates a frequency table with 5 channels.

The SPARK transceiver output power is defined by 3 pulse settings:

The number of pulses in each symbol
The duration of each pulse
The amplitude of each pulse

These 3 settings form the “symbol pattern”. Each connection can have a unique symbol pattern. The user must set the symbol pattern such that the output power remains within the targeted limits (Regulatory Mask) as set by UWB regulations bodies. The WPS does not automatically sense and adjust transmitted power.

The channel must be configured for each connection in the channel sequence.

Data Transfer¶

This section gives an overview of the WPS functionality and describes how frames are transmitted.

Queue¶

Each frame sent with the WPS passes through two queues (FIFOs). The first queue is in the transmitting device (TX FIFO) and the second queue is in the receiving device (RX FIFO). If frames are enqueued too quickly in the TX FIFO and the FIFO becomes full, the wps_send() function will return an error and the new frame will not be enqueued. If the RX FIFO cannot be emptied quickly enough by the application, the WPS will raise an error callback with an overrun flag. Queue size is unique for each connection and must be configured during initialization.

Send Frame¶

An application must first get an empty buffer before a frame can be sent by the WPS. The user can either use a custom buffer or he can automatically get one by calling the wps_get_free_slot() function. Once this buffer is filled by the application, the wps_send() function is called to transfer the frame from the application buffer into the TX FIFO for transmission over-the-air on the next active timeslot. There are two possible outcomes for the transmission; either the payload has been transmitted and acknowledged (successful transmission) and a TX ACK callback is raised, or the frame was not acknowledged (unsuccessful transmission) 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. The frame buffer must not be modified after calling the wps_send() function. The user must wait for the callback to trigger before modifying the frame buffer, otherwise data corruption will occur.

Receive Frame¶

An RX callback is raised each time a new frame is received. The wps_read() function must be called to read the new frame. Once the frame has been consumed by the application, the wps_read_done() function 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 frames that can be generated by the WPS.

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

Figure 22: Data frame¶
Sync frames
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.

Figure 23: Sync frame¶
Acknowledgement frames
Acknowledgement frames can only be sent in an auto-reply. This type of frame does not contain a payload.

Figure 24: Acknowledged frame¶

Data Validation¶

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

CRC: A frame with a failing cyclical redundancy check (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.
Syncword match: Frames with the wrong syncword are automatically discarded.
Max frame size: Each connection has a maximum frame size, if a larger frame is received, it will automatically be discarded to avoid buffer overflows.

Statistics Module¶

The WPS API provides communication performance statistics shown below.

Basic:

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¶

The WPS requires selection of an MCU that supports the following:

DMA SPI full duplex transfers,
SPI blocking read and write
1 GPIO interrupt input
3 GPIO outputs

For the complete list of Board Support Package (BSP) requirements, please refer to the 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 depending on the selected 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 performance of the wireless link.

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

Figure 25: WPS timing diagram¶

Function Process Hook¶

The WPS is entirely event driven. The user must 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 is 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 has completed. 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. A second type of error is a PHY error. It happens when 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 26: 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, \(Ps\) 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)¶

In some applications, a Sync Timeslot or Beacon will be necessary. This is the case when an application does not transmit payloads at least every 10 ms to the child node. This type of 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¶

SR1000 Driver Module¶

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

Figure 27: 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¶

Wireless Core Changelog¶

v0.5.0 - 2022-03-03¶

Changed

Set auto-sync to disabled by default in the Wireless Core API.

Fixed

Most recently manufactured transceivers were not handled properly causing a wrong Wireless Core behavior.
Transceiver’s FIFO corruption when IRQ handling was too much delayed.

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.