EZRadioPRO devices are designed to be compliant with 802.15.4g standard (subGHz FSK) configured via the Wireless Development Suite (WDS) as per the datasheets (Si4467/68, Si4460/1/3/4). However the provided example does not configure the devices perfectly, there are two bugs which should be addressed by the user for now.

We highly recommend to read section 10.10 in AN633: Programming Guide for EZRadioPRO® Si4x6x Devices, before going further.

If you just download the example with the same PHY on two development boards the receiver won't send the ACK packet back as it is expected.

Note: the example runs on Si4467 and Si4468 with the regular (legacy) boot mode as well.

The bit endianness of the payload

The 802.15.4g standard defines the bit order to LSB first everywhere except the length field (within the PHR configured as Field 1) which must be in MSB first order (see our article about the 802.15.4 standard on RAIL).

The example defines the Data bit order in MSB first by default for all payload fields as it is depicted in the following picture.

You should set it to LSB first since the application is responsible for swapping the bits on Field 1 whenever it is needed (where it loads the TX FIFO, or reads out the RX FIFO).

Therefore the PHR parsing will fail expecting more or less payload bytes than the transmitter actually sends (not to mention that it will mix up the whitening and CRC configurations too).

The 4byte CRC seed

Though, as long as the bit endianness configured correctly (and the transmitted/expected Field contents matches) the two radio boards can communicate with each other and the receiver will always send an ACK packet back regardless of the transmitter's configuration (whether it uses data whitening or not and whether the 2 or the 4 bytes long CRC will be transmitted), the devices will not be compliant with the standard: the 4bytes CRC will be miscalculated due to it is using '0' seed, instead of the '1's (see the referred article above).

Unfortunately this bug cannot be solved by using the WDS only, you should modify the generated radio_config.h file by hand. According to the API docs the PKT_CRC_CONFIG.CRC_SEED bitfield is responsible for this configuration. Modify the property's value from 0x57 to 0xD7.

Testing the example against an EFR32 development kit

Prepare the EFR32

Build a RAILTest application, load it onto any EFR32 development kit and issue the following commands in this order (see UG409: RAILTest User's Guide for reference on the commands):

rx 0
config863Mhz802154
enable802154 rx 100 192 1000
set802154g 0xFF
setchannel 128
setPromiscuousMode 1
setrxoptions 0x03
rx 1

 

Prepare the EZRadioPRO

Load the example config attached to this article (find at the bottom of this page) on any development kit with a revC or revA radio. Note that the Base frequency field had been overwritten to 863.25MHz and the 100kbps 2FSK config had been selected.

Use EZRadioPRO as transmitter

If you miss to configure the EZRadioPRO to LSB first order, sending a packet will not be received by the EFR32 at all.

Correct the field bit endianness then send a packet by the EZRadioPRO.

The EFR32 will print out the following line on the command line:

Note: pay attention to how the payload's length (len:) and its first byte changes with the configuration's changes!

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x08 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

If you enable whitening on the EZRadioPRO only one bit will differ in the received payload:

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x18 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

Now disable data whitening and check Transmit Primary CRC (IEEE 32-bit) checkbox. If you transmit a packet this line will appear on the console:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x00 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

You might have guessed what will be the result if you check the Use data whitening checkbox:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

If you overwrite the PKT_CRC_CONFIG.CRC_SEED field in the radio_config.h the 4byte CRC will be calculated correctly and received by the EFR32 as well:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0xba 0x94 0x5f 0x14}}

Use the EZRadioPRO as receiver

You should configure the same payload on the EFR32 by the following commands to be compliant with the 802.15.4g bidirectional packet example's default payload:

settxlength 5
setTxPayload 0 0x08 0xA0 0x02 0x00 0x6A

With this payload the 2byte CRC will be applied with no whitening, and the LEDs will light up on the EZRadioPRO development board even if only the bit endianness bug was addressed.

Also, the packet will be received correctly if the whitening is enabled on the EFR32:

setTxPayload 0 0x18 0xA0 0x02 0x00 0x6A

If you don't correct the 4bytes CRC calculator's seed this packet won't be received, nor with enabled whitening:

setTxPayload 0 0x00 0xE0 0x02 0x00 0x6A

or

setTxPayload 0 0x10 0xE0 0x02 0x00 0x6A

 

Summary

In this article we introduced two bugs found in the 802.15.4g bidirectional packet example and the workaround on how to deal with them. Also a minimal test guide had been introduced in order to show how can we validate our CRC, whitening and payload configuration for the 802.15.4g standard.

 

EZRadioPRO devices are designed to be compliant with 802.15.4g standard (subGHz FSK) configured via the Wireless Development Suite (WDS) as per the datasheets (Si4467/68, Si4460/1/3/4). However the provided example does not configure the devices perfectly, there are two bugs which should be addressed by the user for now.

We highly recommend to read section 10.10 in AN633: Programming Guide for EZRadioPRO® Si4x6x Devices, before going further.

If you just download the example with the same PHY on two development boards the receiver won't send the ACK packet back as it is expected.

Note: the example runs on Si4467 and Si4468 with the regular (legacy) boot mode as well.

The bit endianness of the payload

The 802.15.4g standard defines the bit order to LSB first everywhere except the length field (within the PHR configured as Field 1) which must be in MSB first order (see our article about the 802.15.4 standard on RAIL).

The example defines the Data bit order in MSB first by default for all payload fields as it is depicted in the following picture.

You should set it to LSB first since the application is responsible for swapping the bits on Field 1 whenever it is needed (where it loads the TX FIFO, or reads out the RX FIFO).

Therefore the PHR parsing will fail expecting more or less payload bytes than the transmitter actually sends (not to mention that it will mix up the whitening and CRC configurations too).

The 4byte CRC seed

Though, as long as the bit endianness configured correctly (and the transmitted/expected Field contents matches) the two radio boards can communicate with each other and the receiver will always send an ACK packet back regardless of the transmitter's configuration (whether it uses data whitening or not and whether the 2 or the 4 bytes long CRC will be transmitted), the devices will not be compliant with the standard: the 4bytes CRC will be miscalculated due to it is using '0' seed, instead of the '1's (see the referred article above).

Unfortunately this bug cannot be solved by using the WDS only, you should modify the generated radio_config.h file by hand. According to the API docs the PKT_CRC_CONFIG.CRC_SEED bitfield is responsible for this configuration. Modify the property's value from 0x57 to 0xD7.

Testing the example against an EFR32 development kit

Prepare the EFR32

Build a RAILTest application, load it onto any EFR32 development kit and issue the following commands in this order (see UG409: RAILTest User's Guide for reference on the commands):

rx 0
config863Mhz802154
enable802154 rx 100 192 1000
set802154g 0xFF
setchannel 128
setPromiscuousMode 1
setrxoptions 0x03
rx 1

Prepare the EZRadioPRO

Load the example config attached to this article (find at the bottom of this page) on any development kit with a revC or revA radio. Note that the Base frequency field had been overwritten to 863.25MHz and the 100kbps 2FSK config had been selected.

Use EZRadioPRO as transmitter

If you miss to configure the EZRadioPRO to LSB first order, sending a packet will not be received by the EFR32 at all.

Correct the field bit endianness then send a packet by the EZRadioPRO.

The EFR32 will print out the following line on the command line:

Note: pay attention to how the payload's length (len:) and its first byte changes with the configuration's changes!

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x08 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

If you enable whitening on the EZRadioPRO only one bit will differ in the received payload:

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x18 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

Now disable data whitening and check Transmit Primary CRC (IEEE 32-bit) checkbox. If you transmit a packet this line will appear on the console:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x00 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

You might have guessed what will be the result if you check the Use data whitening checkbox:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

If you overwrite the PKT_CRC_CONFIG.CRC_SEED field in the radio_config.h the 4byte CRC will be calculated correctly and received by the EFR32 as well:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0xba 0x94 0x5f 0x14}}

Use the EZRadioPRO as receiver

You should configure the same payload on the EFR32 by the following commands to be compliant with the 802.15.4g bidirectional packet example's default payload:

settxlength 5
setTxPayload 0 0x08 0xA0 0x02 0x00 0x6A

With this payload the 2byte CRC will be applied with no whitening, and the LEDs will light up on the EZRadioPRO development board even if only the bit endianness bug was addressed.

Also, the packet will be received correctly if the whitening is enabled on the EFR32:

setTxPayload 0 0x18 0xA0 0x02 0x00 0x6A

If you don't correct the 4bytes CRC calculator's seed this packet won't be received, nor with enabled whitening:

setTxPayload 0 0x00 0xE0 0x02 0x00 0x6A

or

setTxPayload 0 0x10 0xE0 0x02 0x00 0x6A

Summary

In this article we introduced two bugs found in the 802.15.4g bidirectional packet example and the workaround on how to deal with them. Also a minimal test guide had been introduced in order to show how can we validate our CRC, whitening and payload configuration for the 802.15.4g standard.

 

EZRadioPRO devices are designed to be compliant with 802.15.4g standard (subGHz FSK) configured via the Wireless Development Suite (WDS) as per the datasheets (Si4467/68, Si4460/1/3/4). However the provided example does not configure the devices perfectly, there are two bugs which should be addressed by the user for now.

We highly recommend to read section 10.10 in AN633: Programming Guide for EZRadioPRO® Si4x6x Devices, before going further.

If you just download the example with the same PHY on two development boards the receiver won't send the ACK packet back as it is expected.

Note: the example runs on Si4467 and Si4468 with the regular (legacy) boot mode as well.

The bit endianness of the payload

The 802.15.4g standard defines the bit order to LSB first everywhere except the length field (within the PHR configured as Field 1) which must be in MSB first order (see our article about the 802.15.4 standard on RAIL).

The example defines the Data bit order in MSB first by default for all payload fields as it is depicted in the following picture.

You should set it to LSB first since the application is responsible for swapping the bits on Field 1 whenever it is needed (where it loads the TX FIFO, or reads out the RX FIFO).

Therefore the PHR parsing will fail expecting more or less payload bytes than the transmitter actually sends (not to mention that it will mix up the whitening and CRC configurations too).

The 4byte CRC seed

Though, as long as the bit endianness configured correctly (and the transmitted/expected Field contents matches) the two radio boards can communicate with each other and the receiver will always send an ACK packet back regardless of the transmitter's configuration (whether it uses data whitening or not and whether the 2 or the 4 bytes long CRC will be transmitted), the devices will not be compliant with the standard: the 4bytes CRC will be miscalculated due to it is using '0' seed, instead of the '1's (see the referred article above).

Unfortunately this bug cannot be solved by using the WDS only, you should modify the generated radio_config.h file by hand. According to the API docs the PKT_CRC_CONFIG.CRC_SEED bitfield is responsible for this configuration. Modify the property's value from 0x57 to 0xD7.

Testing the example against an EFR32 development kit

Prepare the EFR32

Build a RAILTest application, load it onto any EFR32 development kit and issue the following commands in this order (see UG409: RAILTest User's Guide for reference on the commands):

rx 0
config863Mhz802154
enable802154 rx 100 192 1000
set802154g 0xFF
setchannel 128
setPromiscuousMode 1
setrxoptions 0x03
rx 1

Prepare the EZRadioPRO

Load the example config attached to this article (find at the bottom of this page) on any development kit with a revC or revA radio. Note that the Base frequency field had been overwritten to 863.25MHz and the 100kbps 2FSK config had been selected.

Use EZRadioPRO as transmitter

If you miss to configure the EZRadioPRO to LSB first order, sending a packet will not be received by the EFR32 at all.

Correct the field bit endianness then send a packet by the EZRadioPRO.

The EFR32 will print out the following line on the command line:

Note: pay attention to how the payload's length (len:) and its first byte changes with the configuration's changes!

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x08 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

If you enable whitening on the EZRadioPRO only one bit will differ in the received payload:

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x18 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

Now disable data whitening and check Transmit Primary CRC (IEEE 32-bit) checkbox. If you transmit a packet this line will appear on the console:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x00 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

You might have guessed what will be the result if you check the Use data whitening checkbox:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

If you overwrite the PKT_CRC_CONFIG.CRC_SEED field in the radio_config.h the 4byte CRC will be calculated correctly and received by the EFR32 as well:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0xba 0x94 0x5f 0x14}}

Use the EZRadioPRO as receiver

You should configure the same payload on the EFR32 by the following commands to be compliant with the 802.15.4g bidirectional packet example's default payload:

settxlength 5
setTxPayload 0 0x08 0xA0 0x02 0x00 0x6A

With this payload the 2byte CRC will be applied with no whitening, and the LEDs will light up on the EZRadioPRO development board even if only the bit endianness bug was addressed.

Also, the packet will be received correctly if the whitening is enabled on the EFR32:

setTxPayload 0 0x18 0xA0 0x02 0x00 0x6A

If you don't correct the 4bytes CRC calculator's seed this packet won't be received, nor with enabled whitening:

setTxPayload 0 0x00 0xE0 0x02 0x00 0x6A

or

setTxPayload 0 0x10 0xE0 0x02 0x00 0x6A

Summary

In this article we introduced two bugs found in the 802.15.4g bidirectional packet example and the workaround on how to deal with them. Also a minimal test guide had been introduced in order to show how can we validate our CRC, whitening and payload configuration for the 802.15.4g standard.

 

EZRadioPRO devices are designed to be compliant with 802.15.4g standard (subGHz FSK) configured via the Wireless Development Suite (WDS) as per the datasheets (Si4467/68, Si4460/1/3/4). However the provided example does not configure the devices perfectly, there are two bugs which should be addressed by the user for now.

We highly recommend to read section 10.10 in AN633: Programming Guide for EZRadioPRO® Si4x6x Devices, before going further.

If you just download the example with the same PHY on two development boards the receiver won't send the ACK packet back as it is expected.

Note: the example runs on Si4467 and Si4468 with the regular (legacy) boot mode as well.

The bit endianness of the payload

The 802.15.4g standard defines the bit order to LSB first everywhere except the length field (within the PHR configured as Field 1) which must be in MSB first order (see our article about the 802.15.4 standard on RAIL).

The example defines the Data bit order in MSB first by default for all payload fields as it is depicted in the following picture.

You should set it to LSB first since the application is responsible for swapping the bits on Field 1 whenever it is needed (where it loads the TX FIFO, or reads out the RX FIFO).

Therefore the PHR parsing will fail expecting more or less payload bytes than the transmitter actually sends (not to mention that it will mix up the whitening and CRC configurations too).

The 4byte CRC seed

Though, as long as the bit endianness configured correctly (and the transmitted/expected Field contents matches) the two radio boards can communicate with each other and the receiver will always send an ACK packet back regardless of the transmitter's configuration (whether it uses data whitening or not and whether the 2 or the 4 bytes long CRC will be transmitted), the devices will not be compliant with the standard: the 4bytes CRC will be miscalculated due to it is using '0' seed, instead of the '1's (see the referred article above).

Unfortunately this bug cannot be solved by using the WDS only, you should modify the generated radio_config.h file by hand. According to the API docs the PKT_CRC_CONFIG.CRC_SEED bitfield is responsible for this configuration. Modify the property's value from 0x57 to 0xD7.

Testing the example against an EFR32 development kit

Prepare the EFR32

Build a RAILTest application, load it onto any EFR32 development kit and issue the following commands in this order (see UG409: RAILTest User's Guide for reference on the commands):

rx 0
config863Mhz802154
enable802154 rx 100 192 1000
set802154g 0xFF
setchannel 128
setPromiscuousMode 1
setrxoptions 0x03
rx 1

Prepare the EZRadioPRO

Load the example config attached to this article (find at the bottom of this page) on any development kit with a revC or revA radio. Note that the Base frequency field had been overwritten to 863.25MHz and the 100kbps 2FSK config had been selected.

Use EZRadioPRO as transmitter

If you miss to configure the EZRadioPRO to LSB first order, sending a packet will not be received by the EFR32 at all.

Correct the field bit endianness then send a packet by the EZRadioPRO.

The EFR32 will print out the following line on the command line:

Note: pay attention to how the payload's length (len:) and its first byte changes with the configuration's changes!

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x08 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

If you enable whitening on the EZRadioPRO only one bit will differ in the received payload:

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x18 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

Now disable data whitening and check Transmit Primary CRC (IEEE 32-bit) checkbox. If you transmit a packet this line will appear on the console:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x00 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

You might have guessed what will be the result if you check the Use data whitening checkbox:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

If you overwrite the PKT_CRC_CONFIG.CRC_SEED field in the radio_config.h the 4byte CRC will be calculated correctly and received by the EFR32 as well:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0xba 0x94 0x5f 0x14}}

Use the EZRadioPRO as receiver

You should configure the same payload on the EFR32 by the following commands to be compliant with the 802.15.4g bidirectional packet example's default payload:

settxlength 5
setTxPayload 0 0x08 0xA0 0x02 0x00 0x6A

With this payload the 2byte CRC will be applied with no whitening, and the LEDs will light up on the EZRadioPRO development board even if only the bit endianness bug was addressed.

Also, the packet will be received correctly if the whitening is enabled on the EFR32:

setTxPayload 0 0x18 0xA0 0x02 0x00 0x6A

If you don't correct the 4bytes CRC calculator's seed this packet won't be received, nor with enabled whitening:

setTxPayload 0 0x00 0xE0 0x02 0x00 0x6A

or

setTxPayload 0 0x10 0xE0 0x02 0x00 0x6A

Summary

In this article we introduced two bugs found in the 802.15.4g bidirectional packet example and the workaround on how to deal with them. Also a minimal test guide had been introduced in order to show how can we validate our CRC, whitening and payload configuration for the 802.15.4g standard.

 

EZRadioPRO devices are designed to be compliant with 802.15.4g standard (subGHz FSK) configured via the Wireless Development Suite (WDS) as per the datasheets (Si4467/68, Si4460/1/3/4). However the provided example does not configure the devices perfectly, there are two bugs which should be addressed by the user for now.

We highly recommend to read section 10.10 in AN633: Programming Guide for EZRadioPRO® Si4x6x Devices, before going further.

If you just download the example with the same PHY on two development boards the receiver won't send the ACK packet back as it is expected.

Note: the example runs on Si4467 and Si4468 with the regular (legacy) boot mode as well.

The bit endianness of the payload

The 802.15.4g standard defines the bit order to LSB first everywhere except the length field (within the PHR configured as Field 1) which must be in MSB first order (see our article about the 802.15.4 standard on RAIL).

The example defines the Data bit order in MSB first by default for all payload fields as it is depicted in the following picture.

You should set it to LSB first since the application is responsible for swapping the bits on Field 1 whenever it is needed (where it loads the TX FIFO, or reads out the RX FIFO).

Therefore the PHR parsing will fail expecting more or less payload bytes than the transmitter actually sends (not to mention that it will mix up the whitening and CRC configurations too).

The 4byte CRC seed

Though, as long as the bit endianness configured correctly (and the transmitted/expected Field contents matches) the two radio boards can communicate with each other and the receiver will always send an ACK packet back regardless of the transmitter's configuration (whether it uses data whitening or not and whether the 2 or the 4 bytes long CRC will be transmitted), the devices will not be compliant with the standard: the 4bytes CRC will be miscalculated due to it is using '0' seed, instead of the '1's (see the referred article above).

Unfortunately this bug cannot be solved by using the WDS only, you should modify the generated radio_config.h file by hand. According to the API docs the PKT_CRC_CONFIG.CRC_SEED bitfield is responsible for this configuration. Modify the property's value from 0x57 to 0xD7.

Testing the example against an EFR32 development kit

Prepare the EFR32

Build a RAILTest application, load it onto any EFR32 development kit and issue the following commands in this order (see UG409: RAILTest User's Guide for reference on the commands):

rx 0
config863Mhz802154
enable802154 rx 100 192 1000
set802154g 0xFF
setchannel 128
setPromiscuousMode 1
setrxoptions 0x03
rx 1

Prepare the EZRadioPRO

Load the example config attached to this article (find at the bottom of this page) on any development kit with a revC or revA radio. Note that the Base frequency field had been overwritten to 863.25MHz and the 100kbps 2FSK config had been selected.

Use EZRadioPRO as transmitter

If you miss to configure the EZRadioPRO to LSB first order, sending a packet will not be received by the EFR32 at all.

Correct the field bit endianness then send a packet by the EZRadioPRO.

The EFR32 will print out the following line on the command line:

Note: pay attention to how the payload's length (len:) and its first byte changes with the configuration's changes!

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x08 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

If you enable whitening on the EZRadioPRO only one bit will differ in the received payload:

{{(rxPacket)}{len:7}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x18 0xa0 0x02 0x00 0x6a 0xe4 0x79}}

Now disable data whitening and check Transmit Primary CRC (IEEE 32-bit) checkbox. If you transmit a packet this line will appear on the console:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x00 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

You might have guessed what will be the result if you check the Use data whitening checkbox:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Fail}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0x59 0xb4 0xe4 0xca}}

If you overwrite the PKT_CRC_CONFIG.CRC_SEED field in the radio_config.h the 4byte CRC will be calculated correctly and received by the EFR32 as well:

{{(rxPacket)}{len:9}{timeUs:xxxxx}{timePos:4}{crc:Pass}{rssi:x}{lqi:xxx}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{ed154:255}{lqi154:255}{payload: 0x10 0xe0 0x02 0x00 0x6a 0xba 0x94 0x5f 0x14}}

Use the EZRadioPRO as receiver

You should configure the same payload on the EFR32 by the following commands to be compliant with the 802.15.4g bidirectional packet example's default payload:

settxlength 5
setTxPayload 0 0x08 0xA0 0x02 0x00 0x6A

With this payload the 2byte CRC will be applied with no whitening, and the LEDs will light up on the EZRadioPRO development board even if only the bit endianness bug was addressed.

Also, the packet will be received correctly if the whitening is enabled on the EFR32:

setTxPayload 0 0x18 0xA0 0x02 0x00 0x6A

If you don't correct the 4bytes CRC calculator's seed this packet won't be received, nor with enabled whitening:

setTxPayload 0 0x00 0xE0 0x02 0x00 0x6A

or

setTxPayload 0 0x10 0xE0 0x02 0x00 0x6A

Summary

In this article we introduced two bugs found in the 802.15.4g bidirectional packet example and the workaround on how to deal with them. Also a minimal test guide had been introduced in order to show how can we validate our CRC, whitening and payload configuration for the 802.15.4g standard.

 

Hi Yazhou,

The Standard packet TX and Standard packet RX applications doesn't support packet configuration on the GUI (this is where their names come from), though you can modify the generated radio config array by hand. However, for custom packet configuration use the Custom packet TX and RX examples, where you can customize the Preamble, sync word, payload fields as well as the CRC configuration.

On sync word selection see this article, and consult with the device's datasheet for the recommended preamble length configuration.

Best Regards,
Bence

Hi Issac,

It is oversampled, but as far as I know it is not indicated in the log file nor can be precisely calculated by the radio configuration GUI's inputs. Therefore the oversampling ratio should be measured. I use to calculate it by measuring the time between two consecutive RAIL_EVENT_RX_FIFO_ALMOST_FULL events; the measured time should be divided by the number of bytes read out from the RX FIFO (use RAIL_ReadRxFifo instead of clearing the FIFO by the RAIL_ResetFifo). For more accurate result you can either increase the RX FIFO's length or calculate it over multiple radio events.

The representation of the RX_DEMOD_DATA is 2's complement, so it might be negative.

Best Regards,
Bence
 

Hi Stefan,

Sorry, last time I didn't know that direct mode isn't supported on EFR32 Series 2 devices yet. Unfortunately the API documentation does not mention it, but it can be concluded by the fact that the part you have does not have PC10 and PC11 pins. Although, direct mode does not work on the target, synchronous MODEM.DOUT signal can be assigned to any GPIO on portA or portB (see datasheet) which puts the payload bits out on the selected pin in case of RX, and the whole packet (including preamble, sync word and CRC bits as well) on the transmitter; but I suspect, this isn't your goal.

Note that EXP_HEADER denotes pin header on WSTK not on the Thunderboard.

Best Regards,
Bence

Hi Su,

If a packet had been received without any error (including abort by software, CRC error, frame length decoding error, filtering error, etc.) the RAIL_EVENT_RX_PACKET_RECEIVED event will be raised. It can be also triggered by receiving a packet with CRC error if the RAIL_RX_OPTION_IGNORE_CRC_ERRORS option is in effect. This event is counted in counters.receive and printed out as RxCount:%u.

Packet received with CRC errors are counted in counters.frameError and printed out as FrameErrors:%u by default (the RAIL_EVENT_RX_FRAME_ERROR will be triggered). Once the RAIL_RX_OPTION_IGNORE_CRC_ERRORS option is activated packet with CRC errors will no longer raise the frame error event.

Best Regards,
Bence

Andrey,

Sorry for the late reply.

I wouldn't say that I don't believe your observation, but we should investigate the root cause of this issue, which can be in the hardware design as well as in the software or even in the measurement setup. The POR should reset all the register contents of Si446x. I never heard that the radio stored previous state of any register after the POR had been executed properly. Additionally you should check whether the POR timings regarding the VDD's level are met according to the specification (see Table 10 of the datasheet).

1. Could you confirm that you set up the exact same configuration in each cases? The consumption may differ with the GLOBAL_CONFIG.POWER_MODE.
2. From where did you raise the 7 mA current consumption expectation for the receive state of the Si446x? Maybe you measured the I_Tune_RX current first time. According to the datasheet the RX consumption should be 10 mA at least.

3. Please confirm that the radio is in RX state for sure observing the RX_STATE signal on a  GPIO or issuing REQUEST_DEVICE_STATE command.
4. Is it possible that you measured current consumption with averaging over a long period?
5. Are you aware of the device's LDC (Low duty cycle) capability? I think It may be worth to get more familiar with this concept as with it you may save more energy (however, I don't know much about the details of your project).

If you share your radio configuration, I would measure the consumption on a development board.

Best Regards,
Bence