Overview#

The following is a summary of functionality provided as part of the RAILtest application:

  • Transmit and receive packets

  • Schedule transmits at a specific time in the RAIL timebase

  • Configure RAIL address filtering to receive only specific packets

  • Enable CCA mechanisms (CSMA/LBT) to validate that a channel is clear before transmit

  • Set a timer callback in the RAIL timebase to see how the RAIL timer API works

  • Change the transmit channel within the current configuration's band

  • Change the transmit power level

  • Enable RF energy sensing of a specified duration across the 2.4 GHz and/or Sub 1-GHz bands, and sleep to wake on this event.

  • Output a continuous unmodulated tone for debugging

  • Output a continuous modulated PN9 stream for debugging

  • Enter into direct mode where data can be sent and received using asynchronous GPIOs as input and output

About RAILtest Versions#

RAILtest version 2.16 was released with Gecko SDK (GSDK) v4.4. Previous versions are as follows:

  • GSDK v4.3: RAILtest v2.15

  • GSDK v4.2: RAILtest v2.14

  • GSDK v4.1: RAILtest v2.13

  • GSDK v4.0: RAILtest v2.12

  • GSDK v3.2: RAILtest v2.11

  • GSDK v3.1: RAILtest v2.10

  • GSDK v3.0: RAILtest v2.9

  • GSDK v2.7: RAILtest v2.8

Modes#

RAILtest can be in a number of different modes. Each of these modes enables a subset of the test application's functionality, so that nonsensical commands (such as trying to transmit a tone and a packet at the same time) are ignored. The following are supported modes, with a short description.

  • None: The app is doing nothing, but the radio may be on. Parameters can be set in this mode based on the current radio state, and the timer can be used.

  • Stream: Send a stream of pseudo-random bits.

  • Tone: Send a tone at the carrier frequency.

  • ContinuousTx: Send an unending stream of packets, separated by a configurable delay.

  • DirectMode: Send data to and from a GPIO, without any packet handling.

  • PacketTx: Send a specific number of packets, with a summary print at the end.

  • ScheduledTx: Send one packet scheduled in the future.

  • TxAfterRx: Schedule a packet after each RX after a specific delay.

  • RxOverflow: Overflow on receive by delaying in RAILCb_RxPacketReceived.

  • TxUnderflow: Underflow by not loading data for the next TX sequence.

  • TxCancel: Cancel a single packet transmit to force an error callback.

  • RfSense: Sense RF energy to wake the radio.

  • PER (Packet Error Rate) test: A GPIO is toggled, and stats are gathered on received packets.

  • BER (Bit Error Rate) test: Statistics are gathered on received bits.

Command Line Interface#

The most powerful way to interact with the sample application is through the provided command line interface.

Command Input#

The syntax for this interface is the standard command [arg0, arg1, ...] syntax, where the number and type of arguments depend on the specific command. Numeric values can be prefixed with 0x to indicate hexadecimal values.

In RAILtest 2.8 (GSDK v2.7.x), the maximum number of arguments to any command is set by the value of MAX_COMMAND_ARGUMENTS, and the maximum length of each command line is set by the value of APP_COMMAND_INTERFACE_BUFFER_SIZE.

Starting in RAILtest 2.9 (GSDK v3.0), the maximum number of arguments to any command is set by the value of SL_CLI_MAX_INPUT_ARGUMENTS, and the maximum length of each command line is set by the value of SL_CLI_INPUT_BUFFER_SIZE.

For a full listing of the command options see Full Help Text or use the help command.

Command Responses#

All responses to commands are formatted in a human readable yet parsable format. This format has two variations: single and multiline. Both follow these rules.

  • Start and end with curly braces { }

  • List the command name, enclosed in parentheses ( )

  • Contain any number of tag/value pairs enclosed in curly braces { }

  • Carriage returns and line feeds are treated as whitespace by any parser

Single Response#

Used when a command has a single response.

  • There is a single start/end curly brace wrapper

  • Tag/value pairs are wrapped in a single set of curly braces, separated by a colon {tag:value}.

Example:

> getchannel
{{(getchannel)}{channel:4}}

Multi Response#

Used when a command may have multiple responses, such as when reading a block of memory or receiving multiple packets.

  • Response starts with a header, delimited by a hash # at the start of the line.

  • Header includes the command name, followed by any tags individually wrapped with curly braces { }.

  • Following the header, any number of responses can be provided.

  • Data lines do not contain the command name or tags, only the values that correspond to the tags in the order described in the header.

Example:

> getmemw 0x20000000 4
#{{(getmemw)}{address}{value}}
{{0x20000000}{0x0000e530}}
{{0x20000004}{0x000051c6}}
{{0x20000008}{0x0000c939}}
{{0x2000000c}{0x0000e090}}