Using the PLFRCO on EFR32xG13

by <a href="http://community.silabs.com/t5/Welcome-and-Announcements/Community-Ranking-System-and-Recognition-Program/m-p/140490#U140490"><font color="#000000"><font size="2">Legend Employee</font></font> </a> tmonte on ‎06-15-2017 08:58 AM

Introduction

The EFR32xG13 devices include a new internal oscillator, the PLFRCO, or Precision Low Frequency RC Oscillator, which is a self-calibrating RC oscillator that eliminates the need for a 32.768kHz crystal.

 

The PLFRCO can be used by the Bluetooth stack as the low frequency clock source (instead of the LFXO) to time the RTCC which is used to wake-up the device on each connection interval when sleep is enabled in the stack.

 

The PLFRCO has a frequency accuracy of +/-500ppm which is within the Bluetooth specification requirements.

 

It is best suited for some BLE use cases such as applications with very constrained cost targets or board layout space, devices that maintain short connection intervals or have infrequent BLE connections as well as devices that advertise most of the time (such as iBeacon or Google Eddystone devices).

 

Selecting the PLFRCO

Using the PLFRCO requires only a few changes in InitDevice.c and one change in the Bluetooth stack configuration structure.

 

In the Bluetooth stack configuration structure the sleep clock accuracy needs to be changed to 500ppm.

 

static const gecko_configuration_t config = {
  ....
  ....
  .bluetooth.sleep_clock_accuracy = 500, // ppm
  ....
  ....
};

 

In InitDevice.c it is required to initialize the PLFRCO and select it as a clock source for the low frequency clock branches. Below is a comparison between the standard InitDevice.c and a modified version that configures PLFRCO instead of LFXO as the low frequency clock source. There’s essentially 3 steps to take:

  • Remove the LFXO related initialization code
  • Enable PLFRCO oscillator instead of LFXO
  • Change clock source for LFA, LFB and LFE to PLFRCO

code changes.png

 

Tradeoffs

The most obvious benefit of using the PLFRCO instead of the LFXO is the cost savings from not using the low frequency crystal. The drawback is that the PLFRCO increases the sleep current by up to 500nA and extends the RX receive window on the slave side at the beginning of each connection interval.

 

Sleep Current

Below are sleep current measurements on the same device with LFXO and PLFRCO where the sleep current difference is about ~280nA.

 

SLEEP_LFXO.png

Figure 1 - EFR32xG13 sleep current with LFXO

 

SLEEP_PLFRCO.png

Figure 2 - EFR32xG13 sleep current with PLFRCO

 

RX period extension

At the beginning of each connection interval the master device is the first to send out a packet. This makes it a hard requirement that the slave must be listening (in RX) in order not to loose that initial packet from the master device. The combined clock accuracy from master and slave (sum of both accuracy values in ppm) is used to calculate the moment in which the slave should wake-up to listen for the incoming packet.

 

When the accuracy is lower then the slave must wake-up earlier so there will be a longer RX receive window when using a PLFRCO compared to the LFXO due to the lower accuracy. The images below show an empty packet taken from the slave side with 1 second connection interval and 0dBm output power. When using PLFRCO the RX receive window is extended by ~250uS. The longer the connection intervals the more pronounced will be the RX window extension when compared to LFXO usage.

TX_CONN_1S_INTERVAL_LFXO.png

Figure 3 - Empty packet using LFXO

 

TX_CONN_1S_INTERVAL_PLFRCO.png

Figure 4 - Empty packet using PLFRCO

 

One final note, when the slave misses connection intervals (e.g. device was temporarily out of range or due to interference) then the RX receive window will be widened by the combined accuracy until the slave is able to catch the initial packet from the master. Let's consider a combined accuracy of +/-600ppm, if the connection interval is 1s and the slave misses a connection interval then the next interval's RX receive window will be widened by 600uS = 600 parts of 1 million micro-seconds.