RSSI (Received Signal Strength Indicator) measurement is continuously running and the current result is stored in a HW register after the Rx is started. This register gets updated after each measurement window.

When the Rx is started the first RSSI result is not available immediately. The first RSSI acquisition time can be split into three parts:

1. State transition time to Rx – this depends on the starting state
2. Signal propagation through the Rx chain
3. RSSI measurement window length

As stated 1) depends on the starting state and also on a RAIL configuration that explicitly sets state transition times. More on this you can read here: RAIL Tutorial: Time, timestamping and Scheduling

Contribution 2) depends on the PHY configuration (and varies with PHY configuration). This time is mainly driven by the delay through the channel filter so as a rule of thumb it scales inversely proportionally with the configured channel bandwidth. For a typical FSK modulation where the channel filter roughly equals the signal bandwidth itself this time is ~ 3-4 Ts, where Ts is the symbol time.

RSSI measurement is held off for some amount of time to make sure no false RSSI readings are reported due to partial signal propagation. This time is configurable on the radio configurator advanced AGC section (AGC Settling Delay). Note that this parameters primarily adjusts the AGC (Automatic Gain Control) time schedule so it is recommended not to be tampered with as the AGC may go unstable or converge slowly.

Also note that this time period may be extended (by as much as 2x) for gain adjustments in the front end. It means that this time period depends on the signal level presented to the Rx. Typically you get the fastest response time around sensitivity level and may experience longer acquisition times above ~ sensitivity + 20 dB.

Contribution 3) is the RSSI measurement itself. Once the “blanking” period explained in point2) expires the first RSSI measurement commences. The measurement window through which the RSSI samples are averaged can be set on the configurator GUI with control RSSI Update Period. (Measurement and update period = 2^RSSI Update Period [Ts].) This control sets the length of the measurement window as well as the measurement update period. A result is reported after each back to back measurement window and stored in a HW register. Each result represents the average reading of the preceding measurement window. The HW register stores an invalid value until the 1st result gets written into it. (This is the invalid value RAIL also reports if a measurement results is not available, i.e., the device is not in Rx state or a valid result has not arrived yet in Rx state.)

As an example take a 100 kbps 2GFSK PHY with 50 kHz deviation and a 200 kHz channel filter with an RSSI Update Period of 1 meaning a 2Ts window. Suppose the starting state is idle. The time contributions will have the following values

1. 100 us  - the shortest programmable consistent** state transition time
2. ~ 3Ts = 30 us  - assuming close to sensitivity level signals
3. 2Ts = 20 us

** Note that the state transition time may also be configured to as fast as possible: from idle to Rx this typically means 60-80 us. In this mode the state transition time is not consistent. i.e., it varies from Rx start to Rx start. The shortest consistent state transition time from idle state to Rx state is 100 us.  Look for RAIL_StateTiming_t for more details.

The sum is ~ 150 us most of which is taken up by the state transition itself. If we take a much lower DR PHY as an example you may see that the RSSI acquisition time will mostly be driven by the symbol time.

If you are not happy with the RSSI acquisition time as the whole operation burns too much energy here is the tricks (and tradeoffs) you may apply to make it faster. As the state transition time is a given these will have the most benefits at low data rate PHYs.

1. Select the minimum measurement window of RSSI Update Period = 1 (measuring over 2Ts).
2. Open up the channel bandwidth. This will make the blanking time shorter at the expense of worse selectivity. In a channelized system you may not have much room here.
3. Increase the DR while keeping the same channel bandwidth. This will make the RSSI measurement time shorter at the price of less accurate readings. You must force the channel bandwidth to achieve this otherwise the calculator will make it automatically wider.
4. If your application can tolerate inconsistent state transition times opt for the as fast as possible option in RAIL_StateTiming_t.

Below are some explanations of the RAIL RSSI related APIs:

RAIL_GetRssi(): When this function is called it simply returns the current value stored in the HW RSSI register. It does not initiate a new measurement. It returns an invalid value if the HW register has an invalid value in it as explained above.

RAIL_StartAverageRssi() .This function can only be called from idle state. This function makes the radio transition to Rx state and measure one RSSI value with the exact measurement window given to it. This function reconfigures the radio to align the HW RSSI measurement window to the desired averaging time. This means that during the measurement packets cannot be received. To this end signal detection is disabled during the operation of this function. Once the RSSI measurement is acquired the configuration is restored and the radio returns to idle state. The HW supports a finer adjustment on the measurement window which is not exposed on the configurator GUI – this function makes use of this method to match the desired measurement window as accurate as possible from HW. The resolution of window adjustment is ~ Ts/10 – Ts/5. So taking the 100 kbps example the resolution will be between 1us – 2us. The exact resolution depends on the PHY configuration. Note that based on the operations of this API there will be a maximum time limit (dependent on the PHY) the API is capable of supporting. If a longer time period is requested RAIL_STATUS_INVALID_PARAMETER is returned.

EFR32xG1 based radio boards use 1.0uF capacitor at DC-DC output by default, but the recommended value is 4.7uF for new designs. The EFR32xG1 software defaults to using 1.0 µF, use of 4.7 µF on EFR32xG1 requires modifications in the software. This KBA provides details how to do this modification.

The following methods are valid for Flex SDK 2.4. For other SDK versions, the folder paths or line numbers might be different.

There are 2 options to do this software modification:

1. Look for the following file in your computer: "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\platform\emlib\inc\em_emu.h"

Lines 725-752 are responsible for choosing if 1uF or 4.7uF capacitor is present at the DC-DC output. By default, the software uses 1uF for EFR32xG1 series, in order to change that to 4.7uF the following modification should be made:

Swap "emuDcdcLnCompCtrl_1u0F" (line 737) with "emuDcdcLnCompCtrl_4u7F" (line 751). This will make 4.7uF the default value.

2. Place line "#define _SILICON_LABS_GECKO_INTERNAL_SDID_80" in a comment section in the part specific header file (e.g. "efr32mg1p233f256gm48.h"). You can find this file at "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\platform\Device\SiliconLabs\EFR32xG1x\Include" folder.

How can I calculate the occupied bandwidth for an FSK modulated signal?

Carson’s Rule to determine the BW for an FSK signal:

For 2FSK / 2GFSK modulation the symbol rate is equal to the data rate, and unlike 4FSK / 4GFSK modulation there is only one deviation. This way, the formula can be simplified to the following form:

4FSK / 4GFSK modulation has inner and outer deviation parameters, the connection between them can be described as the following:

This way, the OBW for 4FSK / 4GFSK:

Question:  I've been getting 'ERROR: No application properties area found in application'' when trying to generate GBL files using simplicity commander. What are the steps to add Gecko Bootloader compatibility to a project that is using the RAIL API? 

Answer: Below are the two options to create the .gbl file for RAIL project without errors.

Option 1: Force GBL creation with default application properties using Simplicity commander. Commander will now insert a default struct into the GBL file(not s37 application file)

More information about force command can be found in the UG162 Simplicity Commander Reference Guide

Option 2: To enable the security features, we must add application properties struct to the RAIL project

When using Simplicity Studio v4 with ARM GCC toolchain copy application_properties.c file to the project, now add the path to application_properties.h(include in build) and change the APP_TYPE to MCU from Bluetooth App.

Location of application_properties.c file for gecko SDK v2.4 - C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\bluetooth\appbuilder\sample-apps\common

then, add "KEEP(*(.application_properties))"  to the linker file(.ld) as below. This will enable the access to ApplicationProperties.

SECTIONS
{
.text :
{
KEEP(*(.vectors))
__Vectors_End = .;
__Vectors_Size = __Vectors_End - __Vectors;
__end__ = .;
KEEP(*(.application_properties))

*(.text*)

KEEP(*(.init))
KEEP(*(.fini))

Now generate .gbl file using simplicity commander. More information about using simplicity commander can be found in the UG162 Simplicity Commander Reference Guide

        所有RAIL示例项目都依赖于UART，因为retargetserial.c 是由HAL library插件自动添加到项目中的，就连一些根本没有用到UART的项目(如Simple TRX )都依赖于UART。

        在AppBuilder 或Hardware Configurator 中禁用UART及所有串口的相关选项(如下图)，都不能解除对UART的依赖。

        其根本原因是retargetserial.c 包含了retargetserialhalconfig.h ，如果hal-config.h中没有有效UART定义的话就会有触发#error "Invalid UART type"。编译就会报如下(或相似)的错误:

        解决方法是从项目中移除retargetserial.c (位于hal-efr32目录) 。移除后即可成功编译了。

        有一点要注意，通过AppBuilder重新生成项目后,一定要记得重新移除这个文件。

        英文原文：https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/11/10/remove_uart_dependen-tRaj

All Silicon Labs EFR32 radio board equipped with external SPI flash memory. Although, the standby current consumption of these devices are low some application need to eliminate even this amount of current consumption to reach extremely low power consumption (the achievable current consumption of a Connect based application exploiting Connect's lowest power mode (EM2) is ~2-4uA)). This mode of the SPI flash called "Deep Power Down" mode, which is available by sending the 0xB9 command to the flash (on the SPI interface).

First, the SPI Flash plugin must be enabled in AppBuilder (Plugins tab):

Don't forget to re-generate project files.

Beside enabling the SPI Flash plugin it is necessary to add the initialization and deep power down command to the project by calling the two API functions below:

• halEepromInit()
• halEepromShutdown()

It is practical to call these functions at startup of the application, for example from emberAfMainTickCallback() which located in flex-callbacks.c like in the example below:

void emberAfMainInitCallback(void)
{
  emberAfCorePrintln("INIT: %p", EMBER_AF_DEVICE_NAME);
  emberAfCorePrintln("\n%p>", EMBER_AF_DEVICE_NAME);

  halEepromInit();
  halEepromShutdown();

  emberNetworkInit();
}

After applying the above the current consumption should be reduced by ~8-10uA.

In some cases customer wants to build a project directly by IAR Embedded WorkBench. Since the Simplicity Studio generated IAR project files may have some mistakes and may not be able to fix by Simplicity Studio design team in a short time, here is a workaround solution.

Take railtest_efr32 project as an example, after we generate it with IAR toolchain in Simplicity Studio, we should also check if it can pass compiling/building process in Simplicity Studio with IAR toolchain firstly. It is supposed the building with SS should be OK.

Then open the project railtest_efr32.eww with IAR workbench directly. The compile may fail, we found below errors. Test on Flex SDK 2.4.1.0. If you use Flex SDK 2.3.1.0, you may only have issue 2.

1, File link mistake.

2, EFR32MG12P332F1024GL125.icf cannot found.

3, Files is not included.

If you also found it failed to build the project, you could try below modifications, after doing these 2 steps, the IAR Embedded WorkBench compiling was supposed to be successful.

1, In file railtest_efr32.ewp. Make the files link correct and entirety.

Change the line

$PROJ_DIR$\..\railapp\railapp_antenna.c

to

$PROJ_DIR$\railapp_antenna.c

Add gpio_ci.c and zwave_ci.c into the project.

After changed, it will look like below:

2, Browse to Options-->Linker-->Config-->Linker configuration file, Uncheck “override default” option. Make the icf link correct.

After all the changing, you will can compile success and get a screen like this:

    现有的EFR32无线小壁虎系列sub-GHz频段参考匹配网络中，使用所谓的直接相连的拓扑结构，即Tx和Rx通路直接连在一起而不使用外部的射频开关。为了在参考匹配网络中插入SAW 滤波器/ RF开关或 FEM模块，需要将Tx通路与Rx通路分离开来，这是因为不建议在Tx通路使用SAW滤波器，具体原因如下： 

- SAW滤波器相当大的插损会降低期望的功率效率，

- SAW滤波器典型应用是低功率等级，也即会产生功率限制问题，

- SAW滤波器通常对高频率信号（也即RF谐波成分）衰减相对较弱，因此总是推荐使用分立LPF。

    EFR32带SAW滤波器的推荐原理图结构如下：

- Tx通路的匹配保持现有的参考匹配电路，推荐匹配元件值已在AN923中说明，或参考现在的参考设计。

- LPF低通滤波器部分可以基于功率水平，谐波抑制的要求来改变。

- Rx通路匹配利用一个标准的4元件分立巴伦匹配网络，相应的在AN643里面有详细说明。仿真元器件值如下表所示。

- RF开关被用来分开TX和RX通路的匹配，这两个通路被连接到相同的天线端口。

- SAW滤波器独自的匹配网络并非必须的 (LW1, LW2, CW1, CW2, CW3 and CW4)，具体请参考给定SAW滤波器规格书。

    对于只用RF开关的设计，上述原理图是可用的，不焊接SAW滤波器及其匹配元件即可。但是，推荐在4元件离散巴伦单端端口和RF开关之间串入旁路/DC隔离电容。

    下图所示是一典型的带FEM的设计，在这里，RF开关可被FEM取代。SAW滤波器在下图没显示出来，但如果使用的话，可将其应用在FEM的RX端口上。在FEM（带LNA）设计中推荐SAW滤波器放在FEM的分立RX端口上，并确保在接收通路上RF模块的顺序如下：天线 --> 分立 LPF(因TX谐波抑制需要) --> SAW滤波器 --> FEM LNA --> 4元件分立巴伦匹配网络 --> EFR32 LNA。这种方法可确保即使在嘈杂的环境中也有强悍的接收性能。在无噪声环境中，如果将SAW滤波器置于4元件匹配巴伦和FEM的LNA之间，则可以实现更好的链路预算。芯科建议使用上述方法，因为将LNA引入接收器路径一般会产生更好的灵敏度，但会导致更差的线性和阻塞性能。如果可以保证无噪声环境，那么SAW滤波器在设计中是不必要的。

    同样，对于在Tx通路上的分立匹配方案（也即去掉EFR32和FEM之间的外部陶瓷巴伦），请参考以下链接的KBA：

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/11/06/discrete_matchingso-IKyv

  Connect 支持NCP(网络协处理器)工作模式(通过UART接口)。这种情况下应用与协议栈分别置于不同的设备上。协议栈运行在EFR32设备(target)上，而应用运行在另一MCU/CPU(host)。

  在当前的应用，当NCP有一些打印操作后，通信会宕在目标NCP侧。

  为避免这种问题，应在ncp-main/ncp-main.c中，在ThreadMain(NULL);这一行前加上emberSerialWaitSend(APP_SERIAL);

如下：

int MAIN(void)
{
#if defined(__CONNECT_CONFIG__) && !defined(CORTEXM3_EMBER_MICRO)
  emberAfMain();
#endif

  halInit();
  INTERRUPTS_ON();
  emberSerialInit((uint8_t)APP_SERIAL, (SerialBaudRate)APP_BAUD_RATE, (SerialParity)PARITY_NONE, 1);

  emberSerialPrintfLine(APP_SERIAL, "%s-app ready", emAppName);
  emberSerialPrintfLine(APP_SERIAL,
                        "channel %u (0x%x), node id 0x%2x, pan id 0x%2x",
                        emberGetRadioChannel(), emberGetRadioChannel(),
                        emberGetNodeId(), emberGetPanId());
  emberSerialPrintf(APP_SERIAL, "%s> ", emAppName);

  emberSerialWaitSend(APP_SERIAL);

  // Call the main NCP thread. This should never return
  ncpThreadMain(NULL);

  // should never hit this, but here to suppress compiler warning
  return 0;
}