There are multiple ways to sniff Connect (IEEE 802.15.4) packets (for example using the RAILTEST utility). This article will describe how to create a simple RAIL based application to configure EFR32 packet sniffing feature necessary to use the Simplicity Studio built-in Network Analyzer. This example uses the Simple TRX demo application as a boilerplate project to develop the sniffer application. In Simple TRX everything is configured (including the enabled PTI) as required only the PHY has to be set to match the packets wanted to sniff and main.c need to contain the appropriate code, which is actually very simple.
To test the sniffer, it is expedient to run a Connect network with at least two devices: a coordinator and an end node. The Sink / Sensor demo applications are excellent candidates to set up the test network.
Establishing the test network
To set up the test network, follow the application note AN902.
Creating the RAIL based sniffer
First, open the Simple TRX demo application and follow the wizard to create the project. In the last step Simplicity Studio will open the AppBuilder. Navigate to the Radio Configuration tab and select the required PHY by setting the Profile to Connect and selecting the appropriate PHY - this must be match with the settings of the devices in the test network.
Only a few lines of code is necessary to achieve the sniffing capability.
To use the IEEE 802.15.4 API functions:
#include "rail_ieee802154.h"
To enable IEEE 802.15.4 mode, turn on promiscuous mode and set PTI protocol format in the radio initialization:
This example application will be in RX mode during the whole operation so, several of the settings are irrelevant.
The complete main.c file is attached to the article for convenience, it is only necessary to copy over the Simple TRX project's original main.c file with the attached one. The attached main.c contains implementation of counting received packets and printing the packed count over the UART port. The current implementation only counts the packets, however any further filtering can be implemented in RAILCb_Generic(). Note, that PTI is a hardware feature thus implementing any filter in RAILCb_Generic() will not have any effect on PTI data output.
Compiling and running the project should result in continuously counting the packets received from the test network, both from coordinator and end node(s) including the ACK packets too.
Inspecting the test network communication in the Network Analyzer
Open the Network Analyzer perspective:
Connect to the device (right click on its name):
Start capturing:
From this point every packet sent from the sink or sensor device(s) should appear in the Network Analyzer:
See AN822 for more detailed guide on using the Network Analyzer.
Wake up the device with Bluetooth advertising packets
Measurement result
Software test environment:
RAIL 2.6 (Flex SDK 2.5.1.0)
Bluetooth SDK 2.9.2
Hardware used for examination:
EFR32MG14 based radio board (BRD4169A Rev A02)
Wireless Starter Kit (BRD4001A)
Introduction
This Knowledge Base Article is a short introduction to RFSENSE feature particularly from the practical view. This means how to configure a device capable to wakeup from sleep mode, where a BLE advertiser device is close to the EFR32 device.
One use case is, when the EFR32 is powered by a coin cell battery, and the goal is to minimize the time in active state. Therefore the radio should be in sleep state most of the time, and it wakes up only when a Bluetooth advertiser getting close to the sleepy device. In this typical use case that the transceiver should be disabled before enabling the RFSENSE. Then the transceiver can be enabled by the wakeup event, or manually disabling the RFSENSE. At the end of this KBA some measurement results shared to understand this practical application better.
What is the RFSENSE
RFSENSE is an Ultra Low Energy RF detector peripheral on EFR32 devices available even in EM4 Shutoff mode. During the device is in sleep mode the RF detector continuously monitors the RF band for any signal and generates a wakeup event when RFSENSE is active - this method can reduce the energy consumption significantly. Once the signal will have sensed the RFSENSE feature will be disabled, thus need to reactivate to further use. The RFSENSE held in reset by default.
There are two configurable parameters in the RFSENSE. The detection period (or sensing time) despite, that it's name indicates temporal nature it relates to the incoming RF energy (value must be determined empirically, due this fact we are sharing our measurement results. The other parameter is the RF sensing band, where the RFSENSE operates. These are discussed in more details in the following section.
Although RFSENSE is a very effective energy saving feature, it has some limitations:
Below 0 °C the RFSENSE is unreliable, this means that the RFSENSE generates wakeup signals randomly (vid. API documentation).
The RFSENSE is not band filtered, that means for example if a device operates at 868 MHz, a 900 MHz signal may have enough power to wakeup the device. The radio configuration has no effect on RFSENSE.
If a radio packet has enough power to wake up the sleepy device, there is no chance for the radio to receive that packet, due to the wakeup period length.
Configure RFSENSE
The RAIL_StartRfSense()API supports configuring both of the RFSENSE peripheral parameters. The API receives 4 parameters (documented in RAIL API Documentation). We will go through the details of these configuration parameters.
Like most RAILAPI functions, RAIL_StartRfSense() takes the handle of a RAIL instance. The second parameter is the sensing band selector, it can be any combination of 2.4GHz and SubGHz bands (there are predefined enum types). The third parameter is a RAIL_Time_t instance, which sets what is the minimal period the incoming RF signal should be “sensed”, called as sensing time. Here we have to note that it is a very inaccurate in this mean, a given signal has energy at a given distance (due to interference and free space path losses) and need to consider a custom designed antenna matching circuit, so it doesn’t define the sensing time exactly.
RAILTEST application provides two command line interface (CLI) commands related to RFSENSE. One of these is the sleepcommand which receives 1 to 3 arguments, the first tells which EM mode should be used, and the others are related to the API discussed above: the sensing time and the band selector parameters. The other command (rfsense) implements subset of features of the sleep command, it calls immediately the RAIL_StartRfSense()API without setting any EM Mode.
Although the sleepCLI command is applicable in all EM modes, using the sleep command makes sense in EM2, EM3 and EM4modes only (4s and 4h are also valid on first generation MCUs).
Wake up with a Bluetooth advertiser device
We had tested RFSENSE with soc-empty sample application which is part of Bluetooth SDK. The application serves as a skeleton example for further development. It sends only the beacon frames and gives the opportunity to join.
There are two software configurable parameters, which have impact on target's RFSENSE. If you would like extend the range where the RFSENSE can be activated, generally you have two choices. These are:
increasing the length of the advertise packet
increasing the message sending duty cycle
The Generic Access Service holds the Device Name Characteristic where the device's name is defined. This is part of the message and will be sent in every advertisement interval. The easiest way to increase the beacon's length can be done via Bluetooth Configurator (part of Bluetooth SDK).
The gecko_cmd_le_gap_set_advertise_timing() Bluetooth API call sets the minimum and maximum advertisement interval. It's minimal value is 20 ms, therefore it cannot be used as a range extender option when you want to use a Bluetooth advertiser. This means that the first option is the more efficient to extend the RFSENSE operational range in this use case.
Measurement results
For getting exact data we had done conducted RF measurements. We had used two devices, one used as a CW signal transmitter (custom application) and one with RAILTEST application used as sleepy device. The custom application provided with one CLI command for setting the period, the CW signal duty cycle, and the PA power.
First we had done a sensing time resolution and programmed vs. real PA power level examination, then we measured the necessary transmission time at constant PA level at 20 unit each on the whole range (0-252) to wake up the target device. Then we measured the minimal PA power required to activate the RFSENSE by a continuously radiated CW signal.
At last we captured some radiated measurement with using RAILTEST and soc-empty applications on the two device, but the results are not exact due to the behave of the radiated signals, so we ended this KBA a few normative notes.
Sensing time resolution/accuracy
In the first table we are showing the possible values of sensing time in microseconds. Sensing time selection above 1 second does not have practical meaning, so we are not representing the full range of applicable sensing time. The growing of the real sensing time values are quadratic.
On the top row are the sensing time ranges (from previous column + 1 to the Max value), serves as the second parameter of sleepCLI command and so for the RAIL_StartRfSense()API, and the lower is the return value of the API, the real configured sensing time. The RFSENSE can be disabled if this parameter is 0.
Max [us]
0
301
401
602
1005
1811
3422
6643
13086
25972
51743
Real [us]
0
268
335
469
737
1274
2348
4496
8791
17382
34563
PA Power and minimum radiation time
The second table shows the sufficient transmission time at fix power to waking up the sleepy device. The radio are not able to transmit shorter than 42 us CW signal. The sensing time is 1 for maximal sensitivity.
PA Power [dBm]
0
4.3
7.1
9.1
10.4
11.5
12.2
12.6
13.1
13.5
13.7
14
14.3
Rail raw power
20
40
60
80
100
120
140
160
180
200
220
240
252
Min. radiation time [us]
280
251
221
105
75
61
42
42
42
42
42
42
42
Minimum power
The minimum transmission power required to wake up the sleepy device using continuous CW signal was about 4 dBm (RAIL_TxPowerLevel_t unit) when conducting measurement was applied.
Radiated measurements installation and results
With two unmodified sample applications (RAILTEST and soc-empty) it is possible to try how RFSENSE works.
Use Simplicity Studio to generate these two sample application and to flash your devices. Then open your favorite terminal program and send the sleep command to the RAILTEST device. Recommended parameter values for sleep command are:
> sleep 2 1 1
where '2' stands for EM2 mode, '1' stands for the lowest sensing time and the last '1' means the 2.4 GHz band is selected.
Then place the two devices close to each other (it should be ~5cm distance between the patch antennas and you will get the following message in the terminal window:
It is often required to measure the supply voltage when the radio is on and packet transmission is in progress (for example for battery lifetime estimation). Connect does not provide direct function for this purpose, however exploiting the flexible PRS (Peripheral Reflex System) feature of EFR32 makes it possible to measure the supply voltage during transmission.
To show how it is achievable the Sink / Sensor Connect example will be used and the sensor application will be modified to implement the measurement. The test environment contained two identical Wireless Starter Kits (BRD4001A main board + BRD4255A radio board) and Flex SDK 2.5 was used.
Compile and run clean examples
First, open, compile and run both applications to make sure it works as expected using a serial port terminal software. On the sink issue the commands form 0 and pjoin 255 while on the sensor issue the join 0 command. At this point the sensor has to send the temperature values to the sink periodically.
PRS signals to detect transmission
The next step is to figure out how to find when the transmission is in progress. The EFR32 radio peripheral is a PRS producer and it can emit two PRS signals which can be used for this purpose. One is PRS_MODEM_PRESENT which is activated when the radio has sent the preamble (i.e. when it starts to transmit the sync word). The other signal is PRS_MODEM_SYNCSENT which is activated when the sync word has been sent (just before the payload).
PRS_MODEM_PRESENT is chosen for the current purpose as it has the advantage that since the sync word is fixed, the measurement will happen with the same condition all the time. In case of PRS_MODEM_SYNCSENT the measurement would be started after the sync word is sent so, the measurement would happen during transmitting the payload which may differ packet by packet.
Although it is not necessary, the PRS signals can be routed out to GPIO ports and this way it is possible to inspect those signals with oscilloscope.
In the first step, the PRS channel will be configured and enabled to output PRS_MODEM_PRESENT signal on a GPIO port (in this case PC7 which is available at P3 position of the WSTK header connector):
// output PRS_MODEM_PRESENT signal on PC7 for oscilloscope inspection
GPIO_PinModeSet(gpioPortC, 7, gpioModePushPull, 0);
halEnablePrs(
10,
1,
gpioPortC,
7,
(PRS_MODEM_PRESENT & _PRS_CH_CTRL_SOURCESEL_MASK) >> _PRS_CH_CTRL_SOURCESEL_SHIFT,
(PRS_MODEM_PRESENT & _PRS_CH_CTRL_SIGSEL_MASK) >> _PRS_CH_CTRL_SIGSEL_SHIFT);
The code above should run at initialization time thus it is placed into emberAfMainInitCallback() function. The helper functions (like halEnablePrs()) are available in the attached flex-callbacks.c file. Furthermore, adding #include "em_cmu.h" is necessary to set up PRS clock.
If the application compiled and started the attaching a scope probe to P3 of the WSTK a high level pulse should appear every time the sensor application transmits a message. The rising edge of the pulse shows the end of the preamble and the beginning of the sync word:
Starting the ADC conversion on PRS signal
It is not only possible to route out the PRS_MODEM_PRESENT signal to a GPIO but various peripherals can be the consumer. In the current case the ADC conversion must be started on this signal. This requires ADC default settings to be modified:
PRS must be enabled for the ADC peripheral
The corresponding channel must be routed to the ADC
The corresponding code snippet including the ADC initialization for internal supply voltage measurement (adding #include "em_adc.h" is necessary to set up the ADC):
// Enable ADC clock
CMU_ClockEnable(cmuClock_ADC0, true);
/* Base the ADC configuration on the default setup. */
ADC_Init_TypeDef init = ADC_INIT_DEFAULT;
ADC_InitSingle_TypeDef sInit = ADC_INITSINGLE_DEFAULT;
sInit.prsEnable = true; // Enable to start conversion on PRS signal
sInit.prsSel = adcPRSSELCh10; // Select PRS channel where PRS_MODEM_PRESENT was configured
// Initialize timebases
init.timebase = ADC_TimebaseCalc(0);
init.prescale = ADC_PrescaleCalc(400000, 0);
ADC_Init(ADC0, &init);
sInit.reference = adcRef5V;
sInit.acqTime = adcAcqTime8;
sInit.posSel = adcPosSelAVDD;
ADC_InitSingle(ADC0, &sInit);
At this point the ADC conversion will be started every time on the rising edge of the PRS_MODEM_PRESENT signal.
Retrieving the supply voltage value
View ADC conversion complete PRS signal on an oscilloscope
The ADC is not just a consumer but it produces signals as well. Routing the ADC's conversion completed signal to a GPIO pin makes it possible to analyze the timing of A/D conversion. The following code routes the ADC signal to PC9 (P7 on WSTK):
// output PRS_ADC0_SINGLE signal on PC9 for oscilloscope inspection
GPIO_PinModeSet(gpioPortC, 9, gpioModePushPull, 0);
halEnablePrs(
11,
2,
gpioPortC,
9,
(PRS_ADC0_SINGLE & _PRS_CH_CTRL_SOURCESEL_MASK) >> _PRS_CH_CTRL_SOURCESEL_SHIFT,
(PRS_ADC0_SINGLE & _PRS_CH_CTRL_SIGSEL_MASK) >> _PRS_CH_CTRL_SIGSEL_SHIFT);
The code above is not necessary for the measurement, the only purpose is to enable visible inspection of the timing. The ADC conversion complete PRS signal is a very short positive pulse:
The A/D conversion time using the above settings is ~58us:
Updating the measured value
The conversion complete interrupt of the ADC must be enabled:
The Connect examples already implement the ADC0_InterruptHandler() (in ${workspace_loc:/${ProjName}/hal/EFR32/hal/adc-efr32.c) which conflicts with the current example's one thus the fileadc-efr32.c where it is originally implemented must be excluded from build.
There is only one step left, displaying the measured value:
The above line is placed at the end of the reportHandler() to print the measured value after the packet sent.
To keep the example simple the value is printed only on the CLI, else the structure of the report packet should be changed (on both sensor and sink side).
Note, that Connect does not provide any API call to directly manipulate the transmit buffer from application level. Thus after the transmission is started it is not possible to add the value measured during the current transmission to the current packet. As a result, the measured value can be transmitted only in the next packet.
In this example the whole measurement and supporting functions were implemented in flex-callbacks.c to keep all code in one place, although it is recommended to use a better organized structure in production applications.
This article shows how to create monochrome icons / bitmaps to display on the LCD attached to the developer boards.
Since The GLIB pixmap format is not standard and additional plug-in has to be installed in GIMP (the plug-in is attached to this article). In GIMP Edit -> Preferences find the Plug-in folder and copy the attached GIMP plug-in to this directory then restart GIMP (on Linux the file attribute of the plug-in must be set to executable).
First create a new image, set the required size (width and height):
Edit the image - preferably use only black and white color as the color depth of the LCD display on the WSTK is 1 bit.
By default the color mode of the image is RGB for a newly created picture. This must be changed to indexed to be processable by the plugin thus change it: Image -> Mode -> Indexed.
Select Use black and white (1-bit) palette:
From File menu choose Export GLIB pixmap... to save the pixmap files:
Select the appropriate folder for the files (it is a good practice to create a directory in the Studio project to store the pixmaps and export the files to that folder directly) and choose a suitable name for the picture (don't add file extension it will be generated by the plug-in):
Press OK to save the C and header files - be careful, there is no confirmation the existing files will be overwritten.
The plug-in creates a file with .c extension which contains the actual image data and a file with extension .h containing two defines for the image width and height. Files, defines and the data array named based on the Output name. For example if the Output name is thermometer a header file named thermometer.h will be created containing THERMOMETER_WIDTH and THERMOMETER_HEIGHT defines and a C file named thermometer.c containing thermometer_bits array.
To use the pixmaps created with GIMP simply include the header file in the project, for example:
#include "thermometer.h"
The header files must be in the include path - it may need to add the pixmap folder in project properties.
The created pixmap can be used by the GLIB_drawBitmap() GLIB API function:
The following quick guide will show you how to set up and enable the security in Connect through a MAC-Device example. This article uses two Wireless Starter Kits with BRD4257A radio boards (Flex Gecko, 19 dBm, 915 MHz). However, the following is applicable for all Connect applications, disregarding the radio board.
If you are new to Connect, please consider going through the User Guide series UG235 starting with UG235.01 to learn more. For more information on the MAC-Device example and an introduction how to set it up, please see Connect MAC-Device KBA.
Security in Connect
Connect is based on the IEEE 802.15.4-2011 standard which defines various Physical (PHY) and Media Access Control (MAC) layer modes designed for short-range communication in Personal Area Networks (PANs). IEEE 802.15.4 supports the following security services:
Data confidentiality
Data authenticity
Replay attack protection
The Auxiliary Security Header can have various arrangements, depending on the security and key setup available. However, with Silicon Labs Connect, when security is enabled it:
Always uses a 128-bit key, which was set by the application (that is, there is no IEEE 802.15.4 key identifier field).
Uses all three of the above services.
This means that the Auxiliary Security Header is five bytes long:
Format of the Auxiliary Security Header
Only the lowest three bits are used from Security Control, which selects the security mode (always 5). The Frame Counter is a counter on each device that enables replay protection: The counter is part of the authenticated data (that is, MIC is calculated over it) and a receiver should not accept frames with the same/lower count. The Frame Counter must be valid even if the device reboots.
To guarantee data authenticity, a 4-byte MIC will be added at the end of the MAC payload (before the FCS). In the security mode supported by Silicon Labs Connect, the security headers and footers use nine bytes of the MAC payload.
Configuring and enabling security
The steps you need to go through to enable security are:
Set the key on all the nodes (same key) using the "set-key" command
Enable security on all the nodes by setting the 1st bit of the tx options on each of them, using the "set-options" command (give 3 as a parameter to enable security and keep ACKing on)
Short addressing only partially work in MAC mode with security enabled. The limitation is that the source address has to be long, therefore using a short destination and a long source address, or both long source and destination addresses are acceptable.
Note: From Flex SDK 2.6.0 there is a new API available, emberMacAddShortToLongAddressMapping which can map the short addresses to the long ones. By using this API and mapping the appropriate addresses, the above limitation can be worked around, the short-short addressing can be used as well in MAC mode while security is enabled.
This article intends to show how to configure an On-off keying modulation profile in the Radio Configurator in Simplicity Studio. In this example we will be using two Wireless Starter Kit with BRD4257A radio boards (Flex Gecko, 19 dBm, 915 MHz). However, considering the following guidelines, the radio link can be set up for any base frequency and/or radio board.
The guide is not going into details about most of the controls found in the Radio Configurator and assumes basic radio technology and RAIL application creational knowledge. For more information on custom radio configurations, please see AN971.
OOK modulation
The On-off keying modulation method is a simple type of the amplitude-shift keying modulation. It codes the transmitted data at the presence or the absence of the carrier wave (binary one and zero respectively).
OOK modulation on air
This type of modulation is quite popular due to its simplicity and rather low implementation costs. Its main advantage is that it can let the transmitter run in idle while transmitting zeros, which can preserve power. The biggest disadvantage of the technology is its sensitivity to noise. Since zero means nothing is transmitted, with a significant amount of background noise the ones and zeros can be a challenge to distinguish on the receiving end.
Radio configurator setup
Create a new RAILTEST example application to set up the radio link in the radio configurator. It is easier to start with a base profile, in our case we chose one of the 915 MHz profiles. Naturally, you can set the profile and the following settings based on your requirements.
General radio link parameters
After all the settings were loaded, switch to "Custom settings" to enable edit. Here choose OOK as the modulation type to switch to On-off Keying modulation. In our case the data rate is set to 4.8 Kbps, as OOK transmissions are usually used with lower data rates. For this modulation, deviation is not relevant.
Important: Make sure to uncheck all settings under the "Advanced tab" in the bottom, letting the configurator determine all the parameters.
If you are setting up a receiver, also make sure to define your RX and TX crystal accuracy under the "Crystal" tab. This will help the configurator determine a valid receive bandwidth. Alternatively, if you have a predefined receiver bandwidth, you can set it under the Advanced section, "Channel bandwidth" option. If neither the crystal accuracy nor the bandwidth is known, in general 200 kHz can be recommended.
BT parameter recommendations
At this point the modulation probably will not work yet, as the Shaping Filter Parameter (BT) is set for FSK2 (or any other which you used as a base profile) and not for OOK modulation. Set this parameter to 1.5 for the best results, see explanation below.
In yellow you can see the output and its spectrum generated with low BT parameter, in this case 0.5. It's visible how the signal is over-filtered, the edges are rounded down too much for the receiver to interpret this as an OOK modulation.
Time domain graphs of the different filter settings
We can get an ideal OOK output signal by completely disabling the filtering, these outputs are marked with purple. You can see it on the time domain diagram how perfect it looks like, however significant background noise and regular side-bands appeared on its spectrum at the same time.
Frequency domain graphs of the different filter settings
The output of the recommended configuration with the Gaussian filter on, using a BT of 1.5 is marked with teal on the figures. In time domain a lesser "rounding" effect came back, however by using this filter we can suppress the side-bands of the spectrum emission and less background noise is generated, while the receiver can interpret the signal without any issue.
Therefore, for the best results our recommended value is 1.5 for the BT parameter. See the final settings of the radio link below.
Radio configuration for OOK modulation
You can also find this configuration attached for the aforementioned base band and radio board.
Testing the radio link using railtest
With the settings above applied, it's time to generate the example code and build, flash it on the devices. After opening the console on both targets, or by just pushing the PB0 a few times shortly, we can check the functionality of the radio link.
See a test method with results in the following to get an approximate PER of the link created:
RAIL Test App - Built: Feb 12 2019 11:13:18
> setnotifications 0
{{(setNotifications)}{Peripherals:Enabled}{Notifications:Disabled}}
> status
{{(status)}{UserTxCount:0}{AckTxCount:0}{UserTxAborted:0}{AckTxAborted:0}{UserTxBlocked:0}
{AckTxBlocked:0}{UserTxUnderflow:0}{AckTxUnderflow:0}{RxCount:999}{SyncDetect:999}
{NoRxBuffer:0}{RfSensed:0}{ackTimeout:0}{ackTxFpSet:0}{ackTxFpFail:0}{RfState:Rx}
{RAIL_state_active:0}{RAIL_state_rx:1}{RAIL_state_tx:0}{Channel:0}{AppMode:None}
{TimingLost:0}{TimingDetect:0}{FrameErrors:0}{RxOverflow:0}{AddrFilt:0}{Aborted:0}
{Calibrations:1}{TxChannelBusy:0}{TxClear:0}{TxCca:0}{TxRetry:0}}
As you can see out of a 1000 packets sent with rather small delay, 999 arrived successfully, resulting a 0.1% error rate, which can be considered acceptable.
Proprietary Knowledge Base
Connect sniffer using RAIL
Introduction
There are multiple ways to sniff Connect (IEEE 802.15.4) packets (for example using the RAILTEST utility). This article will describe how to create a simple RAIL based application to configure EFR32 packet sniffing feature necessary to use the Simplicity Studio built-in Network Analyzer. This example uses the Simple TRX demo application as a boilerplate project to develop the sniffer application. In Simple TRX everything is configured (including the enabled PTI) as required only the PHY has to be set to match the packets wanted to sniff and
main.c
need to contain the appropriate code, which is actually very simple.To test the sniffer, it is expedient to run a Connect network with at least two devices: a coordinator and an end node. The Sink / Sensor demo applications are excellent candidates to set up the test network.
Establishing the test network
To set up the test network, follow the application note AN902.
Creating the RAIL based sniffer
First, open the Simple TRX demo application and follow the wizard to create the project. In the last step Simplicity Studio will open the AppBuilder. Navigate to the Radio Configuration tab and select the required PHY by setting the Profile to Connect and selecting the appropriate PHY - this must be match with the settings of the devices in the test network.
Only a few lines of code is necessary to achieve the sniffing capability.
To use the IEEE 802.15.4 API functions:
To enable IEEE 802.15.4 mode, turn on promiscuous mode and set PTI protocol format in the radio initialization:
This example application will be in RX mode during the whole operation so, several of the settings are irrelevant.
The complete
main.c
file is attached to the article for convenience, it is only necessary to copy over the Simple TRX project's originalmain.c
file with the attached one. The attachedmain.c
contains implementation of counting received packets and printing the packed count over the UART port. The current implementation only counts the packets, however any further filtering can be implemented inRAILCb_Generic()
. Note, that PTI is a hardware feature thus implementing any filter inRAILCb_Generic()
will not have any effect on PTI data output.Compiling and running the project should result in continuously counting the packets received from the test network, both from coordinator and end node(s) including the ACK packets too.
Inspecting the test network communication in the Network Analyzer
Open the Network Analyzer perspective:
Connect to the device (right click on its name):
Start capturing:
From this point every packet sent from the sink or sensor device(s) should appear in the Network Analyzer:
See AN822 for more detailed guide on using the Network Analyzer.
Using RFSENSE with Bluetooth advertising
Content
Software test environment:
Hardware used for examination:
Introduction
This Knowledge Base Article is a short introduction to RFSENSE feature particularly from the practical view. This means how to configure a device capable to wakeup from sleep mode, where a BLE advertiser device is close to the EFR32 device.
One use case is, when the EFR32 is powered by a coin cell battery, and the goal is to minimize the time in active state. Therefore the radio should be in sleep state most of the time, and it wakes up only when a Bluetooth advertiser getting close to the sleepy device. In this typical use case that the transceiver should be disabled before enabling the RFSENSE. Then the transceiver can be enabled by the wakeup event, or manually disabling the RFSENSE. At the end of this KBA some measurement results shared to understand this practical application better.
What is the RFSENSE
RFSENSE is an Ultra Low Energy RF detector peripheral on EFR32 devices available even in EM4 Shutoff mode. During the device is in sleep mode the RF detector continuously monitors the RF band for any signal and generates a wakeup event when RFSENSE is active - this method can reduce the energy consumption significantly. Once the signal will have sensed the RFSENSE feature will be disabled, thus need to reactivate to further use. The RFSENSE held in reset by default.
There are two configurable parameters in the RFSENSE. The detection period (or sensing time) despite, that it's name indicates temporal nature it relates to the incoming RF energy (value must be determined empirically, due this fact we are sharing our measurement results. The other parameter is the RF sensing band, where the RFSENSE operates. These are discussed in more details in the following section.
Although RFSENSE is a very effective energy saving feature, it has some limitations:
Configure RFSENSE
The
RAIL_StartRfSense()
API supports configuring both of the RFSENSE peripheral parameters. The API receives 4 parameters (documented in RAIL API Documentation). We will go through the details of these configuration parameters.Like most RAIL API functions,
RAIL_StartRfSense()
takes the handle of a RAIL instance. The second parameter is the sensing band selector, it can be any combination of 2.4GHz and SubGHz bands (there are predefined enum types). The third parameter is aRAIL_Time_t
instance, which sets what is the minimal period the incoming RF signal should be “sensed”, called as sensing time. Here we have to note that it is a very inaccurate in this mean, a given signal has energy at a given distance (due to interference and free space path losses) and need to consider a custom designed antenna matching circuit, so it doesn’t define the sensing time exactly.RAILTEST application provides two command line interface (CLI) commands related to RFSENSE. One of these is the sleepcommand which receives 1 to 3 arguments, the first tells which EM mode should be used, and the others are related to the API discussed above: the sensing time and the band selector parameters. The other command (rfsense) implements subset of features of the sleep command, it calls immediately the
RAIL_StartRfSense()
API without setting any EM Mode.Although the sleep CLI command is applicable in all EM modes, using the sleep command makes sense in EM2, EM3 and EM4modes only (4s and 4h are also valid on first generation MCUs).
Wake up with a Bluetooth advertiser device
We had tested RFSENSE with soc-empty sample application which is part of Bluetooth SDK. The application serves as a skeleton example for further development. It sends only the beacon frames and gives the opportunity to join.
There are two software configurable parameters, which have impact on target's RFSENSE. If you would like extend the range where the RFSENSE can be activated, generally you have two choices. These are:
The
Generic Access Service
holds theDevice Name Characteristic
where the device's name is defined. This is part of the message and will be sent in every advertisement interval. The easiest way to increase the beacon's length can be done via Bluetooth Configurator (part of Bluetooth SDK).The
gecko_cmd_le_gap_set_advertise_timing()
Bluetooth API call sets the minimum and maximum advertisement interval. It's minimal value is 20 ms, therefore it cannot be used as a range extender option when you want to use a Bluetooth advertiser. This means that the first option is the more efficient to extend the RFSENSE operational range in this use case.Measurement results
For getting exact data we had done conducted RF measurements. We had used two devices, one used as a CW signal transmitter (custom application) and one with RAILTEST application used as sleepy device. The custom application provided with one CLI command for setting the period, the CW signal duty cycle, and the PA power.
First we had done a sensing time resolution and programmed vs. real PA power level examination, then we measured the necessary transmission time at constant PA level at 20 unit each on the whole range (0-252) to wake up the target device. Then we measured the minimal PA power required to activate the RFSENSE by a continuously radiated CW signal.
At last we captured some radiated measurement with using RAILTEST and soc-empty applications on the two device, but the results are not exact due to the behave of the radiated signals, so we ended this KBA a few normative notes.
Sensing time resolution/accuracy
In the first table we are showing the possible values of sensing time in microseconds. Sensing time selection above 1 second does not have practical meaning, so we are not representing the full range of applicable sensing time. The growing of the real sensing time values are quadratic.
On the top row are the sensing time ranges (from previous column + 1 to the Max value), serves as the second parameter of sleep CLI command and so for the
RAIL_StartRfSense()
API, and the lower is the return value of the API, the real configured sensing time. The RFSENSE can be disabled if this parameter is 0.PA Power and minimum radiation time
The second table shows the sufficient transmission time at fix power to waking up the sleepy device. The radio are not able to transmit shorter than 42 us CW signal. The sensing time is 1 for maximal sensitivity.
Minimum power
The minimum transmission power required to wake up the sleepy device using continuous CW signal was about 4 dBm (
RAIL_TxPowerLevel_t
unit) when conducting measurement was applied.Radiated measurements installation and results
With two unmodified sample applications (RAILTEST and soc-empty) it is possible to try how RFSENSE works.
Use Simplicity Studio to generate these two sample application and to flash your devices. Then open your favorite terminal program and send the sleep command to the RAILTEST device. Recommended parameter values for sleep command are:
where '2' stands for EM2 mode, '1' stands for the lowest sensing time and the last '1' means the 2.4 GHz band is selected.
After sending this command you will receive:
Then place the two devices close to each other (it should be ~5cm distance between the patch antennas and you will get the following message in the terminal window:
With a longer advertisement packet we can extend this distance to ~30 cm.
Connect: measure battery voltage during transmission
Prerequisite readings:
Introduction
It is often required to measure the supply voltage when the radio is on and packet transmission is in progress (for example for battery lifetime estimation). Connect does not provide direct function for this purpose, however exploiting the flexible PRS (Peripheral Reflex System) feature of EFR32 makes it possible to measure the supply voltage during transmission.
To show how it is achievable the Sink / Sensor Connect example will be used and the sensor application will be modified to implement the measurement. The test environment contained two identical Wireless Starter Kits (BRD4001A main board + BRD4255A radio board) and Flex SDK 2.5 was used.
Compile and run clean examples
First, open, compile and run both applications to make sure it works as expected using a serial port terminal software. On the sink issue the commands
form 0
andpjoin 255
while on the sensor issue thejoin 0
command. At this point the sensor has to send the temperature values to the sink periodically.PRS signals to detect transmission
The next step is to figure out how to find when the transmission is in progress. The EFR32 radio peripheral is a PRS producer and it can emit two PRS signals which can be used for this purpose. One is
PRS_MODEM_PRESENT
which is activated when the radio has sent the preamble (i.e. when it starts to transmit the sync word). The other signal isPRS_MODEM_SYNCSENT
which is activated when the sync word has been sent (just before the payload).PRS_MODEM_PRESENT
is chosen for the current purpose as it has the advantage that since the sync word is fixed, the measurement will happen with the same condition all the time. In case ofPRS_MODEM_SYNCSENT
the measurement would be started after the sync word is sent so, the measurement would happen during transmitting the payload which may differ packet by packet.Although it is not necessary, the PRS signals can be routed out to GPIO ports and this way it is possible to inspect those signals with oscilloscope.
In the first step, the PRS channel will be configured and enabled to output
PRS_MODEM_PRESENT
signal on a GPIO port (in this case PC7 which is available at P3 position of the WSTK header connector):The code above should run at initialization time thus it is placed into
emberAfMainInitCallback()
function. The helper functions (likehalEnablePrs()
) are available in the attachedflex-callbacks.c
file. Furthermore, adding#include "em_cmu.h"
is necessary to set up PRS clock.If the application compiled and started the attaching a scope probe to P3 of the WSTK a high level pulse should appear every time the sensor application transmits a message. The rising edge of the pulse shows the end of the preamble and the beginning of the sync word:
Starting the ADC conversion on PRS signal
It is not only possible to route out the
PRS_MODEM_PRESENT
signal to a GPIO but various peripherals can be the consumer. In the current case the ADC conversion must be started on this signal. This requires ADC default settings to be modified:The corresponding code snippet including the ADC initialization for internal supply voltage measurement (adding
#include "em_adc.h"
is necessary to set up the ADC):At this point the ADC conversion will be started every time on the rising edge of the
PRS_MODEM_PRESENT
signal.Retrieving the supply voltage value
View ADC conversion complete PRS signal on an oscilloscope
The ADC is not just a consumer but it produces signals as well. Routing the ADC's conversion completed signal to a GPIO pin makes it possible to analyze the timing of A/D conversion. The following code routes the ADC signal to PC9 (P7 on WSTK):
The code above is not necessary for the measurement, the only purpose is to enable visible inspection of the timing. The ADC conversion complete PRS signal is a very short positive pulse:
The A/D conversion time using the above settings is ~58us:
Updating the measured value
The conversion complete interrupt of the ADC must be enabled:
To store the voltage a new global variable has been introduced (
adcValue
):The only necessary step is to implement the ADC interrupt handler:
The Connect examples already implement the
ADC0_InterruptHandler()
(in${workspace_loc:/${ProjName}/hal/EFR32/hal/adc-efr32.c
) which conflicts with the current example's one thus the fileadc-efr32.c
where it is originally implemented must be excluded from build.There is only one step left, displaying the measured value:
The above line is placed at the end of the
reportHandler()
to print the measured value after the packet sent.To keep the example simple the value is printed only on the CLI, else the structure of the report packet should be changed (on both sensor and sink side).
Note, that Connect does not provide any API call to directly manipulate the transmit buffer from application level. Thus after the transmission is started it is not possible to add the value measured during the current transmission to the current packet. As a result, the measured value can be transmitted only in the next packet.
In this example the whole measurement and supporting functions were implemented in
flex-callbacks.c
to keep all code in one place, although it is recommended to use a better organized structure in production applications.Creating monochrome bitmap files for LCD / GLIB using GIMP
This article shows how to create monochrome icons / bitmaps to display on the LCD attached to the developer boards.
Since The GLIB pixmap format is not standard and additional plug-in has to be installed in GIMP (the plug-in is attached to this article). In GIMP Edit -> Preferences find the Plug-in folder and copy the attached GIMP plug-in to this directory then restart GIMP (on Linux the file attribute of the plug-in must be set to executable).

First create a new image, set the required size (width and height):

Edit the image - preferably use only black and white color as the color depth of the LCD display on the WSTK is 1 bit.

By default the color mode of the image is RGB for a newly created picture. This must be changed to indexed to be processable by the plugin thus change it: Image -> Mode -> Indexed.

Select Use black and white (1-bit) palette:

From File menu choose Export GLIB pixmap... to save the pixmap files:

Select the appropriate folder for the files (it is a good practice to create a directory in the Studio project to store the pixmaps and export the files to that folder directly) and choose a suitable name for the picture (don't add file extension it will be generated by the plug-in):

Press OK to save the C and header files - be careful, there is no confirmation the existing files will be overwritten.
The plug-in creates a file with .c extension which contains the actual image data and a file with extension .h containing two defines for the image width and height. Files, defines and the data array named based on the Output name. For example if the Output name is thermometer a header file named thermometer.h will be created containing THERMOMETER_WIDTH and THERMOMETER_HEIGHT defines and a C file named thermometer.c containing thermometer_bits array.
To use the pixmaps created with GIMP simply include the header file in the project, for example:
#include "thermometer.h"
The header files must be in the include path - it may need to add the pixmap folder in project properties.
The created pixmap can be used by the GLIB_drawBitmap() GLIB API function:
GLIB_drawBitmap(&glibContext, 0, 0, THERMOMETER_WIDTH, THERMOMETER_HEIGHT, thermometer_bits);
For further reference of using GLIB library see the following knowledge base article:
Displaying on the LCD screen using glib
Security in Connect
Introduction
The following quick guide will show you how to set up and enable the security in Connect through a MAC-Device example. This article uses two Wireless Starter Kits with BRD4257A radio boards (Flex Gecko, 19 dBm, 915 MHz). However, the following is applicable for all Connect applications, disregarding the radio board.
If you are new to Connect, please consider going through the User Guide series UG235 starting with UG235.01 to learn more. For more information on the MAC-Device example and an introduction how to set it up, please see Connect MAC-Device KBA.
Security in Connect
Connect is based on the IEEE 802.15.4-2011 standard which defines various Physical (PHY) and Media Access Control (MAC) layer modes designed for short-range communication in Personal Area Networks (PANs). IEEE 802.15.4 supports the following security services:
The Auxiliary Security Header can have various arrangements, depending on the security and key setup available. However, with Silicon Labs Connect, when security is enabled it:
This means that the Auxiliary Security Header is five bytes long:
Only the lowest three bits are used from Security Control, which selects the security mode (always 5). The Frame Counter is a counter on each device that enables replay protection: The counter is part of the authenticated data (that is, MIC is calculated over it) and a receiver should not accept frames with the same/lower count. The Frame Counter must be valid even if the device reboots.
To guarantee data authenticity, a 4-byte MIC will be added at the end of the MAC payload (before the FCS). In the security mode supported by Silicon Labs Connect, the security headers and footers use nine bytes of the MAC payload.
Configuring and enabling security
The steps you need to go through to enable security are:
Limitations in MAC Mode
Short addressing only partially work in MAC mode with security enabled. The limitation is that the source address has to be long, therefore using a short destination and a long source address, or both long source and destination addresses are acceptable.
Setting up OOK modulation in RAIL using EFR32
Introduction
This article intends to show how to configure an On-off keying modulation profile in the Radio Configurator in Simplicity Studio. In this example we will be using two Wireless Starter Kit with BRD4257A radio boards (Flex Gecko, 19 dBm, 915 MHz). However, considering the following guidelines, the radio link can be set up for any base frequency and/or radio board.
The guide is not going into details about most of the controls found in the Radio Configurator and assumes basic radio technology and RAIL application creational knowledge. For more information on custom radio configurations, please see AN971.
OOK modulation
The On-off keying modulation method is a simple type of the amplitude-shift keying modulation. It codes the transmitted data at the presence or the absence of the carrier wave (binary one and zero respectively).
This type of modulation is quite popular due to its simplicity and rather low implementation costs. Its main advantage is that it can let the transmitter run in idle while transmitting zeros, which can preserve power. The biggest disadvantage of the technology is its sensitivity to noise. Since zero means nothing is transmitted, with a significant amount of background noise the ones and zeros can be a challenge to distinguish on the receiving end.
Radio configurator setup
Create a new RAILTEST example application to set up the radio link in the radio configurator. It is easier to start with a base profile, in our case we chose one of the 915 MHz profiles. Naturally, you can set the profile and the following settings based on your requirements.
General radio link parameters
After all the settings were loaded, switch to "Custom settings" to enable edit. Here choose OOK as the modulation type to switch to On-off Keying modulation. In our case the data rate is set to 4.8 Kbps, as OOK transmissions are usually used with lower data rates. For this modulation, deviation is not relevant.
If you are setting up a receiver, also make sure to define your RX and TX crystal accuracy under the "Crystal" tab. This will help the configurator determine a valid receive bandwidth. Alternatively, if you have a predefined receiver bandwidth, you can set it under the Advanced section, "Channel bandwidth" option. If neither the crystal accuracy nor the bandwidth is known, in general 200 kHz can be recommended.
BT parameter recommendations
At this point the modulation probably will not work yet, as the Shaping Filter Parameter (BT) is set for FSK2 (or any other which you used as a base profile) and not for OOK modulation. Set this parameter to 1.5 for the best results, see explanation below.
In yellow you can see the output and its spectrum generated with low BT parameter, in this case 0.5. It's visible how the signal is over-filtered, the edges are rounded down too much for the receiver to interpret this as an OOK modulation.
We can get an ideal OOK output signal by completely disabling the filtering, these outputs are marked with purple. You can see it on the time domain diagram how perfect it looks like, however significant background noise and regular side-bands appeared on its spectrum at the same time.
The output of the recommended configuration with the Gaussian filter on, using a BT of 1.5 is marked with teal on the figures. In time domain a lesser "rounding" effect came back, however by using this filter we can suppress the side-bands of the spectrum emission and less background noise is generated, while the receiver can interpret the signal without any issue.
Therefore, for the best results our recommended value is 1.5 for the BT parameter. See the final settings of the radio link below.
You can also find this configuration attached for the aforementioned base band and radio board.
Testing the radio link using railtest
With the settings above applied, it's time to generate the example code and build, flash it on the devices. After opening the console on both targets, or by just pushing the PB0 a few times shortly, we can check the functionality of the radio link.
See a test method with results in the following to get an approximate PER of the link created:
TX side
RX side
As you can see out of a 1000 packets sent with rather small delay, 999 arrived successfully, resulting a 0.1% error rate, which can be considered acceptable.