This tutorial builds on the following tutorials:

• RAIL Tutorial 1: Introduction and init
• RAIL Tutorial 2: Transmitting a Packet
• RAIL Tutorial 3: Event Handling
• RAIL Tutorial 4: Combining Transmit and Receive

Please read them first if you haven't.

You can find other tutorials on the Table of Contents site.

Note that this tutorial is slightly outdated in Studio v5, since PA calibration is performed by the RAIL Util components by default, and some calibration configuration is performed in there as well. The article is accurate but will be extended in the near future on how calibrations can be simply enabled using the RAIL Util components.

To reach the maximum performance of the radio, you should enable and implement calibrations. In this tutorial, we will talk about the details on how to implement calibrations and when can they be avoided.

Enable All Calibrations

Generally, you should enable all calibrations. They do have some drawbacks, but they can be avoided in some cases. To enable everything, call the following during init:

RAIL_EnablePaCal(true); //make sure you call this before RAIL_ConfigTxPower()
RAIL_ConfigCal(railHandle, RAIL_CAL_ALL);
RAIL_ConfigEvents(railHandle, RAIL_EVENT_CAL_NEEDED, RAIL_EVENT_CAL_NEEDED);

This will enable the calibration of the PA during its initialization and enable the calibration event. To perform the runtime calibration when requested, you should handle the calibration event:

if( events & RAIL_EVENT_CAL_NEEDED ){
  RAIL_Calibrate(railHandle, NULL, RAIL_CAL_ALL_PENDING);
}

In the following sections, we’ll look into the 3 calibrations available on EFR32.

PA Calibration

Why Is It Needed?

The Power Amplifier (PA) has some part-to-part variations at low-power levels. To compensate this, Silicon Labs measure the PA during manufacturing and store some calibration constants on the DI page. The 2.4GHz Low Power PA is not affected.

When to Perform This Calibration?

Before calling RAIL_ConfigTxPower().

How Long Does It Take?

Virtually no time. It’s just loading some constants from the DI page, not an actual calibration.

What If I Don’t Use It?

When you set to transmit at low power, your output power might be different from part to part.

Are There Any Drawbacks?

By default, during PA ramp-up, the radio ramps the PA current to a fixed value, which always takes the same time (but results in different power output).

With calibration, the slope will be the same, but it can reach the target output power either faster or slower. To guarantee the scheduling timing, RAIL will set up the slowest ramp time as a delay for the ramp-up. This means that ramping will take slightly longer, and it might reach the top early.

Since we’re talking about microseconds here, it’s usually not an issue, unless for some reason, you need to be aware of ramping shape and time.

How to Do It?

The simplest way is the implementation above.

Temperature Calibration

Why Is It Needed?

The Voltage Controlled Oscillator (VCO) must be temperature-compensated to generate the expected frequency. This will be automatically performed when the radio enters either the Tx or Rx state from idle, but it might be needed when the radio is in Rx for a long duration with big temperature changes.

When to Perform This Calibration?

Generally speaking, when RAIL requests it through RAIL_EVENT_CAL_NEEDED. RAIL will request calibration when the temperature changes by 70 °C. In the case of EFR32xG1, it will also request calibration when crossing the 0 °C line. There’s a 5 °C hysteresis, so it won’t calibrate all the time if you’re device is around 0 °C for a long time.

How Long Does It Take?

Under 100 µs.

What If I Don’t Use It?

There’s no need for it if your device does not stay in Rx mode (without channel change), while the temperature can change by a lot.

If you don’t calibrate when requested, your received frequency might change to the point where reception will be impossible.

Are There Any Drawbacks?

It’s not possible to receive packets while the calibration is running.

How to Do It?

The simplest way is the implementation above.

Image Rejection Calibration

Also known as IR or IQ calibration.

Why Is It Needed?

The receiver fundamentally receives signals from two frequency bands: one IF (Intermediate Frequency) above the Local Oscillator (LO) frequency - wanted band, and one IF below the LO frequency - image band. Image band reception is not desired. The receiver is designed in a way that there is inherently suppression on the image band. The suppression of the image, however, can be further improved by performing an on-chip calibration. Note that the calibration does not improve receiver sensitivity, and it’s not even used for Tx, it only improves signal suppression on the image frequency in Rx mode.

When to Perform This Calibration?

Once, for each subGHz radio configuration, in the lifetime of the chip. This means it’s enough to calibrate during manufacturing, store the result, and apply it later. In fact, we do this measurement for 2.4 GHz 802.15.4 and BLE and store it in the DI page of the chip. The internal calibration process is not available on 2.4 GHz, but the stored values are quite good for any radio configuration on that band. However, we can’t provide calibration values for any possible sub-GHz radio configuration.

How Long Does It Take?

The calibration itself takes about 200 ms. Loading a stored value is just a register write, so it’s nearly instantaneous.

What If I Don’t Use It?

You will be able to receive from the image frequency. This can be harmful, for example, if the image frequency is a neighboring channel.

Are There Any Drawbacks?

Loading a stored value has no drawback. The calibration itself takes quite a long time, and it needs about 2.5 kB code memory (In Flex 2.3.0, with GCC 7.2.1).

How to Do It?

The easiest way is the automatic implementation above. RAIL will request calibration when you call RAIL_ConfigChannels. However, you can also trigger calibration manually, e.g., at boot. There are a few more details that are important in multi-phy or multiprotocol environments, we will discuss it in those tutorials.

Alternate API

If you can use a “manufacturing test” firmware to run the IR calibration and store it, and only load the value from the end-product application, you can remove the 2.5 kB codespace required by the IR calibration by using the alternate API:

if( events & RAIL_EVENT_CAL_NEEDED ){
  RAIL_CalMask_t pending = RAIL_GetPendingCal();
  if ( pending & RAIL_CAL_ONETIME_IRCAL ){
    RAIL_ApplyIrCalibration(railHandle, storedIrValue);
  } else { //if not IR, it must be temperature on EFR
    RAIL_CalibrateTemp(railHandle);
  }
}

In the manufacturing firmware, you can use RAIL_CalibrateIr() to get the IR calibration value. If you never call RAIL_Calibrate() or RAIL_CalibrateIr() in your application, the calibration code will be removed, freeing up code space.

API Introduced In This Tutorial

Functions

• RAIL_EnablePaCal()
• RAIL_ConfigCal()
• RAIL_ApplyIrCalibration()
• RAIL_CalibrateTemp()
• RAIL_CalibrateIr()

Types and enums

• RAIL_CalMask_t: (RAIL_CAL_ALL/RAIL_CAL_ALL_PENDING/RAIL_CAL_ONETIME_IRCAL/RAIL_CAL_TEMP_VCO)
• RAIL_EVENT_CAL_NEEDED