Railtest User’s Guide

परिचय

टीप: This section replaces UG409: RAILtest User’s Guide. Further updates to this user guide note will be provided here.
The RAILtest application (RAILtest) provides you with a simple tool for testing the radio and the functionality of the RAIL library.
For more advanced usage, developers must write software against the RAIL library and create a custom radio configuration.
Proprietary is supported on all EFR32FG devices. For others, check the device’s data sheet under Ordering Information > Protocol Stack to see if Proprietary is supported. In Proprietary SDK version 2.7.n, Connect is not supported on EFR32xG22.

मुख्य मुद्दे

• Command Line Interface description
• अनुप्रयोग वैशिष्ट्ये
• Protocol-specific features
• चाचणी मोड

ओव्हरview

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 transmitting
• 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.14 was released with Gecko SDK (GSDK) v4.2. Previous versions are as follows:

• 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

मोड्स
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.

कमांड लाइन इंटरफेस

ओव्हरview
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 transmitting
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

मोड्स
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.

कमांड लाइन इंटरफेस
The most powerful way to interact with the sample application is through the provided command-line interface.

कमांड इनपुट
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.

आदेश प्रतिसाद
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}.

Exampले:

> 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.
• The header includes the command name, followed by any tags individually wrapped with curly ब्रेसेस { }.
• 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.

Exampले:

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

गौण

गौण
बटणे
When enabled, RAILtest can use up to two buttons. When pressed for a short duration (less than 1 second), the first button causes RAILtest to transmit one packet. When pressed for a long duration (greater than 1 second), the first button causes RAILtest to continuously transmit packets until the button is pushed again for a long duration. Pressing the second button causes RAILtest to increment the channel number used for TX and RX until the channel number wraps around to its beginning value.
Starting in RAILtest 2.9 (GSDK v3.0), button functionality is disabled by default. To enable button functionality, the Simple Button Driver software component needs to be enabled with an instance name of btn0 for the first button and btn1 for the second button.

LEDs
When enabled, RAILtest can use up to two LEDs. The first LED toggles when a packet is successfully received, and the second LED toggles when a packet is successfully transmitted.
Starting in RAILtest 2.9 (GSDK v3.0), LED functionality is disabled by default. To enable LED functionality, the Simple LED Driver software component needs to be enabled with an instance name of led0 for the first LED and led1 for the second LED.

एलसीडी
When enabled, RAILtest can use the LCD to show packets received and transmitted, as well as the channel selected and radio activity.
Starting in RAILtest 2.9 (GSDK v3.0), LCD functionality is disabled by default. To enable LCD functionality, the RAILtest Application, the Graphics software component needs to be enabled.

अर्ज वैशिष्ट्ये

अर्ज वैशिष्ट्ये
Packet Mode

The application starts in packet mode with the receiver enabled. In this mode, the application receives and transmits packets using the radio’s frame controller hardware. To disable receiving, use the rx 0 command. To transmit, use tx [numPackets] or press button PB0 if button support is enabled. To toggle the continuous transmit mode, hold PB0 for a couple of seconds if button support is enabled, or run the tx 0 command. When transmitting multiple packets or infinite packets there is a configurable delay in between each transmit. By default, this is 250 ms, but it can be set with the setTxDelay command.

All received packets are printed to the console with information like CRC, RSSI, and timestamp, as long as notifications are enabled. Notifications are enabled by default, but they can be turned off with the setRxNotification 0 command.
The application by default sends a fixed packet, but it is possible to override the values through setTxPayload. The command allows you to modify the values of the payload at specific offsets. For instance, to modify the first 4 bytes sent in the packet to be 0x01 0x02 0x03 0x04, use:

setTxPayload 0 0x01 0x02 0x03 0x04

ला view the currently configured TX Packet information, use printTxPacket.

टीप: The packet format depends on the current PHY configuration. If your PHY has a dynamic frame length byte, then that will be used to determine how much data should be sent.

डायरेक्ट मोड
In direct mode, the radio will still attempt to decode received packets, but it will only be able to transmit packets sent over the DIN pin. The GPIOs for direct mode are fixed for now to the following pins.

DOUT – EFR32_PC11 -> EXP_HEADER16/WSTK_P13
DIN – EFR32_PC10 -> EXP_HEADER15/WSTK_P12

The data on these pins is an asynchronous stream of bits at the expected data rate from the radio (DOUT) or to the radio (DIN). To enter direct mode, issue the directMode 1 command after starting the app. To leave direct mode, use directMode 0. If you want to transmit, you must enable the transmitter by issuing directTx 1 and later stop it with directTx 0. Receive is controlled using the standard rx 1/0 command, but is enabled by default when not transmitting.

टीप: Direct mode does not work in certain modulations (for example, 4FSK). If you require this mode, contact support to verify your configuration.

Channels/Frequencies
The specific channel configuration depends on the PHY configuration you have chosen for your test app. To switch between channels, use the setChannel [num] command. If RX is active (rx 1), then any TX or RX in progress will be aborted, and the new channel switched to. In addition, if button support is enabled, you can use button PB1 to cycle through channels.

To modify your frequency to a value not defined in the channel list, you will need to set the application into the FREQUENCY_OVERRIDE debug mode via set Debug Mode, which tells the application to ignore the current channel selection. Once in the FREQUENCY_OVERRIDE debug mode, you can use the freqOverride command to switch to another center frequency.

टीप: The freqOverride command requires you to be in FREQUENCY_OVERRIDE debug mode. The radio state must also be IDLE for the frequency to be modified — call rx 0 first.

setDebugMode 1
freqOverride 865000000

To leave FREQUENCY_OVERRIDE debug mode and return to normal channel-based operation, use setDebugMode 0.

खबरदारी: The modem is configured to a specific band. The application will not restrict you from changing the frequency out of band, but this could cause significant issues, including forcing a chip reboot.

Command Scripting
The command scripting feature built into RAILtest allows for CLI commands to be executed without back-and-forth interaction on the command line. The same commands that can be executed one by one can be queued up within RAILtest and executed sequentially later. Additionally, a command script can be saved to flash, and any script saved to flash will run automatically on device boot.

In RAILtest 2.8 (GSDK v2.7.x), support is integrated into RAILtest to use a command script in RAM, but to use a command script in flash, the Flash Data plugin must be enabled.
In RAILtest 2.9 (GSDK v3.0), to use a command script in RAM, the CLI Storage in RAM software component needs to be enabled with an instance name of inst0. To use a command script in Flash, the CLI Storage in NVM3 software component needs to be enabled with an instance name of inst0.
हे माजीample of how to enter, print, and run a script from RAM. Note that the wait command needs to be used to allow time for the first scripted command (that is, tx 1 ) to successfully run to completion before the second scripted command (that is, tx 2) starts.

enterScript
tx 1
वाट पहा ८
tx 2
endScript
printScript
runScript

हे माजीample of how to enter, print, run, and clear a script from Flash.

enterScript 1
tx 1
वाट पहा ८
tx 2
endScript
printScript 1
runScript 1
clearScript 1

हे माजीample of how to enter and run a script from Flash on boot.

enterScript 1
tx 1
वाट पहा ८
tx 2
endScript
रीसेट

टीप: For rapid command entry (for example, automated testing), you may need to increase the USART RX buffer from its default value, specified by a define similar to SL_IOSTREAM_USART_VCOM_RX_BUFFER_SIZE in RAILtest 2.9, to account for long command string entry being interrupted by chip interrupts. For lengthy (for example, hours-long) automated test programs, a notable decrease in test time will come from disabling CLI command history, setting SL_CLI_NUM_HISTORY_BYTES to 0 (RAILtest 2.9).

RAIL Timebase
The microsecond RAIL timebase is used for features requiring specific timing. You can read this timebase with get Time, and you can also set this microsecond timebase with set Time. Avoid changing the timebase when the timebase is actively being used, such as during clear channel assessment, during scheduled TX or RX, and so on.

Scheduled TX
The RAIL API has its own timebase that can be used to schedule the start of transmits. It measures time as a 32-bit integer in microseconds. As part of this change, many APIs will now return the time they were run, all RX packets report the time they were received, and all TX packets return the time that the transmission was completed. There is also the command getTime to print the current time in the RAIL timebase.
To test scheduled transmit, we provide two commands: txAt and txAfterRx. These allow you to send a packet at an absolute time in the RAIL timebase or exactly some number of microseconds after each receive, respectively.

टीप: These APIs should provide reliable timing, but you may have to adjust for overhead that relates to preamble and PA ramp time in order to transmit at the exact time you want.

चॅनल मूल्यांकन साफ ​​करा
The RAIL API provides the ability to specify a Pre-Transmit Operation for every transmit, one of which is the Scheduled Transmit discussed above. Others are also provided to support two common medium access methodologies that delay transmission until the channel is clear:

• CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance) — based on IEEE 802.15.4 specification
• LBT (Listen Before Talk) — based on ETSI EN 300 220-1 specification

Both CSMA-CA and LBT are similar: Before transmission, a device waits for a random ‘backoff’ period of time and then performs a CCA (Clear Channel Assessment) for a fixed period of time. If the channel is free, the transmission proceeds; if busy, the process is repeated with a new random backoff period. The random backoff period is determined by a randomly chosen multiple of a fixed backoff unit of time.
For CSMA-CA, the random multiplier is a power-of-2 exponential whose range increases on each try up to a limit, and the CCA period is typically short — smaller than a backoff unit and around the time it takes a small packet to be transmitted. For LBT, the random multiplier is linear and typically chosen to allow the random period to range up to the CCA period, which can be quite long — much longer than the on-air time of the actual transmission it’s gating. LBT also specifies that if the channel is found busy during CCA, the process cannot repeat until the channel is free.
In RAIL and RAILtest, several parameters are exposed through the setLbtParams and getLbtParams commands to configure either CSMA-CA or LBT operation. Their interpretation depends on which mode has been chosen:

• minBo: Minimum backoff. For CSMA-CA, the first try’s power-of-2 random exponential range, that is, the backoff multiplier, will range from 0 to 2^minBo – 1. Subsequent tries increase minBo by 1 up to maxBo. For LBT, this is the minimum backoff multiplier for all tries, typically 0.
• maxBo: Maximum backoff. For CSMA-CA, this is the maximum power-of-2 random exponential range to which subsequent tries can increase. For LBT, this is the maximum backoff multiplier for all tries, typically maxBo * backoff = duration. If both minBo and maxBo are 0, a non-random fixed backoff time is configured.
• tries: The maximum number of tries (‘busy’ CCAs), up to 15, that the CSMA-CA or LBT operation will tolerate before declaring the transmission a failure due to channel busy. A value of 0 will perform no CCA assessments and always transmit immediately.
• thresh: The CCA RSSI threshold, in dBm, above which the channel is considered ‘busy’.
• backoff: The backoff unit period, in RAIL’s microsecond time base. This is multiplied by the random backoff multiplier controlled by minBo and maxBo to determine the overall backoff period. For random backoffs, this value must be in the range 100 to 511
  microseconds; for fixed backoffs, it can go up to 65535 microseconds.
• duration: The CCA duration, in RAIL’s microsecond time base. The radio determines the maximum RSSI during this period for comparison against the CCA threshold.
• timeout: An overall timeout, in RAIL’s microsecond time base, for the operation. If transmission does not start before this timeout expires, the transmission will fail. This is more important for limiting LBT due to LBT’s unbounded requirement that if the channel is busy, the next try must wait for the channel to clear. A value of 0 indicates that no timeout is imposed.

अनेक माजीampलेस:

• RAILtest’s default parameters are suitable for the IEEE 802.15.4 PHY for CSMA-CA, equivalent to: setLbtParams 3 5 4 -75 320 128 0. This specifies up to 4 CCA attempts. The 1st will choose a random multiplier of 0..7 (2^3-1), the 2nd 0..15 (2^4-1), the 3rd
  0..31 (2^5-1), and the 4th 0..31 since the maxBo limit is 5.
• ETSI EN 300 220-1 LBT’s parameters in the 863 MHz band would be: setLbtParams 0 10 15 -80 500 5000 1000000. This specifies a 5 millisecond CCA duration with a random backoff period of 0..5 milliseconds (0..10 * 0.5 milliseconds) and a 1 second timeout limit in case the channel remains busy.
• A single CCA of 160 microseconds after a fixed 1024 microsecond backoff, against a -70 dBm threshold would be: setLbtParams 0 0 1 -70 1024 160 0.

In RAILtest, CSMA-CA and LBT are enabled as a mode applied to subsequent transmits through setLbtMode, whose choices are ‘off’, ‘csma’, and ‘lbt’.

टीप: On EFR32, LBT is currently implemented using the EFR32’s CSMA-based hardware engine, so LBT parameters are mapped to roughly equivalent CSMA parameters.
टीप: Scheduled Transmit and Clear Channel Assessment are currently mutually exclusive, with Scheduled Transmit taking precedence.

पत्ता फिल्टरिंग
The address filtering code examines the packet as follows.

Bytes: 0 – 255	८७८ - १०७४	८७८ - १०७४	८७८ - १०७४	चल
डेटा 0	Field0	डेटा 1	Field1	डेटा 2

In the above structure, anything listed as DataN is an optional section of bytes that will not be processed for address filtering. The FieldN segments reference the specific sections in the packet that will be examined during filtering for addresses. There may be up to four addresses per field, and they may each have a size of up to 8 bytes. To set up address filtering, first configure where the addresses are in the packet and how long they are. Next, configure what combinations of matches in Field0 and Field1 should constitute an address match. Lastly, enter addresses into the tables for each field and enable them.

The configAddressFilter command can be used to set the offsets and sizes for the address fields, as well as how combinations of matches in Field0 and Field1 are combined to determine whether or not an address matches.
Configuring which combinations of Field0 and Field1 constitute a match is the most complex portion of the address filter. The easiest way to think about this is with a truth table. If you consider each of the four possible address entries in a field, you can have a match on any one of those or a match for none of them. This is shown in the 5×5 truth table below, where Field0 matches are the rows and Field1 matches are the columns.

फील्ड	कोणताही सामना नाही	पत्ता १	पत्ता १	पत्ता १	पत्ता १
कोणताही सामना नाही	बिट0	बिट1	बिट2	बिट3	बिट4
पत्ता १	बिट5	बिट6	बिट7	बिट8	बिट9
पत्ता १	बिट10	बिट11	बिट12	बिट13	बिट14
पत्ता १	बिट15	बिट16	बिट17	बिट18	बिट19
पत्ता १	बिट20	बिट21	बिट22	बिट23	बिट24

Since this is only 25 bits, it can be represented in one 32-bit integer, where a 1 indicates a filter pass and a 0 indicates a filter fail. This is the matchTable parameter in the configAddressFilter command. For a simple one-field configuration, set the matchTable to 0x1fffffe, and for a two-field configuration, pairing indices across the fields use 0x1041040.
After you have configured address filtering, you must also set which addresses are valid and enable them. This can be done with the setAddress and setAddressEnable commands. You must also turn on the address filtering feature with the setAddressFiltering command.
माजी म्हणूनample, to configure an address of 0x00 0x01 0x02 0x03 in field0, index0 for a filter that has one field starting at offset 0 with a length of 4 bytes, use the following commands.

configAddressFilter 0x1fffffe 0 4 0 0
setAddress 0 0 0x00 0x01 0x02 0x03
setAddressEnable 0 0 1
setAddressFiltering 1

In addition to the standard address filtering, if the frame length decoding algorithm is by frame type, then additional filtering functionality is available. Address filtering can be enabled or disabled based on the frame type that is decoded. This can be set by the addressFilterByFrame command. This command takes an 8-bit bitmask, in which each bit represents whether addresses are present in that frame. The least significant bit determines whether to apply the address filter to frame 0, and the most significant bit determines whether to apply the address filter to frame 7. addressFilterByFrame must be called after configAddressFilter for it to take effect.

Automatic State Transitions
RAIL provides an API to configure state transitions to happen automatically on certain radio events:

• a successful reception
• a failed receive
• a successful transmission
• a failed transmission

All of these events can transition to a radio state of idle or receive. In addition, a transmission can be configured to happen after a successful receive.

These states are configured through the setTxTransitions and setRxTransitions commands. Each of these commands takes in two radio states, which are passed in as single-letter strings. To transition to receive after a transmission, regardless of its success, the command is setTxTransitions r r.
When setting the receive transitions, there is also a third argument, a bitfield to configure which events count as errors. The documentation for this bitfield can be found in the RAIL library documentation. Calling setRxTransitions i i 0xFF will ignore all errors that are possible to ignore, and transition the radio to idle after attempting to receive one packet.
In addition to the state transitions, timings can be set for the transitions. The six timings that are currently configurable are:

• idleToRx
• idleToTx
• rxToTx
• txToRx
• rxSearchTimeout
• txToRxSearchTimeout

Each of these timings configures an amount of delay between two states. The search timeouts allow you to set a maximum time that the chip will sit in the RX search state. These can be used to implement short receive timeouts. The rxSearchTimeout is used when transitioning to receive from idle, and the txToRxSearchTimeout is used when transitioning to receive from a past transmit. Setting [rx|txToRx]SearchTimeout to zero disables the timeout, and the radio will stay in RX until an event changes the state. Transitions to idle simply happen as fast as possible. Each timing is configurable in microseconds, up to a maximum of 13 ms, with the exception of txToRxSearchTimeout, which could be up to a quarter of the RAIL timebase, which is 2^32/4 microseconds or 18 minutes. For example, to disable the timeouts and set all other transitions to take 200 µs, use:

setStateTimings 200 200 200 200 0 0

Auto-Acknowledgment

RAIL contains auto-acknowledgment (ACK) APIs that are exposed through the RAILtest command interface. To initialize and enable this functionality, use autoAckConfig. For example, autoAckConfig rx 100 192 1000 will configure the ‘defaultState’, the state at which the radio returns after an ACK operation, to receive. Transitions from idle will take 100 µs. Turnaround transitions will take 192 µs and will wait for an ACK for 1000 µs. To load a custom ACK payload, call setAckPayload and setAckLength.

If a packet is received during the ACK window, then the isAck flag for that packet will be true. The ACK window begins at the end of the turnaround time and lasts for the timeout length. If auto acknowledgment is not enabled, then the isAck flag will always be false.
To customize ACK functionality, users can use the autoAckPause command to either skip the wait for an ACK on the transmit side or skip the transmit of an ACK on the receive side. To modify if/how the ACK is transmitted after a receive operation, use the setTxAckOptions command.

Conversely, after a transmit operation, waiting for ACK is controlled by the TX options configured by 1.
While auto-ACK is enabled, you should not call setTxTransitions and setRxTransitions.
You can disable auto-ACK by calling autoAckDisable. It will also reset the Rx and Tx transitions to idle.

RF Energy Sensing

The EFR32 has the ability to sense the presence of RF Energy above -20 dBm within either or both the 2.4 GHz and Sub 1-GHz bands and trigger an event if that energy is continuously present for certain durations of time.
This feature is exposed through library RAIL_RfSense () and RAIL_RfSensed () APIs, whose use is exemplified by the RAILtest commands rfSense and sleep. Both commands allow you to specify the duration in microseconds of continuous RF energy and which RF band(s) to monitor. The requested duration will be mapped to the nearest duration supported by the hardware; it is not terribly precise and can be off by a factor of 2 or more. Once RF energy of sufficient duration has been sensed, the sensing operation terminates, and a new one must be started if additional sensing is desired.

on EFR32 precludes normal packet reception in that same band; this is by design.

The sleep command allows you to activate RF sensing in combination with entering one of the Energy-Saving Modes, EM0. EM4.
To wake from these modes, RF energy of the specified duration and band must be sensed. Energy modes 0 through 3 will also wake and terminate RF sensing on any serial input to the CLI. EM4 does not support waking on serial input. It will only wake on RF sense or a pin reset.

काही माजीampलेस:
RFSENSE Legacy Mode:

> rfSense 500 2 // Sense RF energy of ~0.5ms or longer in sub-GHz band
{{(rfsense)}{RfSense:MHz}{RfUs:413}} // Closest HW supports is ~0.4ms
…
{{(rfSensedCheck)}{RfSensed:MHz}{RfUs:413}}

> sleep 2 500 1 // Sleep in EM2 for RF energy of ~0.5ms in 2.4 GHz band
{{(sleep)}{EM:2}{SerialWakeup:On}{RfSense:GHz}}
…
{{(sleepWoke)}{EM:2}{SerialWakeup:No}{RfSensed:Yes}{RfUs:413}}

> sleep 4 500 3 // Sleep in EM4 for RF energy of ~0.5ms in any band
{{(sleep)}{EM:4s}{SerialWakeup:Off}{RfSense:Any}}
…
{{(reset)}{App:RAILtest}{Built:Jul 19 2019 13:36:24}}
{{(sleepWoke)}{EM:4s}{SerialWakeup:No}{RfSensed:Yes}}

RFSENSE Selective Mode (Transmit Node Setup):

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:27993006}}

> configRfSenseWakeupPhy
{{(configRfSenseWakeupPhy)}{RFSense Wakeup PHY:Enabled}}

> fifoModeTestOptions 1 0 // Manually load Tx FIFO to transmit only preamble and syncword
{{(fifoModeTestOptions)}{TxFifoManual:Enabled}{RxFifoManual:Disabled}}

> setRfSenseTxPayload 0x2 0xB16F // <Syncword Size(Bytes)> <Syncword>
{{(setRfSenseTxPayload)}{RFSense Payload:Set}}

> tx 1
{{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:54463886}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:57481907}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:57481861}{timePos:6}{lastTxStart:57398486}{ccaSuccess:0}
{failed:0}{lastTxStatus:0x000000000}{isAck:False}}

RFSENSE Selective Mode (Receive Node Setup for EFR32xG22):

> sleep 2 2 0xB16F 1 // <EM Mode> <Syncword Size(Bytes)> <Syncword> <RFBand>
{{(sleep)}{RfSense:Enabled}{None:Disabled}{Time:14176659}}
…
{{(sleepWoke)}{EM:2}{SerialWakeup:No}{RfSensed:Yes}{RfUs:0}}

> rfsense 2 0xB16F 1 // <Syncword Size(Bytes)> <Syncword> <RFBand>
{{(rfsense)}{RfSense:Enabled}{None:Disabled}{Time:44817696}}

> {{(rfSensedCheck)}{RfSensed:GHz}{RfUs:0}}

मल्टी-टाइमर
If the multi-timer is never enabled (or subsequently disabled with enableMultiTimer), then the RAIL timer is a single-instance, hardware timer. If the multi-timer is enabled, the RAIL timer becomes one instance of the software-based multi-timer. The multitimer can only be enabled or disabled when no timers are running.

Protocol Specific Features

Protocol-Specific Features
IEEE 802.15.4

RAIL provides IEEE 802.15.4-specific hardware acceleration that can be configured through RAILtest commands. To configure the IEEE 802.15.4 2.4 GHz Radio Configuration, use config2p4GHz802154. This will configure the IEEE 802.15.4 2.4 GHz modem settings as well as channel scheme, making channels 11-26 available for use. To configure IEEE 802.15.4 hardware acceleration, use the enable802154 command. The options exposed in enable802154 allow you to configure similar parameters as autoAckConfig.

Indeed, Auto-ACK is enabled when calling enable802154. Thus, do not call setRxTransitions or setTxTransitions after an enable802154 while Auto-ACK is enabled. The IEEE 802.15.4 ACK payload is already loaded into the ACK buffer; do not call setAckPayload or setAckLength. However, you will want to enable the Wait-For-ACK transmit option through configTxOptions so the hardware looks for the specific ACK corresponding to the transmitted packet. RAILtest is configured to always set the frame pending bit in the ACK if it successfully receives a data command to the node. Any ACK modifications should use the commands detailed in the section Auto Acknowledgment.

To configure the IEEE 802.15.4 SubGHZ SUN FSK GB868 mode (802.15.4e and 802.15.4g), use ‘config863MHz802154’ or ‘config915MHz802154’. The different options can be configured using the set802154e and set802154g commands. These commands map very closely to the RAIL API that it wraps, so refer to the RAIL Library doxygen for further information.

Further IEEE 802.15.4 configuration is done through acceptFrames, setPromiscuousMode, and setPanCoordinator. To configure the node’s address, use the setPanId802154, setShortAddr802154, or setLongAddr802154 commands. These commands map very closely to the RAIL API that it wraps, so refer to the RAIL Library doxygen for further information.
From this point, use the normal tx and rx commands to send packets back and forth.
Transmit side:

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1846852}}
> config2p4GHz802154
{{(config2p4GHz802154)}{802.15.4:Enabled}}
> enable802154 rx 100 192 1000
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:100}{turnaroundTime:192}
{ackTimeout:1000}}
// Turn on transmit wait-for-ACK option
> configTxOptions 1
{{(configTxOptions)}{waitForAck:True}{removeCrc:False}{syncWordId:0}{txAntenna:Any}{altPreambleLen:False}
{ccaPeakRssi:False}}

// Load packet directed towards the receive side
// Packet has the destination address set on the receive side.
> setTxLength 26
{{(setTxLength)}{TxLength:26}}
> setTxPayload 0 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}}
> setTxPayload 10 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05
0x06 0x07 0x08 0x09 0x00 0x00 0x00 0x00 0x00 0x00}}
> setTxPayload 20 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05
0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f}}

// Assumes there is another node that will receive and ACK
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:157683158}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:157689582}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:157689516}{failed:0}{lastTxStatus:0x0}{isAck:False}}
{{(rxPacket)}{len:4}{timeUs:157689914}{crc:Pass}{rssi:-20}{lqi:96}{phy:0}{isAck:True}{syncWordId:0}{antenna:0}
{channelHopIdx:254}{payload: 0x05 0x02 0x00 0x00}}

// Assumes a node does not ACK
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:165139148}}
{{(rxAckTimeout)}{ackTimeoutDuration:1021}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:165187375}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:165145515}{failed:0}{lastTxStatus:0x0}{isAck:False}}

Receive side:

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1846852}}
> config2p4GHz802154
{{(config2p4GHz802154)}{802.15.4:Enabled}}
> enable802154 rx 100 192 1000
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:100}{turnaroundTime:192}
{ackTimeout:1000}}
> setPanId802154 0x1234 // PANID: 0x1234, OTA Value: 0x34 0x12
{{(setPanId802154)}{802.15.4PanId:Success}}
> setShortAddr802154 0x3344 // Short Addr: 0x3344, OTA Value: 0x44 0x33
{{(setShortAddr802154)}{802.15.4ShortAddress:Success}}
// Long Addr (OTA): 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66
> setLongAddr802154 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}
> rx 1
{{(rx)}{Rx:Enabled}{Idle:Disabled}{Time:2070858}}

// Receive a packet and ACK it
{{(rxPacket)}{len:26}{timeUs:29662246}{crc:Pass}{rssi:-15}{lqi:82}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}
{channelHopIdx:254}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05 0x06
0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f}}

In 802.15.4, the first byte(s) written in the Tx buffer correspond to the PHR (physical header) and must follow a precise mapping, including at least the frame length. Formatting the PHR can be laborious and is error-prone. Silicon Labs recommends using ‘set802154PHR’.
For instance, in SUN FSK, to set this PHR:
| bit0 bit15|
| mode switch | reserved | FCS type | data whitening | frame length |
| 0 | 00 | 0 | 1 |20=000 0001 0100|
you can use:

> setTxLength 18 //must be >= frameLength+PHRsize-FCSsize
{{(setTxLength)}{TxLength:18}{TxLength Written:18}}
> setTxPayload 0 0x10 0x28
{{(setTxPayload)}{len:18}{payload: 0x10 0x28 0x11 0x22 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee
0x10 0x11}}

Or

> setTxLength 18 //must be >= frameLength+PHRsize-FCSsize
{{(setTxLength)}{TxLength:18}{TxLength Written:18}}
> set802154PHR 1 0 1
{{(set802154PHR)}{PhrSize:2}{PHR:0x2810}}
{{(set802154PHR)}{len:18}{payload: 0x10 0x28 0x11 0x22 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee
0x10 0x11}}

Note that ‘set802154PHR’:

• Only formats (and writes in the Tx buffer) the PHR. It does not check that the requested PHR format is coherent with the loaded PHY.
• Uses the TxLength value (set with ‘setTxLength’) to process the PHR frame length field.
• If the FCS size is known, then it set it to TxLength-PHRsize+FCSsize.
• If the FCS size is not known, then it is set it to TxLength-PHRsize (SUN OFDM and SUN OQPSK cases).

Note that the PHR value is interpreted by the HW both in Tx and Rx to dynamically adapt the processing.

Typical SUN OFDM usage:

> setTxLength 64
{{(setTxLength)}{TxLength:64}{TxLength Written:64}}
> Set802154phr 2 6 0
{{(set802154phr)}{PhrSize:4}{PHR:0x780c00}}
{{(set802154phr)}{len:64}{payload: 0x00 0x0c 0x78 0x00 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26
0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d
0x3e 0x3f}}
> tx 10
{{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:3116912126}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:3117028916}}
{{(txEnd)}{txStatus:Complete}{transmitted:10}{lastTxTime:3117028845}{timePos:6}{lastTxStart:3117026790} {ccaSucess:0}
{failed:0}{lastTxStatus:0x000000000}{isAck:False}}

To use 802.15.4 filtering with SUN OFDM PHYs on the Rx side

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:3470713331}}
> Enable802154 rx 200 1000 2000
{{(Enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:200}{turnarounTime:1000}
{ackTimeout:2000}{defaultFramePending:False}}
> set802154e 3
{{(set802154e)}{15.4E_GB868:True}{15.4E_EnhAck:True}{15.4E_ImplicitBroadcast:False}}
> setPanId802154 0xCDAB
{{(setPanId802154)}{802.15.4PanId:Success}}
> setLongAddr802154 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}

on Tx side

> SetTxPayload 4 0x01 0x2D 0xAB 0xCD 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78
{{(SetTxPayload)}{len:64}{payload: 0x00 0x0c 0x78 0x00 0x01 0x2d 0xab 0xcd 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26
0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d
0x3e 0x3f}}

To use continuous Tx (setTxStream) with SUN OFDM PHYs:

• All modes listed in RAIL_StreamMode_t from 0 to 5 are supported except the 1010 stream option.
• The PHR is interpreted to get the rate, scrambler, and frameLength parameters. Thus, take care to always format it correctly and load it in the TxFIFO.
• to get a packet of infinite length, PHR frameLength must be set to 0. For that, txLength must be set to 4
  > setTxLength 4
  {{(setTxLength)}{TxLength:4}{TxLength Written:4}}
  > set802154Phr 2 4 0
  {{(set802154Phr)}{PhrSize:4}{PHR:0x400}}
  {{(set802154Phr)}{len:4}{payload: 0x00 0x04 0x00 0x00}}
  > setTxStream 1
  {{(setTxStream)}{Stream:Enabled}{None:Disabled}{StreamMode:PN9}{Time:2504841818}}
• If the PHR frameLength is set to a value different from 0, it generates an infinite number of packets of size ‘frameLength’ with an IFS of 1ms.
• for a stream with data filled with a ramp started at a different offset for successive packets:
  > setTxstream 1 4
• To send a tone at the carrier frequency:
  > setTxTone 1
  It is equivalent to
  > setTxstream 1 0
• For an OFDM PHY, the tone can also be generated roughly at channel_bandwidth/6
  > setTxstream 1 5

WiSUN Specific
WiSUN is based on IEEE802.15.4 SUN PHYs but with a specific mode switch protocol.
Two commands support the WiSUN mode switch: trigModeSwitchTx and modeSwitchLife.
modeSwitchLife is optional and intended only for test automation or certification use.
You can also activate two specific Rx events, MODE_SWITCH_START and MODE_SWITCH_END. >Note: that they need to be enabled if modeSwitchLife is set to 1.
For Rx events MODE_SWITCH_START and MODE_SWITCH_END activation:
> setEventConfig 0x0 0x0 0x6000 0x6000
{{(setEventConfig)}{Mask:0x600000000000}{Values:0x600000000000}}

Concurrent Listening Specific
802.15.4 concurrent listening allows one radio to switch quickly enough between RF channels to detect the 802.15.4 preamble on either RF channel. This allows the application to use two 15.4 channels concurrently. Once preamble is detected, the radio stays on channel to receive the packet. It will also provide an ACK, if configured, and schedule any subsequent TX responses before resuming concurrent listening.
To configure concurrent listening, the following RAILtest commands must be issued:

// Setup 802.15.4 on the RX side.
> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> config2p4Ghz802154 1 0
{{(config2p4Ghz802154)}{802.15.4:Enabled}}

// Note: Channel must be set to one of the concurrent listening channels before enabling receive.
> setChannel 20
{{(setChannel)}{channel:20}}

> enable802154 rx 110 192 672 0
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:110}{turnaroundTime:192}
{ackTimeout:672}{defaultFramePending:False}}
> setPanId802154 4660 0
{{(setPanId802154)}{802.15.4PanId:Success}}
> setShortAddr802154 13124 0
{{(setShortAddr802154)}{802.15.4ShortAddress:Success}}
> setLongAddr802154 221 204 187 170 153 136 119 102 0
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}

// Configure 802.15.4 concurrent listening on channels 15 and 20.
> configRxChannelSwitching802154 15 20
{{(configRxChannelSwitching802154)}{Success:True}}

// Configure receive options to enable concurrent listening.
> setRxOptions 1024
{{(setRxOptions)}{storeCrc:False}{ignoreCrcErrors:False}{enableDualSync:False}{trackAborted:False}
{removeAppendedInfo:False}{rxAntenna:Any}{frameDet:On}{skipDCCal:False}{skipSynthCal:False}{rxChannelSwitching:True}
{fastRx2Rx:False}}

// Enable the radio receive mode
> rx 1

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
// Configure 802.15.4 concurrent listening on channels 11 and 17.
> configRxChannelSwitching802154 11 17
{{(configRxChannelSwitching802154)}{Success:True}}
> setChannel 17
{{(setChannel)}{channel:17}}
// Enable the radio receive mode
> rx 1

Concurrent listening can be disabled either by switching to a non-concurrent listening channel e.g.

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> setChannel 18
{{(setChannel)}{channel:18}}
// Enable the radio receive mode
> rx 1

Or, by disabling the rxChannelSwitching RX option, i.e., RAIL_RX_OPTION_CHANNEL_SWITCHING

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> setRxOptions 0
{{(setRxOptions)}{storeCrc:False}{ignoreCrcErrors:False}{enableDualSync:False}{trackAborted:False}
{removeAppendedInfo:False}{rxAntenna:Any}{frameDet:On}{skipDCCal:False}{skipSynthCal:False}{rxChannelSwitching:False}
{fastRx2Rx:False}}
// Enable the radio receive mode
> rx 1

टीप: Loading the PHY via e.g., config2p4Ghz802154, after configuring concurrent listening, will de-initialize concurrent listening, and configRxChannelSwitching802154 must be issued again to re-configure the feature.

ब्लूटूथ कमी ऊर्जा
RAIL provides Bluetooth Low Energy (BLE)-specific hardware acceleration. RAILtest provides a few wrappers over these APIs, but since BLE is so timing-critical, not much can be done through RAILtest commands. To enable BLE hardware acceleration, use the setBleMode 1 command. You can then configure channel-specific settings with setBleChannelParams. A preset configuration to enable advertising on channel 37 is available using the setBleAdvertising command.
RAILtest can output a BLE advertising packet on channel 37 with the following commands:

> rx 0
rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1999306}}
> setBleMode 1
setBleMode 1
{{(setBleMode)}{BLE:Enabled}}
> setBleAdvertising
setBleAdvertising 37
{{(setBleAdvertising)}{AdvertisingChannel:37}}
{{(setBleAdvertising)}{len:28}{payload: 0x02 0x1a 0xff 0xee 0xdd 0xcc 0xbb 0xaa 0x02 0x01 0x06 0x10 0x08 0x53 0x69
0x6c 0x61 0x62 0x73 0x20 0x52 0x41 0x49 0x4c 0x54 0x45 0x53 0x54}}
> tx 0
tx 0
> {{(tx)}{ContinuousTx:Enabled}{None:Disabled}{Time:16160500}}

After these commands, use your phone to search for available Bluetooth devices. You should see ‘Silabs RAILTEST’ as an available device. RAILtest is not a connectable device.

Z-तरंग
RAIL provides Z-Wave-specific hardware acceleration that can be configured through RAILtest commands. Users can use the setZWaveMode command to enter Z-Wave mode and then setZWaveRegion to specify one of the region-specific PHYs, which generally consist of three separate channels. More about these PHYs can be found in ITU-T G.9959. To send packets between nodes, the following commands must be entered on both nodes, using the same region.

RX Node:

// Turn the radio off first in order to configure it
> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:99647646}}
// Enable Z-Wave Mode (1) – beam detection enabled (0x2), promiscuous mode off (0x1)
> setzwavemode 1 2
{{(setZWaveMode)}{ZWAVE:Enabled}{Promiscuous:Disabled}{BeamDetect:Enabled}}
// Specify the EU Region
> setzwaveregion 0
{{(setZWaveRegion)}{ZWaveRegion:EU-European Union}{ZWaveRegionIndex:0}}

On the transmit side, the user must specify the correct Home ID of the target Z-Wave node. This can be skipped, however, by enabling promiscuous mode on the receiver via setZWaveMode and/or setZWaveOptions. Additionally, the user must specify an accurate length byte; otherwise, the transmitter may encounter an underflow. The CRC will be calculated on the fly by the radio hardware, so there is no need to specify it explicitly.

TX Node:

// Specify the Home ID in the packet. This is a 4-byte value, starting at byte 0
> setTxPayload 0 0xCA 0xFE 0xC0 0xDE
{{(setTxPayload)}{len:16}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee}}
// Specify the length byte (byte 7) for a packet
> setTxPayload 7 15
{{(setTxPayload)}{len:16}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee}}

On the receiver side, for basic functionality, the node must configure its own Home ID.
>Note: that this will set parameters for the node on which these commands are executed – they do not set the TX packet contents for outgoing packets. To skip Home ID configuration, promiscuous mode can also be enabled.

RX Node:

// The Home ID is CAFEC0DE, using a <don’t care= hash
setzwavehomeid 0xCAFEC0DE 0x55
{{(setZWaveHomeId)}{Status:Set}}

For more advanced receiver functionality, or to be used as a sniffer, channel hopping must be configured. As used in Z-Wave networks, the three channels in each of the Z-Wave regions can be used in rapid succession for different purposes. For a receiving node to be able to receive these packets on any arbitrary channel, the node uses hardware acceleration to hop through the three different channels at specific intervals, using preamble sense mode. The following specification configures the correct hopping scheme, with the on-channel time and preamble sense mode, as well as zero delay between channels. Note that while this configuration is accurate for most regions, Japan and Korea regions use 270 µs for all the channels, instead of the 270, 450, and 560 specified below. After this, packets can be transmitted on channel 0, 1, or 2, and will be received on the receiver node, without having explicitly set the channel.

RX Node:

// Configure the channel hopping algorithm
> configRxChannelHopping 0 2 270 0 1 2 450 0 2 2 560 0
{{(configRxChannelHopping)}{numberOfChannels:3}{buffer:0x200048b0}{Success:True}}
// Enable channel hopping
> enableRxChannelHopping 1
{{(enableRxChannelHopping)}{Success:True}}

TX Node:

setChannel 0
{{(setchannel)}{channel:0}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1518591782}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1518601722}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1518601679}{timePos:6}{lastTxStart:1518597116}{ccaSuccess:0}
{failed:0}{lastTxStatus:0x000000000}{isAck:False}}
setChannel 1
{{(setchannel)}{channel:1}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1522247672}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1522258337}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1522258277}{timePos:6}{lastTxStart:1522252961}{ccaSuccess:0}
{failed:0}{lastTxStatus:0x000000000}{isAck:False}}
setChannel 2
{{(setchannel)}{channel:2}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1526903409}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1526930874}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1526930821}{timePos:6}{lastTxStart:1526908743}{ccaSuccess:0}
{failed:0}{lastTxStatus:0x000000000}{isAck:False}}

RX Node:

{{(rxPacket)}{len:13}{timeUs:1508290532}{timePos:4}{crc:Pass}{rssi:-10}{lqi:114}{phy:0}{isAck:False}{syncWordId:0}
{antenna:0}{channelHopIdx:0}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb}}
{{(rxPacket)}{len:14}{timeUs:1511945271}{timePos:4}{crc:Pass}{rssi:-8}{lqi:100}{phy:0}{isAck:False}{syncWordId:0}
{antenna:0}{channelHopIdx:1}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc}}
{{(rxPacket)}{len:14}{timeUs:1516608125}{timePos:4}{crc:Pass}{rssi:-10}{lqi:102}{phy:0}{isAck:False}{syncWordId:0}
{antenna:0}{channelHopIdx:2}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc}}

Cancel Specific Protocol Mode
To cancel any of the specific BLE, 802.15.4, or Z-Wave modes, you can simply call deinitProtocol.

चाचणी मोड

चाचणी मोड
Packet Error Rate Testing

RAILtest can be used to determine the packet error rate (PER) for a given setup. To set up this test, a piece of test equipment needs to be configured to send a packet on the rising edge of a GPIO. The specific EFR32 pin and port to be used are identified by the defines PER_PIN and PER_PORT (RAILtest 2.8) or defines SL_RAIL_TEST_PER_PIN and SL_RAIL_TEST_PER_PORT (RAILtest 2.9). perRx 100 10000 configures the Packet Error Rate test to send 100 packets, waiting 10000 µs between each packet. At the end of the test, the app provides an output indicating that Per mode has finished, and the statistics on the test can be recovered with perStatus and status. Calling perRx 0 0 cancels an ongoing test, and calling perRx has the same effect as calling resetCounters.

बिट एरर रेट चाचणी
The EFR32 hardware can enter bit error rate (BER) receive mode for diagnostic purposes. In BER mode, the chip expects to receive a PN9 (x^9 + x^5 + 1) transmission. To run the BER test successfully, a radio configuration specific to BER mode must be generated by the radio configurator.
Use the setBerConfig command to specify how many bytes to receive in BER receive mode. The maximum number of bytes is 536870911. Specifying 0 or a number greater than the maximum possible value automatically configures the BER test to receive the maximum number of bytes for testing.
Use the berRx command to enter or exit BER receive mode. If the test is allowed to run to completion, there is no need to exit BER receive mode.
Use the berStatus command to query for test statistics during or after a test. The statistics are reset when setBerConfig is run or when berRx 1 is run. The statistics include:

• BitsToTest (total bits to be tested)
• BitsTested (the number of bits already received and tested)
• PercentDone (percentage of how many configured bytes have been received)
• RSSI (an instantaneous RSSI value corresponding to the last byte received)
• BitErrors (the number of received bits determined to be in error)
• PercentBitError (percentage of bit errors to bits tested)

काही माजीampलेस:

> setberconfig 100000

> berrx 1

> berstatus
{{(berStatus)}{BitsToTest:800000}{BitsTested:0}{PercentDone:0.00}
{RSSI:0}{BitErrors:0}{PercentBitError:0.00}}

// PN9 transmission enabled here

> berstatus
{{(berStatus)}{BitsToTest:800000}{BitsTested:121312}{PercentDone:15.16}
{RSSI:-23}{BitErrors:0}{PercentBitError:0.00}}

> berstatus
{{(berStatus)}{BitsToTest:800000}{BitsTested:800000}{PercentDone:100.00}
{RSSI:-24}{BitErrors:0}{PercentBitError:0.00}}

> berrx 1

> berstatus
{{(berStatus)}{BitsToTest:800000}{BitsTested:363936}{PercentDone:45.49}
{RSSI:-23}{BitErrors:0}{PercentBitError:0.00}}

> setberconfig 1000000

> berrx 1

> berstatus
{{(berStatus)}{BitsToTest:8000000}{BitsTested:888672}{PercentDone:11.11}
{RSSI:-23}{BitErrors:0}{PercentBitError:0.00}}

// PN9 transmission disabled here

> berstatus
{{(berStatus)}{BitsToTest:8000000}{BitsTested:4418528}{PercentDone:55.23}
{RSSI:-96}{BitErrors:960478}{PercentBitError:21.74}}

> berstatus
{{(berStatus)}{BitsToTest:8000000}{BitsTested:8000000}{PercentDone:100.00}
{RSSI:-97}{BitErrors:2752908}{PercentBitError:34.41}}

नानाविध

नानाविध
RAM Modem Reconfiguration
RAILtest can dynamically change the modem configuration, allowing for a quick evaluation of different protocols or settings without the need to compile or flash the chip. This is enabled through the writeRmrStructure, updateConfigurationPointer, and reconfigureModem commands. These commands are intended to be used only by Simplicity Studio and not directly from the CLI.

Register/Memory Access

टीप: These commands provide direct access to the chip’s address space. Writing a value to an address can change RAM and register values, and even reading from an address can change the operation of the chip. Any action taken with these commands will potentially conflict with the running program, possibly leading to unexpected behavior or a system crash. Only use these commands when instructed to do so by your Silicon Labs support contact.

To modify any memory on the system, use the getmemw and setmemw commands. To use getmemw, specify the starting address and the number of 32-bit words you want to read. Using setmemw is slightly different in that you specify the starting address and the 32-bit words to write, starting at the specified address. These commands operate on 32-bit words, so all addresses must be 32-bit aligned.

डीबग करा

• To output a tone on the current channel (or overridden frequency), use the setTxTone command.
• To output a PN9 or 101010 stream on the current channel on a certain antenna, TX_ANTENNA0 or TX_ANTENNA1, use the setTxStream command.

Full Help Text
RAILtest 2.14 (GSDK 4.2) Help Text

टीप: Each command is displayed (on the left) with its corresponding arguments and associated datatypes (on the right). Required command arguments and their datatypes are listed first (such as uint32) with potential optional arguments and their datatypes listed afterwards (such as uint32opt). The list of required command argument datatypes includes uint8, uint16, uint32, int8, int16, int32, and string. The list of optional command argument datatypes includes uint8opt, uint16opt, uint32opt, int8opt,  int16opt, int32opt, and stringopt.

Copyright © 2025 Silicon Laboratories.
सर्व हक्क राखीव.

कागदपत्रे / संसाधने

SILICON LABS RAILtest Application [pdf] वापरकर्ता मार्गदर्शक v7.24.2, RAILtest Application, Application

संदर्भ

• वापरकर्ता मॅन्युअल