Fragmentation
Description
The Fragmentation application demonstrates the combined use of two SPARK Wireless Core (SWC) features: fragmentation and auto-reply. A bidirectional link is configured to send payloads bigger than the maximum size supported by the transceiver. The Node uses the auto-replies to the received Coordinator’s packets to transmit the data.
Fragmentation
The application generates a very large payload of pseudo-random data for transmission. The payload is internally split up into chunks that can fit the transceiver’s FIFO before being sent over-the-air. On the receiver side, the 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 through auto-replies by the Node. Refer to Auto-Reply for more details.
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.
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.
Application Data Flow
The application’s data flow is shown in the figure below.
Figure 19: Fragmentation Application Data Flow.
The application generates a random 495-byte payload prepended by a 4-byte CRC and suffixed by a 1-byte sequence ID, resulting in an application payload size of 500 bytes. The packet exchange is halted until both devices are paired. Once successfully paired, the 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 almost identical in both directions for bi-directional configurations, the difference being that the Node transmits over auto-replies instead of main frames.
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.
Application Schedule
The following diagram illustrates the general structure of the schedule used in this application.
Figure 20: Fragmentation Application’s Schedule.
Pairing
By default, devices are unpaired at boot. To use the application, start by pairing the devices.
- Pairing:
Press the SW1 button on both devices to start the pairing procedure; RGB should blink blue twice when doing so.
If the pairing procedure is unsuccessful after 10 seconds, the pairing process stops and the RGB should blink red twice.
Once the pairing procedure is successfully completed, the RGB turns magenta and the devices can start exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; the RGB should blink red twice to indicate the unpairing procedure is in progress.
Unpairing causes the devices to forget their learned addresses. The devices are no longer able to exchange application data.
To start a new pairing procedure, both devices must be unpaired first.
Note
LED behavior changes in pairing mode versus normal execution mode. During pairing mode, LEDs indicate pairing status as described below. Once paired, LEDs indicate packet transmission and reception and fallback mode status.
- Pairing:
Press the SW1 button on both devices to start the pairing procedure; LED0 should blink twice when doing so.
If the pairing procedure is unsuccessful after 10 seconds, the pairing process stops and all the LEDs blink twice.
Once the pairing procedure is successfully completed, the LEDs will cascade and the devices can start exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; All LEDs should blink twice to indicate the unpairing procedure is in progress.
Unpairing causes the devices to forget their learned addresses. The devices are no longer able to exchange application data.
To start a new pairing procedure, both devices must be unpaired first.
Board User Interface
LED1 toggles every time a packet is successfully transmitted (almost always on because of the high packet rate).
LED2 toggles every time a packet is successfully received (almost always on because of the high packet rate).
Interface |
Name |
Description |
|---|---|---|
SW1 |
Pairing Process |
Pair or unpair the device depending on the current state. |
SW2 |
Reset Stats |
Reset the TX and RX statistics. |
SW3 |
N/A |
N/A |
SW4 |
N/A |
N/A |
LED1 |
Transmission Occurence |
Toggle LED when a wireless transmission occurs. |
LED2 |
Reception Success |
Toggle LED when a wireless reception is successful. |
LED3 |
N/A |
N/A |
LED4 |
N/A |
N/A |
RGB |
Pairing Event |
Indicate pairing event as described in the pairing section. |
LED0 toggles every time a packet is successfully transmitted (almost always on because of the high packet rate).
LED1 toggles every time a packet is successfully received (almost always on because of the high packet rate).
Interface |
Name |
Description |
|---|---|---|
SW1 |
Pairing Process |
Pair or unpair the device depending on the current state. |
SW2 |
Reset Stats |
Reset the TX and RX statistics. |
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 |
Terminal
The following figure shows the terminal output of this application.
See Viewing the Terminal for details on how to view the terminal output.
Figure 21: Fragmentation Serial Interface Output
See Wireless Core API - Statistics for more details.