Physical interface - Switch

Project Overview | Previous Step

We are now in the home stretch and ready to build our switch to work interfacing a button. The first thing we need to do is put some hooks into our project to give us a place to put our code.

If you remember back when you made the switch project, we enabled the Button Interface plugin, as the name suggests, this gives you an interface for buttons within our callbacks section.  If you look at the callbacks tab, you will see these callbacks under the Plugin-specific callbacks. There are callbacks for different button states as well as long and short presses. For this example, let’s pick button 0 as it is generally clear of the ribbon cable on the Thunderboard. We also don’t need much more than a single button press, so let’s make use of the Button0 Pressed Short callback, check the box next to that identifier. *

* Quick note – a short press is by default defined as less than 250 mSec, you can look through the plugin code and the button timeout definition within the plugin to see how this is defined.

Like the light, make sure at the bottom of your callbacks page you have the “Generate project-specific callbacks file” box checked. This will ensure your new callbacks file is generated for your application. You can then save your .ISC file and hit generate to add this new callback. You will get a box that talks about overwriting files. Make sure your Project_callsbacks.c file is checked, you should also create backups, just in case. Then hit OK.

When you see the Generation Successful window, you’re ready to move to the next step.

Locate your project callbacks file on the left view titled Project Explorer and open the file in your editor. You will see that your callbacks file now includes a new, blank function named emberAfPluginButtonInterfaceButton0PressedShortCallback(). This function is called anytime the button is pressed for a short time.

Now we need to take our CLI calls and use this function to make these calls happen within this function. Looking back at our configuration, we send two commands via the CLI to send a message:

zcl on-off toggle

and then either

send 0 1 1

which sent our message outright to a node and endpoint we specified, or

bsend 1

which used a binding table entry to remove our need to know the exact device we were sending a message to.

First let’s look at zcl on-off toggle. To do this, we need something that will construct our message for us. We can look in the Application Framework reference guide and then refer to the Ember Application Framework API Reference and then the Application Framework Command Buffer Loading Interface. In here you will find a number of commands that will help load command or response buffers which can be sent out with some form of a send command.

If you search for the word ‘toggle’ through this document, it should find the function

emberAfFillCommandOnOffClusterToggle()

which is a basic command which constructs our command buffer for us automatically. The benefit of this command is that it handled much of the overhead by utilizing the command buffer, making sending the message much easier later.  So, add a call to this function to your button callback function.

Now we need to find a command to send our buffer over the air for us. So let’s return to the Application Framework and click over to the General Application Framework Interface and search for functions that deal with sending messages. On this page, you can search for the word messaging, which locates the function that deal with sending messages within the application framework. If you look through this section, there are a lot of functions which you can call.

You could use a function like emberAfSendUnicast. But this has a lot of parameters. And as we noted, the benefit we had about using the a FillCommand function is that the command buffer overhead has been handled for us. If you look down the list, you will find a number of functions that start out emberAfSendCommand… these are the functions we want to look at. Since this is a specific command send directly to a single node, you can use emberAfSendCommandUnicast(). This takes two options, the first is a messages type and the second is some sort of integer argument that differs based on what your message type is.

emberAfSendCommandUnicast (EmberOutgoingMessageType type, uint16_t indexOrDestination)        

If you follow the link for the EmberOutgoingMessageType, you will see a number of different message types. EMBER_OUTGOING_DIRECT would allow you to send a message directly to a node id. Alternatively, a few lines down, you will find EMBER_OUTGOING_VIA_BINDING, which would allow you to leverage a previously made binding to send your message. Let’s take a look at each of these and you can pick the way you want to send your toggle.

EMBER_OUTGOING_DIRECT

If you choose to send a direct unicast to your node ID, this is the same operation as using the command send 0 1 1 to send your message. If you take a look at the send command’s help you will see the pieces you are providing with the numbers:

send (args)
     short id of the device to send the message to
     The endpoint to send the message from
     The endpoint to send the message to

Looking at the emberAfSendCommandUnicast function, your two options are a type and destination. In the case of using type EMBER_OUTGOING_DIRECT, the destination is our short ID of our target. As we noted before, you can use 0x0000 since this is a short id.

emberAfSendCommandUnicast (EMBER_OUTGOING_DIRECT, 0x0000);

This takes care of your node address. But we set our endpoints in the send command, and these are not yet handled. We need some function to configure the endpoints. And we need to configure this before we send our message otherwise it will be too late. Let’s return to the top level of the application framework and look around at operations that manipulate endpoints. If you search for the word endpoints, you will eventually come across the command emberAfSetCommandEndpoints(), which requires a source and destination endpoint. In our case we know both end points are 1, so you can hard code that if you would like, If you want, you can use emberAfPrimaryEndpoint() as the first argument because it’s the only endpoint of our device. However, in the case of the destination endpoint, you can only specify 1 as you need to hard code this.

emberAfSetCommandEndpoints(emberAfPrimaryEndpoint(),1);

Now you can test this out. Save your callbacks file and compile your code. Put this new application on your “switch” Thunderboard and press button 0, you should see your light turn on and off.

EMBER_OUTGOING_VIA_BINDING

Alternative to sending a direct message to your node, you can leverage the fact that you have already created a binding and send directly to that. The advantage of this is that it already takes care of all of your settings like node address and endpoints. However, now you must know your binding entry to where you can send this to the on/off cluster.

So go to your console and enter the command ‘option binding-table print’ to display your binding table.

#  type   nwk  loc   rem   clus   node   eui
0: UNICA  0    0x01  0x01  0x0003 0x0000 (>)000B57FFFEDEA263
1: UNICA  0    0x01  0x01  0x0006 0x0000 (>)000B57FFFEDEA263

The on-off cluster is 0x0006, so we want to send this to binding table entry 1. You can place this in as the second argument to your function:

emberAfSendCommandUnicast (EMBER_OUTGOING_VIA_BINDING, 1);

Like in _DIRECT format, now test this out. Save your callbacks file and compile your code. Put this new application on your “switch” Thunderboard and press button 0, you should see your light turn on and off.

Follow up

In the end, this isn’t the cleanest code possible. Because this function is hard coded on the button, we are always sending our message. In the included MySwitch_callbacks.c file we have included some code that you can use to check that your network is currently up. We also have print statements to display sensible messages when your light or switch are operating.

Project Overview

Previous Step

Communications

Project Overview | Previous Step | Next Step

Now that we have formed a network, it’s time to verify that we can successfully send messages between our light and switch. To do this will be using simple ZCL commands to start and 

First click on the serial console of the switch. At the prompt enter:

zcl on-off toggle

This builds a Zigbee Clusters Library command frame. You can tell it was constructed correctly because of the output:

Msg: clus 0x0006, cmd 0x02, len 3
buffer: 01 00 02

Cluster 0x0006 corresponds to the on-off cluster.

Command 0x02 is the toggle command and length 3 corresponds to the length of the command buffer.

The buffer is 01 for the frame control, 00 for the sequence number and 02 for the command id for toggle.

Now we want to send this command to our light. Because our light is the coordinator, we know it’s Zigbee node ID is 0x0000. Because we want to send these commands from end point 1 on the switch and to endpoint 1 on the light our command to send this would be:

send 0 1 1 

Hitting enter you will see on the light that it received a message for it’s 0x0006 cluster with command 02.

T00000000:RX len 3, ep 01, clus 0x0006 (On/off) FC 01 seq 00 cmd 02 payload[]

On the switch, you will see  it received a message as well.

T00000000:RX len 5, ep 01, clus 0x0006 (On/off) FC 08 seq 05 cmd 0B payload[02 00 ]

This is a default response as it is sent back from the light to the switch.

If we look at App Builder, you can see these messages sent in the transaction view, a ZCL: Toggle followed by a ZCL: DefaultResponse. You can look at details of each message as they are sent on the side panel. For example, if you look within the event details of the the DefaultResponse, you can see that the response is Status: SUCCESS, meaning that the message was sent and properly handled.

Because our light is our network coordinator, we know that it’s address is 0x0000. However, most of the time we can’t trust that this will be the case. We need some sort of functionality to get our switch to look for and find our light and then join with the light so that it can easily send messages to the light instead of needing to know the address of the light. Additionally, the switch and light need some means of discovering if they share common clusters, like the off-off cluster. To assist with this, Zigbee provides finding & binding as a standard means of performing just this action.

If you remember back when we created our light and switch, we added a Find and Bind plugin to each device. The Light utilized the Find and Bind Target plugin while the Switch utilized the Find and Bind Initiator plugin. With these plugins, it makes finding and binding easy. Instead of having our light looking for ZCL messages doing endpoint discovery and having to manually construct a full set of ZCL messages to be sent across our network, asking for nodes to identify themselves as well as their endpoints and clusters and then binding like clusters, the plugins will take care of it all for us.

What we will first do is make the light a find and bind target for its endpoints. This will make it monitor network traffic and look for devices which are doing Find and Bind Initiation. To do this we will enter the following command:

plugin find-and-bind target 1

This tells endpoint 1 to act as an endpoint target. You will know the command works because you will see:

Find and Bind Target: Start target: 0x00

Now on the switch we must start it as an initiator. This is a similar function, but instead of target, we use:

plugin find-and-bind initiator 1

When you enter on this, you will see traffic in both the serial window as well as the network capture window as well. The process will be complete when you see 

Find and Bind Initiator: Complete: 0x00

In the serial console. 

Looking at the network traffic, you can see:

1. Our switch sends out a broadcast ZCL: IdentifyQuery. This is responded to by our light.

2. Then the switch asks the light for its full EUI64 address, the light responds to this with its EUI64.

3. Then finally the switch sends a simple descriptor request to get cluster information from the light. The light responds with 5 clusters which it is server: 0, 3, 4, 5 and 6 and no clusters which it is a client.

From this information our switch with then creates binding with clusters that it matches. For the 5 server clusters on the light, it looks to see if it is a client cluster on any of those, for the switch those are clusters 3 (identify) and 6 (on-off). So if you go to the CLI of the switch and print the binding table, you will see these new bindings, which are bound to the EUI64, not just the short ID. To print the binding table, use the following command:

option binding-table print

The output will look like this:

#  type   nwk  loc   rem   clus   node   eui
0: UNICA  0    0x01  0x01  0x0003 0x0000 (>)000B57FFFEDEA263
1: UNICA  0    0x01  0x01  0x0006 0x0000 (>)000B57FFFEDEA263

With these bindings we can then use a bsend command to tell our device to send commands to a binding for a particular endpoint.

zcl on-off toggle
bsend 1

This sends a command to our bindings on endpoint 1.

With this information, we can get to the step of making our light and switch act like a light and switch. The light will turn on or off LEDs based on attribute state, while our switch will respond to a button press instead of sending commands due to CLI entries.

Project Overview

Previous Step
Next Step

Preparing for this lab

Project Overview | Next Step

First dock the Mini-Simplicity connectors onto your WSTKs are shown here:

Also connect your ribbon cable as shown. Then connect your Thunderboards on their corresponding 10 pin header. If your mini simplicity connectors do not have keyed headers, make sure to match your pin 1s of both 10 pin headers.

Since we are using Thurnderboards connected externally to our WSTKs, we must make sure our WSTKs are set to debug mode OUT. This can be done via commander. For each WSTK run the following command

commander adapter dbgmode OUT -s XXXXXXX

where XXXXXXX is the serial number of your WSTK.

This can also be performed within Studio from the Launcher perspective. Under the Debug Adapters pane near the top left, you should see the two boards/adapters show up as “J-Link Silicon Labs (4400xxxxx). Highlight each adapter and change the Debug Mode to “OUT”. If you are prompted to update the board firmware, please proceed with the update. Note that when the Debug Mode is OUT, Simplicity Studio does not know about the Thunderboard Sense 2 board anymore and this is expected. (WSTK main board is still recognized.)

Creating bootloaders

Because neither of our applications will run without a bootloader, we want to create a bootloader for each. Fortunately, a default Gecko application bootloader will work for each board in this example.

To generate this bootloader:

• Make sure your Simplicity Studio is in either the Launcher view or the Simplicity IDE view.
• Then select File > New > Project. This will bring up the New Project Wizard.
• On the first screen you want to select Silicon Labs AppBuilder Project and select Next.
• Then select Gecko Bootloader and select Next.
• When the Select Application screen comes up find the bootloader template titled “SPI Flash Storage Bootloader (single image)”. Select it and hit Next.
• Give your Project a name, such as “TB-app-BL” and hit Next.
• Finally, you will be asked for your Board, Part and Configuration. Make sure to specify the board as “Thunderboard Sense 2 (BRD4166A)”, this will populate the part field automatically (EFR32MG12P332F1024GL125) then specify your toolchain (GNU ARM 7.2.1 or IAR ARM 8.30.1) and hit Finish.

Once your App Builder project opens, click the generate button to generate your project without any changes. Once the Generation successful window appears, you are done.  Then use the Hammer icon on the toolbar to invoke your compiler and build your project. This will give you the binaries to flash onto your board. You will need to locate the file named -combined.s37, it should be located in your projects binary folder.

You should flash this application to each of your Thunderboards, making sure to erase each board as you do this. Because you are flashing an external part, it will ask you to use the device option (-d) to identify the part connected to your board, using EFR32 will be enough to proceed.

commander flash TB-app-BL-combined.s37 --masserase -s XXXXXXX -d EFR32

Once you have completed this, you will be ready to begin creating your projects.

Project Overview

Next Step

Creating the projects

Project Overview | Previous Step | Next Step

Now it is time to build our projects for our light and switch. We will be modifying them over the course of a few steps to give them the features they require.

Our first step will be to create two blank projects, from these blank templates, we will start to add the pieces which are required for building a full Zigbee light and switch.

So, let’s get started:

• Make sure your Simplicity Studio is in either the Launcher view or the Simplicity IDE view. 
• Then select File > New > Project. This will bring up the New Project Wizard.
• On the first screen you want to select Silicon Labs AppBuilder Project and select Next.
• When you are asked for the application type, select “ZCL Application Framework V2” and press Next.
• Then you will pick your stack version and application type, for this example we will pick EmberZNet 6.4.0.0 GA SOC and press Next.
• You will then be asked to pick a sample application to start with, since we are building this project from scratch, check the box near the bottom of the window that says “Start with a blank application” and hit Next.
• Next you will be asked to give your project a name, fill in the blank with your project name, such as "MyLight" or "MySwitch", and press Next.
  Note - these are the names we are going to assume you have used, so anytime a filename will include a project name, this is what you will see.
• Finally, you will be asked for your Board, Part and Configuration. These are the same settings are the bootloader, so specify the board as “Thunderboard Sense 2 (BRD4166A)”, this will populate the part field automatically (EFR32MG12P332F1024GL125) then specify your toolchain (GNU ARM 7.2.1 or IAR ARM 8.30.1) and hit Finish.

After some time, Studio will display your newly created .ISC file, this will mean your project is ready for editing. Don't forget you need to create two projects, one for the light and one for the switch, so make sure to have both before you move on.

Unlike our bootloader, we will need to make some modifications to this application to build it, so let’s do this for our next step, starting with the light.

Project Overview

Previous Step
Next Step

Configuring the projects

Project Overview | Previous Step | Next Step

Once you have created your projects, it's time to use App Builder to configure the projects for the types of devices they are going to. As we introduce new parts of app builder, we will do our best to explain to you the pieces which you are using and hopefully educate you on making the best use of app builder. 

For the light

Let's take a look at the MyLight.isc file. By default you should be on the General tab of your project. This gives some basic settings for your project, such as board, chip, and compiler. Below this is the Application configuration, which outlines the version of EmberZNet you are using and the location of the project. If you had an example project from the stack, this would give you a description of the operation of the application. And directly underneath this is multi-network configuration. This isn't something we will use today, but if you are looking for details, AN724 will outline multi-networking.

The next tab is the ZCL global tab. This is identification and versioning information for your part. You don't want to make any changes here for this project.

After this is the ZCL clusters tab, here is where we will make our first changes. On this tab you configure the ZCL elements of your device, namely your endpoints, the clusters which are enabled on your endpoints, and the attributes and commands that are supported by these clusters. 

For our light device we only need a single endpoint, which is the default, but we need to pick a device type that will work for our needs. While you can build custom devices with whatever clusters and attributes you want supported, AppBuilder includes a number of ZCL device types which contain the preconfigured clusters and attributes which are normal for a particular device type. Since we are building a light, we can use a default device included with the stack, for this project find the LO On/Off Light Switch  under the LO devices. This light definition has a number of default clusters for you, such as Basic, Identify, Groups, Scenes and On/Off. For this project we are going to focus on the On/Off cluster. But after you are done you can explore the other settings or even extend this light to be dimmable or color control, to add more functionality.

Moving to the Znet stack tab we will configure the Zigbee device and security level. This tab is where many of the Zigbee options are set. For the light, it will be a Coordinator/Router and utilize Zigbee 3.0 Security. These should be the default settings for this device, but if these settings aren’t correct they can be changed here. There are also some settings here for Radio configugration, ZDO and Inter-PAN settings, but they are beyond the scope of this project.

Proceeding to the Printing and CLI tab we find the configuration of Debug printing as well as the setup of the CLI. Debug printing allows you to add additional printing options beyond the ones that are supported by a standard application. The Cluster debugging includes print statements that are specific to the clusters enabled for your device. The General-purpose debug printing gives you additional printing within different aspects of your application, such as security or service discovery. You can even created your own custom messaging within this block.  Along the bottom you will settings for customizing your CLI. In this section you can enable different CLI commands for your device beyond the standard ones which are included.  For our needs, we are going to enable the On/off cluster printing along the top, so check box boxes next to this so that these print statements are compiled in and enabled at startup. But the normal CLI as it's built will be fine for our needs, so there are no changes needed for the bottom section.

The next tab is the HAL configuration tab. As noted, this is where some hardware settings are made. You want to be sure that your device is setup for the Application bootloader and that your part matches the board you are using (the BRD4162), but any other changes, we will make in a future step.

Finally, we need to configure the required plugins, which can be found on the corresponding tab. Plugins are the EmberZNet method to quickly enable or disable functionality supported by our application layer with a simple click of the button. For plugins, you should use all of the plugins which are included by default with the project and add the following: Network Creator, Network Creator Security, Find and Bind Target (all under ZigBee 3.0) and Security Link Keys Library (Stack Libraries).

Just to be safe, save your project to prevent anything from being lost. We aren't quite done yet, so don't hit the generate button just yet.

For the switch

Now, let's open up MySwitch.isc and configure the Switch similar to the light. Since you know where to find these settings, they should be much easier to set up.

Like the light, your device will have 1 endpoint. But the ZCL device type will be an LO On/Off Light Switch.

It will utilize Zigbee 3.0 Security but will be an End Device. Don't make it a sleepy end device, you won't be able to get as much response from the CLI, and we need to be able to interact with the device as we make our settings.

For plugins, you should use all of the plugins which are included by default with the project and add the following: Find and Bind Initiator (ZigBee 3.0) and Button Interface (HAL).

Because the switch is an end device you can exchange the Zigbee PRO Stack Library Plugin for the Zigbee Pro Leaf Library. This is an optional step, but the leaf library removes many of the additional stack libraries which are only needed for routers and coordinators. The result is a smaller library which consumes less power. While we aren't using the sleepy end device, this would help you achieve a much lower current draw when your device sleeps.

Finally, located the Binding Table Library plugin. It has one option to configure – the size of the binding table, we need to make sure our table has at least 6 entries. We probably won't need this many entries, but we want to make sure we have them, just in case. 

For both devices

There is one final setting you need to make to both devices to make sure you can run the CLI. This involves making sure that the serial port is configured correctly.

On both mySwitch and myLight go back to the plugins tab and you want to make sure that the Serial plugin is enabled. From within the Serial plugin you need to ensure both SERIAL and USART0 are enabled (select each in the peripheral box). Finally, because the Thunderboard doesn’t support hardware flow control, we need to change the flow control type within the USART0 peripheral (in the serial plugin), make sure that Flow Control mode is set to Xon-Xoff.

Once you have configured both applications, you want to save each project.

Next, click the Generate button on each project. Just like our bootloader this will create or link to all of the files necessary to build the project. It shouldn't take too long, but you will have a few moments of waiting until the Generation successful window appears. Once you get that, click OK.

Finally, you can click the hammer icon on the toolbar

(or any other command that will begin building your application) and build your application. This will take a minute or two, depending on the speed of your computer. You can follow the progress in your Console window at the bottom. Once the files are compiled and linked, some post build scripts will run. If these run correctly you will get the following message:

Image-builder not invoked since "OTA Bootload Cluster Policy plugin" is not enabled

16:55:26 Build Finished (took 48s.142ms)

The key is the Image-builder message. Image-builder is run after your project compiles correctly. Once you see that, you know that your project has compiled successfully. Next we need to flash it to our device and test it.

If you get some sort of error during your build, return to your project .ISC file and check your work setting on your device and see if you missed any steps or have an incorrect setting.

Project Overview

Previous Step
Next Step

Flashing and testing the application

Project Overview | Previous Step | Next Step

Locate your files in the binary folder within Studio and select either the .GBL .EBL or .S37 files for your project.

Flash each binary to a separate Thunderboard, making one Thunderboard the light and one the switch.

commander flash -s XXXXXXXX MyLight.s37 -d EFR32

commander flash -s XXXXXXXX MySwitch.s37 -d EFR32

We need to verify that each application is properly flashed and running. We will check them from the CLI. To connect to the serial terminals, enter either the Simplicity IDE or Network Analyzer view in Studio. Find your WSTKs under Debug Adapters. Right click on each of them and select “Launch Console.” This will bring up your console window. Switch to the Serial 1 header and press enter a few times, this should cause your Project name to appear as your application prompt.

Ensure that both your Light and Switch are working.

Next, we will step through joining each device onto a network and adding the pieces to each so that you can activate the LEDs of your light and the buttons of your switch.

Project Overview

Previous Step
Next Step

Forming and joining the network

Project Overview | Previous Step | Next Step

Now we will form our network with the light and use a Zigbee installation code to join the switch to the network. This will be handled via the CLI, so we will need to connect to the CLI on both devices, this can be done just like in the prior step, right clicking on each WSTK in the Debug Adapter View and select “Launch Console.”

Setting up the network

First, we will form the network on the Light. Go to the CLI for the light and enter the command:

plugin network-creator start 1

This tells the light to invoke the network-creator plugin to start network formation. The 1 option tells the plugin to form the network centralized, this makes the light a trust center as well as a router.

You should see output similar to the following:

NWK Creator: Form: 0x00
NWK Creator Security: Start: 0x00
EMBER_NETWORK_UP 0x0000
NWK Creator: Form. Channel: 25. Status: 0x00
NWK Creator: Stop. Status: 0x00. State: 0x00

If you see the EMBER_NETWORK_UP, you can check the network settings with the command:

info

This will output network information. They key thing is that your device should have a panID and its nodeID should be 0x0000.

panID [0x06BA] nodeID [0x0000] xpan [0x(>)1989C1541BB9E874]

If this is all set, we can move over to the switch.

Putting the install code on the switch

As noted before, for the switch we are going to use an installation code (also known as an install code) to join our switch to our network. An install code is a means for a device to join a Zigbee network in a reasonably secure fashion. For a complete description of install codes, read AN1089 and this KBA, they will give you all of the details on using install codes.

The install code itself is a random value installed on the joining device at manufacturing time and is used to encrypt the initial network key transport from the coordinator to the joining device, via a unique link key. To emulate this, we are going to use commander to flash the install code onto our Thunderboard. We have included a file install.txt on this page to give you an install code to work with for this example. While you can use any code you want, this code matches the commands you will see in this example and will allow you to easily follow along with our example. To install this via commander, use this command:

commander flash --tokengroup znet --tokenfile install.txt --device efr32mg12p

Make sure to flash this onto your Thunderboard that is acting as your switch, it won’t hurt to have the install code on the light, but it has to be on the switch for this join process to work.

The output from commander will look very similar to when you flashed your application to the Thunderboard, but shorter. If you don’t see this output, make sure your Thunderboard is attached to your WSTK and that your WSTK is attached to your computer correctly. Once you have flashed the install code, you can check that it was stored correctly with the following command:

commander tokendump –-tokengroup znet –-device efr32mg12p

What you are looking for are two sections, at the top that you can see your EUI 64 and near the bottom, that the install code is stored on your device:

# MFG_EMBER_EUI_64     : C3A4DEFEFF570B00
…
#’MFG_INSTALLATION_CODE (Smart Energy Install Code)' token group
# Install Code Flags : 0x0002
Install Code       : 3141592653589793
# CRC                : 0xCE31

If you see this, the install code was correctly installed. You should run this command on your part as you will need your EUI64 for the next steps. NOTE: using the command, the EUI64 and CRC you see there are both in little endian format. Looking at this, the EUI64 is actually: 000B57FFFEDEA4C3 and our CRC is 0x31CE.

Joining the switch to the network

With this information, we will now return to our light. Our light is acting as the coordinator for our network, so It will need to know this information from our joining device. Specifically, it needs to the link key of the joining device. We are going to do a two-step process to get the link key and they move this key to the transient link key table of the light so that the information is changed after the switch joins.

From the light’s CLI, we are going to tell the light the EUI64, the install code and the CRC of the switch, from this information it will hash out the switch’s link key. To do this, enter the following on the light’s CLI:
Let’s look at this command a little closer, because there are a few things to note:

option install-code 0 {00 0B 57 FF FE DE A4 C3} {31 41 59 26 53 58 97 93 31 CE}

option install-code – this is simply the command which we are running, telling the coordinator we are adding an install-code based link key.

0 – This is the key table entry to add the entry to

{00 0B 57 FF FE DE A4 C3} – this is the EUI64 of the joining device. It is in big endian format. Note, this is the EUI64 of my joining device, you want to make sure to put your EUI64 here.

{31 41 59 26 53 58 97 93 31 CE} – this is our install code (the first 8 bytes) and the CRC (last 4 bytes) we are using. Note that our CRC is in big endian format.

If this command works correctly, you should see the following:

Success: add link key

From this we will then get our new link key from the key table. This is done from the CLI entering:

keys print

This command displays most of the security information for our network. What you are looking for on this display is the key table, which should display information like this:

Link Key Table
0     (>)000B57FFFEDEA4C3  00000000  L     y     FE 2A 47 BE 40 CC AE B2 DC 54 0E 0A EA DB 82 A1 
1/6 entries used.

This is the link key that was derived from the install code. Take note of this new link key, we are going to use it in a future step. With this, you want to delete the key from the permanent key table. To do this enter:

keys delete 0

Which tells the coordinator to delete our 0th entry from the key table.

Now we are going to join the switch to the network. We are also going to watch the process take place on network analyzer, so we can get a graphical representation of the joining process. So first, let’s start our capture. Because we are using an install code, Studio can’t natively see the joining process, so we need to put our install code into Studio. To do this, we need to open Studio’s preference, find the gear icon in Debug Adapter and click it.

This will launch the Preferences window. In the search window enter Security Keys, which should located it under Network Analyzer > Decoding. In that window click New and with the New security Key, enter your link key to allow Studio to be able to decode with it. Hit Apply and then OK to save this information.

Once the link key is added, we can start our capture. From Studio select our two WSTKs again like we did to launch the CLI. We are going to right click on them again, but instead select Start capture (if your environment is particularly noisy, you can select Start capture with options … and only capture off your particular pan ID). This will launch Network Analyzer, Silicon Labs network decryption tool. We won’t dive too deeply into the tool, but we will cover some parts as we work through this example.

At this point you might find it useful to organize Studio to allow you to see more of your windows than you had before. To move around views within Studio, you can drag them around by grabbing their tabs moving them to other areas. When they find a new location, you will see them leave an outline on the window. Since we want to see our network trace as well as both serial windows, you might find an arrangement like this better:

 

Now we want to return to the CLI of the light. Find the tab that contains the CLI for the light. We are going to open the network for joining and provide the link key of the joining device. We do this with a command from one of our plugins:

plugin network-creator-security open-with-key {00 0B 57 FF FE DE A4 C3} {FE 2A 47 BE 40 CC AE B2 DC 54 0E 0A EA DB 82 A1}

The first set of hex digits is the EUI64 of our joining device, the second is the link key that device will use when joinng. As before, make sure you put your own EUI64 in here. This command will add these keys and open our network for 255 seconds as well.

Now let’s go to the switch CLI. We need to start joining the network. In Zigbee 3.0 this is done by network steering, a plugin we added to our switch. So, in the CLI enter the following:

plugin network-steering start 0

Just like the name says, this starts the network steering process. The 0 option tells the switch to join with no additional options. The primary thing that this does is tell the joining device to change its install code after joining.

If you have arranged your windows as noted, you can watch the process take place in both CLIs and network analyzer. The key step is to watch the transport of the network key. Because have told our device to join with a particular link key, you can watch this key be used to transfer the network key to our device. You can follow other steps graphically, like the device announce of the switch to the network and the request and transport of a new link key.

Now that we have formed our network, it is time for us to start sending communications between our light and switch.

Project Overview

Previous Step
Next Step

Simplicity Studio can be utilized within Mac OSX to develop for Silicon Labs wireless mesh stacks (as well as all other Silicon Labs stacks). This guide will help you set up your development environment.

Download, Install Studio and Setup Studio

A full walk through of a Studio installation is beyond this KBA, this will highlight the primary points.

Studio can be downloaded from here. Once you download the file, you can open the file and then drag the Simplicity Studio application to your Applications folder.

Go to your Application folder and launch your new Simplicity Studio application. Once the application is open, this will start the update process for Studio. Follow the instructions for installing the wireless mesh stacks. If you don’t have access to these stacks, go to this link.

Installing Windows IAR

For compiling with Studio, you can utilize either GCC-ARM or IAR Embedded Workbench. If you want to install IAR (a Windows program), follow these steps:

First you will need to download a copy of IAR (see the above link for a download location). Use this KBA to note the version of IAR you need.

Studio comes with an installation of wine for running Windows applications within the OSX environment. Once Studio has completed installation, you should add the folder with wine to your PATH. This folder is located at:

/Applications/Simplicity Studio.app/Contents/Eclipse/support/common/wine/opt/local/bin/

You can add this to your PATH by editing your .bash_profile file within your user home directory. Using a text editor, add the following line to the file:

export PATH=$PATH:/Applications/Simplicity\ Studio.app/Contents/Eclipse/support/common/wine/opt/local/bin/

The next time you launch your terminal, you can see if this works by trying to run wine:

$ wine
Usage: wine PROGRAM [ARGUMENTS...]   Run the specified program
       wine --help                   Display this help and exit
       wine --version                Output version information and exit

If this works, navigate to the folder you downloaded IAR and run the installer via wine:

$wine EWARM-CD-8301-17148.exe

This will launch IAR in a Windows like environment. Follow the installer as you normally would (depending on version, this could take a while). 

NOTE: In Windows applications, they use the CONTROL key instead of the COMMAND key for many functions. So Cut, Copy and Paste are CTRL-X, CTRL-C and CTRL-V, respectively. This is primarily for adding license information to your IAR installation.

Other useful tools

Once Studio and IAR are installed, there are other useful tools which can be added to your PATH (.bash_profile) for ease of use:

Commander: The Silicon Labs programmer and chip debugger for the EFR32 family of chips

export PATH=$PATH:/Applications/Simplicity\ Studio.app/Contents/Eclipse/developer/adapter_packs/commander/Commander.app/Contents/MacOS

ISA3 Utilities: The Silicon Labs programmer and chip debugger for the EM35x family of chips

export PATH=$PATH:/Applications/Simplicity\ Studio.app/Contents/Eclipse/developer/adapter_packs/em3xx/utils/

 

Within EmberZNet and Silicon Labs Thread, different sleep modes are supported based on the particular chip you have selected for your product. This KBA will outline the different sleep modes within EM35x and EFR32 chips and how they are used within the stack.

EM35x

When utilizing Silicon Labs wireless mesh stacks, the EM35x supports two different sleep modes: Deep Sleep and Power Down. Both of these modes will get down to under 1 µA of current, with Power Down being able to realize lower current consumption.

Deep Sleep – EM35x SoC and EM35x NCP

This is the primary sleep mode of the EM35x. In this mode the EM35x will go into a lower current sleep mode by halting most peripherals, maintaining the ability to wake due to GPIO interrupts or a wake timer. This means that the EM35x can be woken by an external event, like a button press, or a scheduled event that is pending, such as polling event scheduled at set intervals.

This is the only supported sleep mode of any EM35x SoC design, utilizing the Idle/Sleep plugin, while it is one of two sleep modes that are supported by an EM35x NCP design, utilizing the sleep bits of the Frame Control bytes within the EZSP structure (see UG100: EZSP Reference Guide for full details).

Power Down - EM35x NCP only

This is a secondary sleep mode of the EM35x. In this mode the EM35x will go into a lower current sleep mode by halting most peripherals, including all timers as well. In this state only a GPIO interrupt can wake the EM35x.

This sleep mode is only supported in the EM35x NCP design as timer functionality can be offloaded to the Host processor, which can trigger polling or other scheduled events, utilizing the external interrupt to wake the NCP. This mode can be entered by utilizing the sleep bits of the Frame Control bytes within the EZSP structure (see UG100: EZSP Reference Guide for full details).

EFR32

Within EmberZNet and Silicon Labs Thread, the EFR32 can support two different sleep modes as well.

EM2 Deep Sleep – EFR32 SoC and EFR32 NCP

This is the primary sleep mode utilized by the wireless mesh stacks on the EFR32. In this mode the EFR32 will halt most peripherals and many timers, keeping only system necessary timers running. In this mode, the EFR32 maintains the ability to wake due to all interrupts or a wake timer and will resume operation as normal when waking from sleep.

To utilize this within an SoC design, use of the Idle/Sleep plugin is necessary. EM2 sleep can be utilized on SPI based NCP implementations through the sleep bits of the Frame Control bytes within the EZSP structure (see UG100: EZSP Reference Guide for full details).

EM4 Hibernate – EFR32 SoC only

EM4 is a special use case sleep mode that disables most functionality within the EFR32 and puts it into a hibernation state. In this mode the EFR32 can only be woken via a select GPIO wake mask or a system timer. Wake in this mode is treated like a reset of the processor.

To utilize EM4 sleep, you will need to enable the EM4 plugin with your application. You will need to further enable the emberAfOKToGoToEM4Callback() within your application’s callbacks. Within this function, you will enable the logic for which your application will enter into EM4 sleep.

NOTE: EM4 sleep is highly disruptive within normal operation of the stack use of it can result in an application that will have difficulty meeting Zigbee or Thread certification. It should only be utilized when this extremely low power mode is required and a well-defined state machine handling the sleep mode of the stack can be defined to govern the EFR32’s behavior.

Ideally, it is assumed that the source (generator) and load has 50Ω impedance, thus to transmit a signal from source to load without any losses, the transmission medium also must have 50Ω impedance.

Practically, the source / load impedance solely cannot be guaranteed to be 50Ω, hence additional impedance matching network is required in the circuit. Matching the impedance of complete RF path will make sure that there is minimum reflection loss and thus the antenna will resonate all of the incoming energy at its resonant frequency.

The RF path of EFR32 Series 1 can be divided into 3 parts as follows:

a) EFR32 Matching Network:

After performing load pull experiments, the optimum termination impedance of power amplifier was found as:

Case A: [Tx power level < +10dBm] ----> 20+j10Ω

Case B: [+20dBm > Tx power level > +10dBm] ----> 23+j11.5Ω

This impedance at the power amplifier should be matched to 50Ω to achieve the maximum power transfer from EFR to antenna. A low pass filter is used to transform this impedance and reject unwanted signals.

For case A, 2 element ladder LC low pass filter is enough to transform the impedance from 20+j10Ω to 50Ω. As max Tx power is limited to +10dBm, additional filtering is not required.
For case B, At higher Tx power, 2nd and 3rd order harmonics go beyond the allowable limit by the regulatory bodies. Hence suppressing higher order harmonics becomes important. To suppress these harmonics, a 3 element Pi filter is combined with the 2 element LC match which then results in a 4 element LCLC ladder that acts as a matching network and a low pass filter.

(For component values, detailed analysis and other types of EFR matching networks, Please refer AN930 rev 0.4 or later).

Thus the impedance at the end of EFR matching network in either case has been successfully transformed to ~50Ω.

b) Pigtail connection (Optional):

Even though pigtail connection is optional, we always recommend everyone to keep a provision for a U.FL connector and a series zero Ω resistor in their prototype design, this will allow the engineer to perform some RF tests such as measuring reflection loss, perform conducted test and etc.

This section is divided into 2 subsections:

i) U.FL connector:

To perform RF conducted test, a provision for U.FL connector can be helpful in the circuit. For this the series zero Ω resistor (3 - Res) has to be removed and it has to be placed at branched path towards U.FL connector. This will help us to ensure that the signal sent by the EFR RFIC is equal to the received signal at U.FL connector. Conducted test helps the engineer to verify that there are no reflection losses in the RF path between EFR and pigtail connection.

ii) Pigtail connector:

To measure reflection loss between pigtail connection and antenna, a pigtail connector is used. This can be done by removing zero Ω resistor (3 – Res) and soldering a pigtail connector at the second pad of the removed component. Please make sure that the metal jacket of the pigtail connector is properly soldered to ground pour from the pad till the edge of the board. By measuring the reflection coefficient, the antenna can also be matched to 50 Ω impedance.

This pigtail connection does not include any kind of impedance transformation, thus the impedance at the end of this network and before antenna is ~50Ω.

c) Antenna Matching Network:

The impedance of the antenna also solely cannot be guaranteed to be 50Ω, hence an additional matching network is required. We usually recommend a 3 element pi structured filter irrespective of the antenna type. Using a pigtail connector would be the starting stage of the antenna matching exercise. More information on the antenna matching network can be found at this KBA.

Please note that detailed design procedure and antenna tuning information for inverted F PCB antenna is given in AN1088.