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 21: 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 22: Fragmentation Application’s Schedule.
Pairing
On boot, devices attempt to pair automatically. If unsuccessful, manual pairing can be performed afterward to use the application.
- Auto Pairing:
On boot, devices automatically start the pairing process. RGB blinks blue twice to indicate that pairing is in progress.
If the pairing procedure is unsuccessful, RGB blinks red twice after 10 seconds.
Once successfully paired, RGB turns magenta, and the devices begin exchanging application data.
- Manual Pairing:
Press the SW1 button on both devices to start the pairing procedure; RGB blinks blue twice when doing so.
If the pairing procedure is unsuccessful, RGB blinks red twice after 10 seconds.
Once successfully paired, RGB turns magenta, and the devices begin exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; RGB blinks red twice to indicate that unpairing has been completed.
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.
- Auto Pairing:
On boot, devices automatically start the pairing process. LED0 blinks twice to indicate the pairing is in progress.
If the pairing procedure is unsuccessful, all LEDs blink twice after 10 seconds.
Once successfully paired, LEDs turn on sequentially, then turn off, and the devices begin exchanging application data.
- Manual Pairing:
Press and hold the SW1 button on both devices for 3 seconds to start the pairing procedure; LED0 blinks twice when doing so.
If the pairing procedure is unsuccessful, all LEDs blink twice after 10 seconds.
Once successfully paired, LEDs turn on sequenstially, then turn off, and the devices begin exchanging application data.
- Unpairing:
When paired, press and hold the SW1 button for 3 seconds to unpair the device; All LEDs blink twice to indicate that unpairing has been completed.
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, unpair, or abort the pairing process 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 |
Press and hold for 3 seconds: Pair, unpair, or abort the pairing process depending on the current state. |
Reset Stats |
Press for less than 250 ms: Reset the TX and RX statistics. |
|
SW2 |
||
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 |
Certification
This application has the ability to run in Certification Mode.
When certification mode is active, a dedicated LED is activated to indicate that the mode is enabled. All activity status LEDs (transmission, reception, fallback, and payload) are suppressed so that only the certification indicator is visible.
Board |
Indicator |
|---|---|
Quasar |
RGB LED steady yellow. |
EVK1.4 |
Steady LED2. |
Only one level of certification is needed for this application since the datarate is constant. The activation process must be performed independently on both the Coordinator and the Node.
Table 30: Certification Mode Activation Certification Mode
Activation Process
Fragmentation Certification
Hold SW2 at startup until the LED 1 blinks once, then release.
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 23: Fragmentation Serial Interface Output
See Wireless Core API - Statistics for more details.