Fragmentation

Description

This application example demonstrates the use of two features offered by SPARK Wireless Core: (SWC): fragmentation and auto-reply.

Fragmentation

The application generates a very large payload of pseudo-random data for transmission. The payload is split up into manageable chunk sizes that the radio can handle before sending over the air. The fragmentation feature is used for such a purpose. On the receiver side, the smaller chunks are merged to reconstruct the original payload. An onboard status LED is toggled every time a complete payload is successfully received.

Auto-Reply

This application example also demonstrates the ability of sending data via the auto-reply feature. Auto-reply is a feature that enables a transceiver to send a reply packet when a packet is successfully received. 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. The auto-reply packet is never acknowledged, so this communication method is considered a “best effort” delivery mechanism where occasional packets could be lost.

Real-time SWC link and application statistics are available through a terminal by connecting the Evaluation Kit (EVK) to a PC via USB. Live statistics allows the developers to monitor the behavior and performance of the application during runtime.

Note

In the context of this example application, the term “payload” refers to the full-size data that is being transmitted between the two devices. The term “chunks” refers to the smaller packets into which the payload is divided for transmission over the air.

By using this example application, the user can understand how to implement the fragmentation and auto-reply features of the SPARK Wireless Core in their own applications.

Application Data Flow

The application data flow is shown in the figure below.

Figure 23: Fragmentation Application Data Flow.

The application generates a random payload of 495 Bytes and appends it with a 4 Byte CRC and a 1 Byte sequence ID, resulting in an application payload size of 500 Bytes. This application payload is sent to the SWC using the API call swc_connection_send . The SWC then fragments the application payload into manageable “wireless payloads” or chunks, which are sent over-the-air (OTA).

On the receiver side, the SWC performs the defragmentation required to rebuild the application payload and returns it to the application. The CRC is then validated, and the statistics are updated accordingly. On-board status LEDs are toggled indicating successful transmission or reception. This data flow is identical in both directions for bi-directional configurations.

The API call swc_connection_send is invoked upon a TX success within the TX success callback.

Behavior

The application enables a synchronized link between two devices, where one device (the Coordinator) uses normal connections to send its payload and the other device (the Node) strictly uses auto-replies to send its payload.

Warning

Auto-reply does not guarantee delivery since it is never acknowledged. In this application, losing a packet during transmission in the auto-reply connection will result in an invalid transaction, and the transmitting device won’t receive any notification of the failed transaction. This can be examined with the Invalid Payload Sequence Count statistic of the Coordinator.

The following diagram illustrates the general structure of the schedule used in this application.

Figure 24: Fragmentation Application Schedule.

Coordinator Device

• LED0 toggles every time a packet is successfully transmitted to the Node (almost always on because of the high packet rate).

• LED1 toggles every time a packet is successfully received from the Node (almost always on because of the high packet rate).

Interface	Name	Description
SW1	Reset Stats	Reset the TX and RX statistics
SW2	N/A	N/A
LED0	Transmission Success	Toggle LED when a wireless transmission is successful.
LED1	Reception Success	Toggle LED when a wireless reception is successful.
LED2	N/A	N/A

Node Device

• LED0 toggles every time a packet is transmitted to the Coordinator (almost always on because of the high packet rate).

• LED1 toggles every time a packet is successfully received from the Coordinator (almost always on because of the high packet rate).

Interface	Name	Description
SW1	Reset Stats	Reset the TX and RX statistics.
SW2	N/A	N/A
LED0	Transmission Occurence	Toggle LED when a wireless transmission occurs.
LED1	Reception Success	Toggle LED when a wireless reception is successful.
LED2	N/A	N/A

Configuration

This application does not require specific configurations.

Terminal

Host terminal configuration should be as follows:

• Speed (baud): 115200

• Data bits: 8

• Stop bit: 1

• Parity: None

• Flow control: None

The following figure shows the serial interface output of this application.

Figure 25: Fragmentation Serial Interface Output