Member | Action | Date |
---|---|---|
![]() |
Replied
to
Sleep on ISR exit
Hello Jimmy, Can you clarify what kind of solution you are looking to develop? Is this a Connect-based application, a pure RAIL application, or based on some other Silicon Labs stack? This will help us understand the reported behavior. Best regards, - Phillip |
Dec 03 2020, 4:06 PM |
![]() |
Selected an answer for
Rail configuration for Series 2
It end up to be a RAM issue, not related to the radio.
Show more
|
Nov 13 2020, 8:06 PM |
![]() |
Replied
to
Rail configuration for Series 2
Thanks for letting us know Davide, I'm glad you're up and running again. Good luck with the rest of your migration! Best regards, - Phillip |
Nov 13 2020, 8:06 PM |
![]() |
Replied
to
Rail configuration for Series 2
Hello Davide, Thanks for your question. For your (and anyone else who comes across this post in the future) reference, we provide guidance for migrating across EFR32 product families in a few different documents, each covering certain aspects or types of applications. For proprietary wireless applications, see AN1244: EFR32 Migration Guide for Proprietary Applications. From that document you can see (in section 2.1) some discussion re: radio configuration migration across devices. To better understand the problems you're facing, can you specify which example(s) you see RAIL_ConfigChannels() excluded from Series 2 targets? Are these the same examples for which you see no rail_config.c generation? I assume you're using Simplicity Studio v4 (please confirm if you're instead using SSv5) - can you clarify which SDK version you're building with? Best regards, - Phillip
|
Nov 12 2020, 4:14 PM |
![]() |
Replied
to
LQI in EFR32MG12
Hello Miki, I hope you are well. This is a long-delayed response, but for future reference: In the EFR32 devices, LQI (Link Quality Indicator) is based on the average correlation value of the first 8 received symbols after the sync word. Correlation is calculated between the received and expected signal properties (the properties used will vary, depending on the modulation format – i.e., for FSK it is scaled deviation). This averaged correlation is scaled to a value between 0 and 255, where a high value indicates a good signal, and a low value indicates a weak signal. As SNR increases, LQI flattens out at some point as noise has a diminishing effect on the results. Depending on your application (stack, API usage), in some cases there may be additional handling/processing (either implicitly or on-demand) of an "LQI" term. Searching the RAIL reference at docs.silabs.com for "LQI" yields detail on these additional considerations. Best regards, - Phillip |
Apr 15 2020, 9:17 PM |
![]() |
Replied
to
Getting wrong LQI for a received packet in Rail SDK
Hello Ashish, LQI (Link Quality Indicator) is based on the average correlation value of the first 8 received symbols after the sync word. Correlation is calculated between the received and expected signal properties (the properties used will vary, depending on the modulation format – i.e., for FSK it is scaled deviation). This averaged correlation is scaled to a value between 0 and 255, where a high value indicates a good signal, and a low value indicates a weak signal. As SNR increases, LQI flattens out at some point as noise has a diminishing effect on the results and the LQI "saturates" at a high value. In your evaluation, did you reduce TX power down to sensitivity? If not (or otherwise low enough), you may not have sufficiently stressed the signal reception to impact LQI.
Best regards, - Phillip |
Apr 15 2020, 8:54 PM |
![]() |
Updated
Wireless Gecko (EFR32) Rx direct mode on Proprietary Wireless Knowledge Base
In a direct Rx configuration the received data is directly output to an IC pin that in turn directly feeds another MCU pin for further processing. Typically in such applications all the signal detection (in form of preamble and / or sync word detection algorithms) are done by the processing MCU as opposed to the receiver’s own frame controller (FRC) block. In the RAIL library there exists a function that places the receiver into this mode: RAIL_DirectModeConfig. When enabled, the RX_DATA will be output to EFR32_PC11. This output data has the following properties:
Note that at the writing of this article the RAIL API documentation states that an RX_CLK signal is also output in parallel with RX_DATA. This is not correct, as there is in fact no RX_CLK signal that the RX_DATA is synchronized to.
Hence, the above direct mode operation can also be referred to as asynchronous direct mode operation. You may quite rightly ask: "What about synchronous direct mode operation?" Synchronous direct mode operation does provide an RX_CLK signal to which the RX_DATA signal is synchronized, but such a mode does not exist on the Wireless Gecko (EFR32).
The reason it does not exist is that a successful sync word detection gates the availability of the RX_CLK signal. So without sync word detection, there is no RX_CLK. If you have sync word detection, however, you may as well carry on and use packet mode. If for some reason RX_CLK and RX_DATA (placed on pins) would still be useful in your packet mode application, keep an eye on the radio related PRS signals (see below the current offering) in the RAIL documentation - as sooner or later RX_DATA and RX_CLK will show up.
|
Apr 15 2020, 6:02 PM |
![]() |
Replied
to
RAIL_GetRxFreqOffset() not working with SDK 2.13.1.10
Hello Isak, A few points of feedback here:
Best regards, - Phillip
|
Feb 27 2020, 9:09 PM |
![]() |
Updated
Connect Tutorial 2 - Communication Basics: Send and Receive on Knowledge Base
This is the second tutorial in a series that demonstrates "the essentials" of building applications based on Silicon Labs Connect. See Connect Tutorial Series: Table of Contents for an overview of topics addressed in the series, general pre-requisites to ensure you get the most out of the exercises, and definitive Connect references for when you're ready to dive deeper. The first tutorial (Getting Started with Application Development) introduced the Connect application development construct, based on plugins, callbacks, and events. In this second tutorial, we expand on this Connect-based application concept to demonstrate basic wireless communication by implementing simple message transmit and receive operations. To conduct the following exercise, you'll need two Wireless Starter Kit (WSTK) boards, each equipped with a (preferably identical) radio board. Basic Application Example: Transmit / ReceiveFirst, create a new "Empty" Flex SDK Project as described in tutorial 1 "Getting Started with Application Development". (Just create a new project for this tutorial 2 and give it an appropriate name - you don't need to actually repeat the tutorial 1 exercise.) Radio ConfigurationRadio configuration is a crucial part of successful communication between devices. Importantly, radio settings in the application must be in agreement with those in the hardware. Configuring the EFR32 radio is not the focus of this tutorial (for more information on this subject, see AN971: EFR32 Radio Configurator Guide). For the purposes of this tutorial series, please take "on faith" the following steps and select a predefined radio configuration in AppBuilder/Radio Configurator to provide radio functionality in the exercises: Open the radio configurator (open the project .isc file, and select the [Radio Configuration] tab in AppBuilder), then click on Protocol Configuration. Select Connect Profile from the available radio profiles. In the radio PHY drop down menu there are several predefined PHY settings that support the radio boards available in the Silicon Labs EFR32 portfolio. Select one of these that corresponds to your target hardware (especially the radio band). By selecting a Connect profile, you ensure that a Connect-compatible packet format will be applied during transmit and receive operations. If none of the predefined radio PHYs match your target hardware, select Custom settings from the radio PHY list and then apply any necessary adjustments to settings in the radio configuration fields. If the delta between a built-in PHY option and your hardware is small enough (like a minor change in frequency, bitrate, or deviation), select that closest predefined setting first, then switch to Custom setting and make your adjustments. However, be aware that radio configuration is a complex task, and even minimal changes can result in a non-functional radio PHY. Select Plugins & Callbacks, Configure Buttons, and Generate Project FilesThe default plugin configuration for the Connect (SoC): Empty Example provides all the features we'll use below, so we don't need to additionally enable or disable any plugins. We will, however, need to activate some related callbacks (using AppBuilder / Callbacks, as described in "Getting Started with Application Development"), so that our application is notified when the corresponding events occur:
Pushbutton configuration is managed using the Hardware Configurator in Simplicity Studio. As with the plugins, the default settings are suitable for our example, so we won't cover this tool in this tutorial. The buttons are initialized from the example Connect application's You can now generate the project (by clicking the [Generate] button) in AppBuilder. Doing so will populate the Simplicity Studio project workspace with source files and linked resources to support the configuration specified in your AppBuilder (.isc) file. We'll write our application using some these files in the following sections - for example, when we implement the callbacks enabled above. Address (Node ID) SelectionThe two devices which will send/receive messages to/from each other must have unique node IDs on the network. So that we can run the same firmware on both devices, we'll use button PB0 on the WSTK to select the node ID for each device at startup. When the application begins, we will first retrieve the state of PB0, then set the local (self) and remote (the other device on the network that we'll communicate with) addresses corresponding to the button state. We check the button state (and determine the correct assignment of device addresses) in
You can see here that we've also used LED0 to visibly indicate the address, which helps to distinguish the WSTK boards from each other. Note that this indication is only applicable at this point (shortly after power-on/reset), as LED0 is repurposed for a different use during the later message transmit and receive operations. (If you're not sure where to find Assigning Local Node IDNote: A single Connect network consists of multiple devices using a single one of the three available Connect Modes. For this tutorial (and the next few in this series), we've chosen a Direct mode Connect application for our demonstrations, as it provides both a sufficiently general platform and the fastest ramp to competency for new Connect developers. The modes are not interoperable, and the APIs vary (often significantly) among them - which makes porting from one to another impractical - so determining the optimal mode for your application is a critical first step. Other Connect Modes will be explored in later tutorials in this series, but with the API call that follows we effectively designate this as a Direct mode device. Later in
At this point the network parameters are set, and the device can communicate with other devices. Button Event HandlingFor this exercise, we want to send a message when button PB1 is pressed. Although we could periodically check (i.e. "poll") the button state, we will instead use an interrupt-based approach available with HAL support. The function The following snippet shows one possible implementation:
Although it is possible to send a message directly from this ISR, blocking execution by conducting lengthy operations from ISR context is not recommended. Instead, we'll only activate a Connect event (to be acted upon later) and quickly exit the ISR. To create a Connect event (as described in "Getting Started with Application Development"), we add it to AppBuilder / Other / Event Configuration and implement it in
Here, we've named the event "command" as Since we want to call the handler only once on each button press (as opposed to the blink event we created in the first tutorial, where the event was rescheduled repeatedly), the event must be inactivated in the handler. We send a message from this handler using the Implementing CallbacksPreviously, we enabled in the AppBuilder / Callbacks tab some callbacks we intend to use in our application. We'll now implement them using the stubs that were created in The Connect stack informs the application that a message has been sent using the following callback:
In the implementation above, we only toggle the state of LED0. Note, however, that this callback will fire even if the message did not actually send or the remote device did not successfully receive the message. The variable Handling incoming messages is accomplished through a callback as well:
The above callback fires when an incoming message is available. It checks whether the endpoint matches and compares the received message payload with the one we previously loaded to Usage and TestingCompile and download the firmware onto both devices. Start (reset) one of them without pressing PB0 (it will assume node ID 0x0000 and LED0 will be off) and do the same on the other board but hold PB0 down during start/reset (its node ID will become 0x0001 and LED0 will be on). After completing the above steps, press PB1 on one of the boards. LED0 should toggle on that board and LED1 should change its state on the other board if the message is successfully received. The same sequence (press PB1 to transmit a message) should work in the other direction as well. NotesKeep in mind that it is always a good policy to handle errors/return values/statuses, and the Connect API provides this feedback in most cases. Hence, as a "best practice" we highly recommend implementing such evaluation routines. This tutorial example omitted these important features to keep it simple, easy to understand, and focused on fundamental topics. ConclusionConnect-based applications benefit from simple APIs that support radio transmit and receive operations. The Wireless Starter Kit (WSTK) platform facilitates application development for the EFR32 product families. Later tutorials in this series dive deeper into more sophisticated radio support APIs and flexible bring-up/debug/management interfaces available to Connect-based applications. API ReferencesFunctions
Type definitionsDefines |
Oct 07 2019, 7:03 PM |
![]() |
Updated
RAIL tutorial: Introduction to Multi-PHY and Multiprotocol on Knowledge Base
This tutorial builds on the following tutorials:
To get the most out of this tutorial, some familiarity with the radio configurator is required, and it's also recommended that you understand the basics of radio protocol stacks (i.e. the OSI model). You can find these prerequisite tutorials on the table of contents site. IntroductionWith a customizable radio, the Wireless Gecko is a great option to support any radio configuration you need. You can set it up for standard IEEE 802.15.4, Bluetooth Low Energy, WMBus, or even the protocol (designed 30 years ago) used by your garage door opener. However, what if you need more than one of those standards? With single protocol radios, this requires a distinct 15.4 radio chip, a Bluetooth chip, and so on for each supported standard. Alternatively, with a single Wireless Gecko, you can store multiple "setups" in your device and switch between them. The only limitation is that it's still a single radio - you can't use multiple "setups" on the radio at the same time. The best way to manage the sharing of this single radio resource depends on the particular usecase targeted by your application. We provide different solutions (discussed below) to help you identify an optimal approach for your design. Channel-based Multi-PHYThe most common usecase in proprietary wireless is the need to support different PHY configurations. For example:
In these cases, Channel-based Multi-PHY is the best solution. It's called Channel-based, because in RAIL, you only need to change the channel to change the PHY. You can find a setup guide for some of these usecases in the Multi-PHY usecases and examples tutorial. Protocol-based Multi-PHYThis is not as widely used as Channel-based Multi-PHY, but it's the next logical step. The typical usecases:
For this, we recommend Protocol-based Multi-PHY. In this case, you can switch between protocols by calling Protocol based Multi-PHY is also useful if you want to test multiple configuration setups using RAILTest: You can change between protocols using the You can find a setup guide for some of these usecases in the Multi-PHY usecases and examples tutorial. Channel-based vs Protocol-based Multi-PHYIn general, you should consider your application requirements: If you want to have (for example) 20 channels, but those 20 channels are defined differently in some application configurations (typically by region), you should use Protocol-based Multi-PHY. A protocol change will be slower than a channel change, but the application doesn't even need to know which protocol is in use, since it still sees the same 20 channels through RAIL. Otherwise, in almost all cases, Channel-based Multi-PHY is a better choice. Dynamic Multiprotocol (DMP) between RAIL-based protocolsIf you have full protocol stacks that are completely independent, it makes sense to develop the PHY and Link layer independently as well. These layers communicate with RAIL, and the cleanest solution to this problem is Dynamic Multiprotocol. Typical usecase:
In Dynamic Multiprotocol, the RAIL scheduler decides which protocol is active. However, it might be worth using Dynamic Multiprotocol even if you don't need the RAIL scheduler, just for the code clarity it provides by the separation of stacks. Dynamic Multiprotocol is more capable than Multi-PHY, but also more complex, so it has some drawbacks when compared to Multi-PHY:
Writing RAIL application in DMP will be the subject of this tutorial. Dynamic Multiprotocol between RAIL-based and other Silicon Labs stack protocolsThe usecase for this is straight forward:
At the moment, Silicon Labs only provides such a DMP solution based on the Bluetooth stack and RAIL. You can access it by installing the Bluetooth SDK and starting one of the DMP applications. See AN1134 for more details, and an upcoming tutorial detailing DMP usage from a RAIL perspective. Other multiprotocol solutionsYou can find other types of multiprotocol mentioned in some Silicon Labs documents, but they are rarely used: Programmable multiprotocol means multiple firmware images for each protocol, and the protocol is decided during the manufacturing process, i.e. a device is either programmed to be a Bluetooth or a Zigbee device. Switched multiprotocol means two firmware images, one for each protocol. A bootloader loads the firmware needed for the protocol, and the two firmware can communicate with each other in a shared NVM storage. Protocol switching in switched multiprotocol is rather slow, and using DMP is almost always a better choice. Concurrent multiprotocol means that the PHY and maybe the lower layers of the stacks are the same, but the upper layers are different. E.g. You can run two proprietary 15.4 protocol on the same channel at the same time, but you don't really need multiprotocol specific APIs to support it. Related documentation |
Jul 02 2019, 7:50 PM |