This question is a duplicate of this topic, therefore we would like to answer there.

Best Regards,
Bence

Hi Gordon,

I found a typo in your OOK configuration (I'm not sure if it cause a critical issue, but you should correct it):

#define RF_MODEM_AGC_CONTROL_1 0x11, 0x20, 0x01, 0x35, 0x622 // (instead of 0x62)

WDS generated the same config for me as you got (except that mistake), and it works perfectly (pull up GPIO0 to see CW signal). Can you double check whether your device can transmit OOK signal with the attached config?

Best Regards,
Bence

Hi Mikel,

This issue had been fixed within the latest SDK release, please update it before creating a new project.

Best Regards,
Bence

Hi Thibault,

I think you missed to generate the project. Open the .isc file and click on the Generate button. It will add more files to your project and it will resolve the inclusion errors.

To get further information on how to work with RAIL examples see QSG138's section 4.3.

Best Regards,
Bence

Shiying,

Si4455 does support LDC, though it cannot be configured at runtime, this means that the duration of the sleep and RX period are configured on startup, and it cannot be changed later. For further references see AN692 and the WDS example (LDC RX).

Best Regards,
Bence

Ashish,

Sorry, disregard my previous answer. Those are by default enabled JTAG pins. See it in the reference manual:

24.3.9.1 JTAG Debug Connection
The JTAG Debug Port is a fixed location resource connected directly to specific GPIO pins. Refer to the Alternate Function Table in the
device Datasheet for the location of the JTAG signals. By default TMS, TCK, TDO, and TDI pin connections are enabled with internal
pull up, pull down, no pull, and pull up resistors, respectively. It is possible to disable these pin connections (and disable the pull resistors)
by setting the SWDIOTMSPEN, SWCLKTCKPEN, TDOPEN, and TDIPEN bits in GPIO_DEBUGROUTEPEN to 0.

But be very careful when clearing these bits, reference manual also exposes:

WARNING: When the pin is disabled, the device can no longer be accessed by a debugger. A reset will set the pin back to a default state as enabled. If you disable this pin, make sure you have at least a 3 second timeout at the start of your program code before you disable the pin. This way, the debugger will have time to halt the device after a reset before the pin is disabled.

Best Regards,
Bence

Hi Ashish,

Could you share please more information about this issue?
- Which example application are you using?
- Can you confirm, the GPIO clock is running, and the peripheral is enabled? (Have you called the the following function before alternating the output:

CMU_ClockEnable(cmuClock_GPIO, true);

?)
- Is this issue occurs only on PA01 and PA02?
- Do you have a custom design and not a Silabs radio board, right? If it is custom, can you check whether PA01 is pulled down or PA02 is pulled high?

You can find in this GitHub repository a lot of peripheral examples even for EFRMG21 devices. This one will show how to configure GPIOs as input or for output.

Best Regards,
Bence

Shiying,

I should highlight it again: 

CURR_RSSI will store valid values in 4 Tb after entering RX_STATE

It means, that you should wait ~6.7 ms at least to acquire correct RSSI samples as the data rate is 600 bps. But after you've got the first valid sample you can read out the following samples per ~1.7 ms.

I don't know for what purpose you need the CCA functionality, maybe we can find a better solution (increasing the datarate will result in faster "RSSI stabilization"), if you can share more about your project. Do you want to implement LDC or channel scanning feature? Are you trying to decrease the receiver's power consumption?

Best Regards,
Bence  

Hi Tony,

I think, it's a very general question, and hard to answer without knowing what are your needs in details. You have a lot of trade-off factors, which play key roles in this protocol design. such as:
- How symmetric is your network (does every node play a similar role, I mean, is the average time spent in RX or TX the same for each node)?
- Do you have a synchronous channel hopping system? It is clear for the nodes when and on which channel to listen? How much effort takes synchronizing the network? - If it is synchronous, I don't think utilizing DSA would save much energy: the major part of the power will be wasted by waiting for the transmitter, and the longer transmission periods are, the more inaccurate the matching of the RX period is, and the higher the power consumption is on the RX side. So it is much more important to schedule the reception as accurately as possible. But the synchronization process can be definitely facilitated by faster signal detection.
- How long overhead can be tolerated on the packets? If you have short messages I rather suggest to use the Master-blast LDC mode. 
- Where do you want spare more power? The higher power consumption on the TX the lower on the RX nodes, and vice versa. 

This is my personal opinion: there is no "absolute lowest power" method: there would be cases, where the implemented solution is optimal, but wasting power is an inevitable consequence of any wireless design.

Let us know, what are the requested parameters to help improve your protocol.

Best Regards,
Bence

Shiying,

1. I'm not sure, whether it is the desired state change, but you configured your device to get to sleep mode after receiving a packet. That's why the GPIO can rise up when it is configured as IN_SLEEP. If you want to stay in RX (or rather "briefly exit and then re-enter RX state") you should use the SI4455_CMD_START_RX_ARG_RXVALID_STATE_ENUM_RX enum instead of the SI4455_CMD_START_RX_ARG_RXTIMEOUT_STATE_ENUM_SLEEP. Furthermore, you may try to lower RSSI_THRESHOLD value, I think -30 dBm is fairly high, but I don't know on what power level you need to trigger with the GPIO.

2. You shouldn't reach those properties on EZRadio devices, only on EZRadioPROs. I recommend to create radio configuration through WDS, where you can modify the RSSI threshold's value as well. Note that the CURR_RSSI updates per 1 Tb.

Best Regards,
Bence