timeReceived#

RAIL_PacketTimeStamp_t RAIL_RxPacketDetails_t::timeReceived

The timestamp of the received packet in the RAIL timebase.

When not available it will be RAIL_PACKET_TIME_INVALID.

crcPassed#

bool RAIL_RxPacketDetails_t::crcPassed

Indicates whether the CRC passed or failed for the received packet.

It is true for RAIL_RX_PACKET_READY_SUCCESS packets and false for all others.

It is always available.

isAck#

bool RAIL_RxPacketDetails_t::isAck

Indicate whether the received packet was the expected ACK.

It is true for the expected ACK and false otherwise.

It is always available.

An expected ACK is defined as a protocol-correct ACK packet successfully-received (RAIL_RX_PACKET_READY_SUCCESS or RAIL_RX_PACKET_READY_CRC_ERROR) and whose sync word was detected within the RAIL_AutoAckConfig_t::ackTimeout period following a transmit which specified RAIL_TX_OPTION_WAIT_FOR_ACK, requested an ACK, and auto-ACK is enabled. When true, the ackTimeout period was terminated so no RAIL_EVENT_RX_ACK_TIMEOUT will be subsequently posted for the transmit.

A "protocol-correct ACK" applies to the 802.15.4 or Z-Wave protocols for which RAIL can discern the frame type and match the ACK's sequence number with that of the transmitted frame. For other protocols, the first packet successfully-received whose sync word was detected within the ackTimeout period is considered the expected ACK; upper layers are responsible for confirming this.

rssi#

int8_t RAIL_RxPacketDetails_t::rssi

RSSI of the received packet in integer dBm.

This RSSI measurement is started as soon as the sync word is detected. The duration of the measurement is PHY-specific.

When not available it will be RAIL_RSSI_INVALID_DBM.

lqi#

uint8_t RAIL_RxPacketDetails_t::lqi

The link quality indicator of the received packet.

A zero would indicate a very low quality packet while a 255 would indicate a very high quality packet.

When not available it will be 0.

syncWordId#

uint8_t RAIL_RxPacketDetails_t::syncWordId

For radios and PHY configurations that support multiple sync words, this number is the ID of the sync word that was used for this packet.

It is always available.

subPhyId#

uint8_t RAIL_RxPacketDetails_t::subPhyId

In configurations where the radio has the option of receiving a given packet in multiple ways, indicates which of the sub-PHY options was used to receive the packet.

Most radio configurations do not have this ability and the subPhyId is set to 0.

Currently, this field is used by the BLE Coded PHY, the BLE Simulscan PHY and the SUN OFDM PHYs. In BLE cases, a value of 0 marks a 500 kbps packet, a value of 1 marks a 125 kbps packet, and a value of 2 marks a 1 Mbps packet. Also, see RAIL_BLE_ConfigPhyCoded and RAIL_BLE_ConfigPhySimulscan.

In SUN OFDM cases, the value corresponds to the numerical value of the Modulation and Coding Scheme (MCS) level of the last received packet. The packet bitrate depends on the MCS value, as well as the OFDM option. Packets bitrates for SUN OFDM PHYs can be found in 802.15.4-2020 specification, chapter 20.3, table 20-10. Ex: Packet bitrate for OFDM option 1 MCS0 is 100kb/s and 2400kb/s for MCS6.

It is always available.

antennaId#

uint8_t RAIL_RxPacketDetails_t::antennaId

For Antenna Control configurations where the device has multiple antennas, this indicates which antenna received the packet.

When there is only one antenna, this will be set to the default of 0.

It is always available.

channelHoppingChannelIndex#

uint8_t RAIL_RxPacketDetails_t::channelHoppingChannelIndex

When channel hopping is enabled, this field will contain the index of the channel in RAIL_RxChannelHoppingConfig_t::entries on which this packet was received, or a sentinel value.

On EFR32XG1 parts, on which channel hopping is not supported, this value is still part of the structure, but will be a meaningless value.

It is always available.

channel#

uint16_t RAIL_RxPacketDetails_t::channel

The channel on which the packet was received.

It is always available.

Note

• It is best to fully process (empty or clear) the receive FIFO before changing channel configurations (RAIL_ConfigChannels() or a built-in configuration) as unprocessed packets' channel could reflect the wrong configuration. On EFR32xG1 only this advice also applies when changing channels for receive or transmit where unprocessed packets' channel could reflect the new channel.