By default our mesh stacks use the LFRCO. It was found that using the internal low frequency RC oscillator instead of an external crystal fit most use cases. However, for certain situations where timing is important the RC oscillator is not adequate. To improve timing accuracy a couple of things can be done:

1. Switch to a low frequency external oscillator (LFXO) which most of our BRDs (found in the dev kit) already have.
2. To further improve timing using an external oscillator, adjust the capacitor tuning value (CTUNE). The optimal value depends on parameters like board, layout, crystal, and temperature.

This KBA deals with locating and downloading the wireless mesh stacks. If you are looking for information on getting access to the stacks, go here.

Once you have registered and gotten access to our wireless mesh stacks, you can download the stacks in one of two places. First is Simplicity Studio v4 the second is the support portal. The stack version you are looking will make a difference on your download method.

If you are looking for earlier stacks, prior to and including EmberZNet 5.7.1 use the support portal to download them.

If you are looking for the latest stacks, specifically stacks from EmberZNet 5.7.2 and later, use Simplicity Studio v4.

Simplicity Studio

Simplicity Studio v4 allows for easy integration of the stacks within the development tools. Using the easy to use Package Manager, you can quickly download stacks and have them ready to use within just a few minutes.

To download the stacks, you first need to go to the Launcher perspective of Studio and click on the Update Software button which can be found in the tool bar.

The stacks appear in the SDK Tab of the package manager (you might need to click through the Installation Manager windows to get to this page).

Within this tab you can find all of the available stacks for you. They are sorted by categories. The view allows you to see all categories or just narrow down to a single category, like EmberZNet or Thread. You can also choose which versions you want, looking at just the latest, all available versions or the ones you have installed. You can also look at the versions which match a version of the Gecko Suite, so you will have the matched versions of different stacks.

If you have access to unreleased stack versions, certain beta stacks can be found within the Early Access tab.

Be mindful that not every stack is available through Simplicity Studio, only stacks from around mid-2016. Most components like ECC Libraries are also not found within Studio either. For these you will need to locate them within the support portal. 

Support Portal

If you want to install the stacks separately from Studio or are looking to locate for packages that are not available within Studio, you can locate them within the support portal.  This includes older software like the ISA3 Utilities and Ember Desktop.

To locate these, you will need to log into your portal account and click on the Software Releases tab within your account. From there you can use the pulldown menu to change display options, the All Software tab shows everything if you are looking for that.

Contact support with any questions or problems.

Background:

Currently in 6.2.3 stack release, the EFR32 sniffer function is still under developing. For customers, the sniffer function is unavailable for EFR32 device. However, some custom are developing the sub-GHz devices and have strong requirement to capture the sub-GHz network with sniffer. There are two ways to capture the sub-GHz network:

• Capture the sub-GHz device directly, which needs the device joined to the sub-GHz network.
• Set up a sniffer with Nodetest to capture the sub-GHz network.

This article is a guidance to describe the second method. Hope it can help custom to develop sub-GHz device quickly.   

Hardware for setup:

Three WSTK main boards, one BRD4155A radio board, two BRD4150C radio boards.

• 1 WSTK main board + BRD4155A radio board  -- Form subGHz network
• 1 WSTK main board + BRD4150C radio board -- Join subGHz network
• 1 WSTK main board + BRD4150C radio board – Nodetest to capture subGHz network

Set up steps:

1. Use the BRD4155A board to form the sub-GHz network. The BRD4155A works in NCP mode. Connect the BRD4155A to PC with USB cable.
   1. Flash the ncp-uart-use-with-serial-btl-ecc-6.2.0.s37 to BRD4155A board. Please note you should also flash the uart bootloader for it.
   2. Build the SeSampleCommsHubHost sample first in Cygwin, then Launch the SeSampleCommsHubHost.

>> ./build/exe/SeSampleCommsHubHost.exe -p com2

3. Form sub-GHz network with below CLI commands:

>> network form 11 3 0x1234
>> network multi-phy-start 28 15 0
>> network pjoin 200

1. Flash the Nodetest to BRD4150C board, and set the BRD4150C board works in the same sub-GHz channel and in Rx mode.
   1. Flash C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.2\protocol\zigbee\build\nodetest-cortexm3-iar-efr32mg1p133f256gm48-efr32gb-brd4150c\nodetest.s37 to BRD4150C board. Please note you should also flash the bootloader for it.

>> commander flash C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.2\protocol\zigbee\build\nodetest-cortexm3-iar-efr32mg1p133f256gm48-efr32gb-brd4150c\nodetest.s37

1. Launch the console in Simplicity Studio, and you can see feedback if you enter any character. Please make sure the Nodetest works well.
2. Set sub-GHz channel for this BRD4150C board, it should the same as the previous formed sub-GHz network.

    >> setChannel 0x8F

1. Set this board in Rx mode

         >> rx

1. Start capture by right click the adapter in Simplicity Studio.

1. Use another BRD4150C board to join the sub-GHz network.
   1. Build a sub-GHz SOC project with BRD4150C board.
   2. Flash the firmware and bootloader to BRD4150C board.
   3. Launch the console in Simplicity Studio and join the sub-GHz network.

>> network join 0x8F 3 0x1234

Then you can see the package is captured by network analyzer in Simplicity Studio. See below picture for your reference.

Please note, you should make sure the sub-GHz device can join the sub-GHz network successful.

Under most circumstances you will want to build a Z3 Coordinator with our Z3Gateway sample application. However, this requires building an NCP and a host app and utilizing a PC or Raspberry Pi. However, you can also build a much simpler Coordinator with our Z3Light sample application. It requires a few changes to the Z3 Light application.

1. On the ZNet stack tab of the application, Change device type to Coordinator or Router
2. On the Plugins Tab:
   1. Include Network Creator plugin
   2. Include Network Creator Security plugin
   3. Within the Network Creator Security plugin you will also need to enable Trust Center Support

Once this is done, you can then generate your application and build it.

Once you have built and loaded your application from the CLI you can start a centralized network with the following command:

plugin network-creator start 1

EmberZNet Stack has Event control mechanism that basically allows application to run a piece of code at desired time interval, Typical examples of usage of events would be. 

1. To generate a periodic delay with only few lines of code. 

2. To run a piece of code which can be activated from an ISR but run outside of ISR at desired interval.

First step is to add a new custom event to the events list inside Simplicity Studio.

Following is a code snippet that can generate a periodic delay of approximately 3 seconds with only a few lines of code in your callbacks file.

#define MY_DELAY_IN_MS 1000

EmberEventControl myDelay;

void emberAfMainInitCallback(void)
{
  emberEventControlSetDelayMS(myDelay, 3 * MY_DELAY_IN_MS);  //Set delay for 3 seconds
}

void myDelayHandler(void)
{
  // First thing to do inside a delay event is to disable the event till next usage
  emberEventControlSetInactive(myDelay);
  
  //Do something
  emberAfCorePrintln("----Inside my delay handler----");

  //Reschedule the event after a delay of 3 seconds
  emberEventControlSetDelayMS(myDelay, 3 * MY_DELAY_IN_MS);  
}

Note: For more accurate timing requirements in time critical systems, usage of hardware timer is recommended instead of event control mechanism because the timing of event controls is based on system tick which depends on the platform. For example, 

* ::MILLISECOND_TICKS_PER_SECOND on the EM357 SoC is 1024, so each tick is therefore 1000 / 1024 = ~0.98 milliseconds.  Calling emberEventControlSetDelayMS(someEvent, 100) on the EM357 SoC will schedule the event for 100 ticks * (1000 milliseconds / 1024 ticks) = ~97.7 milliseconds.