答案

    芯科并没有提供具有天线分集的EFR32MG参考设计。但是，你可以以EM35x的天线分集设计作为例子，比如如何选用外部的RF开关。自EmberZNet 5.7.4 版本协议栈起，对发射/软件分集（当MAC—Level的ACK没有收到时切换天线路径）就开始有了支持，并且通过天线插件（Antenna plug-in）的选择/配置任何的GPIO都可用来做天线选择功能。接收/硬件分集（对到来的数据包的RSSI值做评估从而选择最强的路径）功能是不支持的。也就是说，在设计中通过MODEM_ANT0和MODEM_ANT1 两个GPIO选择 (在有两个天线选择GPIO和一个外部RF开关情况下)来保证发射/软件分集暂时可用，如果将来加入了接收/硬件天线分集功能，可以通过软件升级来支持该功能。请参考EFR32MG1规格书的表6.5来了解哪些GPIO具有MODEM_ANT0 和 MODEM_ANT1功能的详细内容。 
    就硬件的建议上，天线应该分开至少1/4波长的距离，而且应相互转成90度。请参考上述的EM35x天线分集设计作为例子。

英文原文：

      https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2016/11/09/how_can_i_implement-hsvn     

Some customers need a blacklist mechanism in a ZigBee network. For example:

1. Prevent specific devices from joining.
2. Filter messages from a specific node ID.
3. Prevent devices from joining into a specific PAN.

Here is an example to show you how to use blacklist in EmberZNet.

The mechanism is implemented by a plugin “MAC Address Filtering”. There are three lists in the plugin, short address list(2-byte node ID), long address list(64-bit IEEE address) and PAN ID list(2-byte PAN ID). Each list can be configured as either a whitelist or a blacklist. The default is a blacklist with no addresses configured (accept all packets normally).  There is also a separate option to allow or drop packets with no address information (e.g. Beacon Requests). 

To use this mechanism, you must enable the plugin “MAC Address Filtering” first:

Then build and program the application to your device.

• Filter by long address

If you want to block the device with EUI64 90FD9FFFFE7B81BD , then you can run the following commands on the console:

plugin mac-address-filtering long-address-list add {90FD9FFFFE7B81BD}

plugin mac-address-filtering long-address-list set-blacklist

Then the devices won’t response to the association request from the specific long address:

A statistics info shown as below:

• Filter by short address

If you want to filter devices by short address 0xA88F,  you can run the following commands on the console:

plugin mac-address-filtering short-address-list add 0xA88F

plugin mac-address-filtering short-address-list set-blacklist

A statistics info shown as below:

• Filter by PAN ID

If you want to filter specific PAN ID 0xF459, then you can run the following commands on the console:

plugin mac-address-filtering pan-id-list add 0xF459

plugin mac-address-filtering pan-id-list set-blacklist

The device won’t send an association to the filtered PAN:

A statistics info shown as below:

• Filter no address packets

If you want to filter beacon request, you can run the following commands on the console.

plugin mac-address-filtering set-config no-address-filter

Then the router won’t response to the beacon request:

A statistics info shown as below:

Please note that in the “MAC Address Filtering” plugin, all lists are cleared at system startup, so if you want to add some blacklist items permanently, you can make a modification in the source code. The source code of the “MAC Address Filtering” plugin can be found at:

SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\protocol\zigbee\app\framework\plugin-soc\mac-address-filtering\mac-address-filtering.c

You can modify the code if you want to set some specific items of the list in runtime.

e.g (mac-address-filtering.c)

//list of EUI64 to be filtered
EmberEUI64 blacklist_eui64[] = {
    {1,1,1,1,1,1,1,1},
    {2,2,2,2,2,2,2,2},
    {3,3,3,3,3,3,3,3},
};

void emberAfPluginMacAddressFilteringInitCallback(void)
{
  uint8_t i = 0;
  uint8_t size = sizeof(item) / sizeof(EmberEUI64 );

 assert(size <= EMBER_AF_PLUGIN_MAC_ADDRESS_FILTERING_LONG_ADDRESS_FILTER_LENGTH);

  MEMSET(&macAddressFilterData, 0, sizeof(MacAddressFilterGlobals));
  macAddressFilterData.options = MAC_FILTER_OPTIONS_DEFAULTS;
  clearShortFilterList();
  clearLongFilterlist();
  clearPanIdFilterList();

for (i = 0; i < size; i++)
{
    MEMCOPY(macAddressFilterData.macLongAddressList[i].longAddress,  blacklist_eui64 [i],   EUI64_SIZE);
    macAddressFilterData.macLongAddressList[i].matchCount = 0;
}

  //enable as blacklist
  changeListConfig((macAddressFilterData.options
                    & MAC_FILTER_OPTIONS_LONG_ADDRESS_WHITELIST),
                   MAC_FILTER_TYPE_LONG_ADDRESS,
                   MAC_FILTER_OPTIONS_LONG_ADDRESS_WHITELIST);

}

A step-by-step guide to creating, building, and running your own Router Eligible End Device (REED) application based on the Silicon Labs Thread stack. Before tackling this tutorial, please checkout "Building a Thread Router Eligible End Device Application" Part 1 and Part 2 tutorials first. This tutorial expands on Part 2 by adding a button event for the LED toggle and capturing the associated network traffic.

Requirements:

Software:

• Simplicity Studio v4
• Silicon Labs Thread Stack 2.7.1
• IAR Workbench 7.80.4
• Generated project for Router Eligible End Device from Part 1 and Part 2.

Hardware:

• EFR32MG Wireless Starter Kit (WSTK)

I. Updating Configuration for the Reed
  1. Go back to the ISC configuration file we have been working on (ThreadReed271EFR32).
  2. Navigate to the "Callbacks" tab.
      a. Select "halButtonIsr".
  3. Under the "Other" tab:
      a. Add an Event item under Event Configuration section. This will link an event to a button press.
          i. Set Command to "eventToggle".
          ii. Set Callback to "eventToggleHandler".
  4. Click "Generate". AppBuilder will ask you to validate the generation to make sure which files can be overwritten. Make sure thread-callbacks.c is UNCHECKED. Click OK.
  5. In the "Generation successful" window click OK.
  6. Save the ISC file.

II. Add Code and Build Project in Simplicity Studio IDE
  1. In thread-callbacks.c add the following code to have the node send out a CoAP Broadcast message.

static const EmberIpv6Address allMeshNodes = {
  {0xFF, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,}
};

static const uint8_t reedToggleUri[] = "reed/toggle";
EmberEventControl eventToggle;

void eventToggleHandler(EmberStatus status) {
  emberEventControlSetInactive(eventToggle);

  halToggleLed(BOARDLED0);
  
  emberAfCorePrint("Broadcast to ");
  emberAfCoreDebugExec(emberAfPrintIpv6Address(&allMeshNodes));
  emberAfCorePrintln("");
  EmberCoapSendInfo info = {
    .nonConfirmed = true,
  };
  char valueString[1] = "1";
  status = emberCoapPost(&allMeshNodes, // destination
                         reedToggleUri, // URI
                         (uint8_t const*)valueString, // body
                         strlen(valueString), // body length
                         NULL, // handler
                         &info); // CoAP config
  emberAfCorePrintln("status = 0x0%d",status);
}

 2. In thread-callbacks.c add interrupt service routine for the button states.

void halButtonIsr(uint8_t button, uint8_t state) {
  if ((state == BUTTON_PRESSED) && (button == BUTTON0)){
    emberEventControlSetDelayMS(eventToggle, 10);
  } else if ((state == BUTTON_PRESSED) && (button == BUTTON1)) {
    emberResumeNetwork();
  }
}

 3. Compile your project and Ensure that the build completes with zero errors.

III. Load Application to All WSTKs
  1. In Network Analyzer perspective, click on a node for your application and select "Flash/Upload".
  2. Upload only the updated application. This time DO NOT erase the chip because we want to keep the network parameters saved in non-volatile memory.
  3. Repeat for all nodes.

IV. Capture Network Traffic
  1. Set Network Analyzer decode to the appropriate Thread stack by going to Window -> Preferences -> Network Analyzer -> Decoding -> Stack Versions. (Please note, there is an auto-detection decoder stack however, if you have multiple protocols in the air in your space, then we recommend selecting the specific stack).
  2. Make sure your master-key is available in Window -> Preferences -> Network Analyzer -> Decoding -> Security Keys. If it is not there add a new security key by clicking on the "Add" button.
  3. In Network Analyzer perspective, in the Device view, right-click on a node and select "Start capture with options"
      a. May need to select "Connect" first if icon beside node name is not showing green.
  4. In capture options specify PAN ID. This allows you to narrow the data captured to the specific PAN ID.

V. Bringing the Reed Back into Network
  1. In console bring the node back up by using the resume command. Either use the following command or press PB1 on WSTK (button 1).

network-management resume

  2. Do this for all nodes. Management traffic should start showing in the network capture.

VI. Sending Messages
  1. Press Button0 on WSTK board. Console will print when the node is broadcasting. Nodes with URI "reed/toggle", will toggle their LEDs. The network capture will show CoAP POST messages with acknowledgements.

A step-by-step guide to creating, building, and running your own Router Eligible End Device (REED) application based on the Silicon Labs Thread stack. Before tackling this tutorial, please checkout "Building a Thread Router Eligible End Device Application" tutorial first.

This tutorial expands on Part 1 by adding a handler for a received CoAP message.

Requirements:

Software:

• Simplicity Studio v4
• Silicon Labs Thread Stack 2.7.1
• IAR Workbench 7.80.4
• Generated project for Router Eligible End Device.

Hardware:

• EFR32MG Wireless Starter Kit (WSTK)

I. Updating Configuration for REED
  1. Go back to the ISC configuration file we created in the previous exercise (ThreadReed271EFR32.isc).
  2. Navigate to the "Plugins" tab:
      a. Select "CoAP Dispatch".
        b. Remove "CoAP Debug" as there are some conflicts.
  3. Under the "Other" tab:
      a. Add a CoAP Dispatch item.
          i. Change Method to POST.
          ii. Change URI Path to "reed/toggle".
          iii. Change Handler to "reedToggleHandler".
  4. Click "Generate". AppBuilder will ask you to validate the generation to make sure which files can be overwritten. Make sure thread-callbacks.c is unchecked. Click OK.
  5. In the "Generation successful" window click OK.
  6. Save the ISC file.

II. Add Code and Build Projects in Simplicity Studio IDE
  1. In thread-callbacks.c add the following code to have the node respond to CoAP messages. This Handler will respond to "reed/toggle" URI, toggle an LED on the WSTK, and print a statement to the console.

void reedToggleHandler(EmberCoapCode code,
                uint8_t *uri,
                EmberCoapReadOptions *options,
                const uint8_t *payload,
                uint16_t payloadLength,
                const EmberCoapRequestInfo *info) { 
  
  emberAfCorePrintln("Toggle LED");
  halToggleLed(BOARDLED0);
  emberCoapRespondWithCode(info, EMBER_COAP_CODE_204_CHANGED);

}

  2. Build your project and ensure that it completes with zero errors.

III. Load Application to All WSTKs
  1. In Network Analyzer perspective, click on a node for your application and disconnect from the device (for the EFR32). Then select "Flash/Upload".
  2. Upload only the updated application. This time DO NOT erase the chip because we want to keep the network parameters saved in non-volatile memory.
  3. Repeat for all nodes.

IV. Bringing Nodes Back Into the Network
  1. In Network Analyzer perspective, navigate to the node's console and use the resume command

network-management resume

  2. Do this for all nodes.

V. Sending CoAP messages
  1. In the console send a CoAP POST message to your neighbor using their IP address and unique URI to toggle the LED. This CoAP POST message will toggle LED0 on the WSTK and print out "Toggle LED" on the receiving node.

coap post <destination> <uri> <body>

    Example:

coap post "fd00:db8::d9dd:b493:143b:9cbc" "reed/toggle" "1"

VI. Expanding application

The third part of this tutorial adds functionality to the sending node.

Question

Which GPIOs are used on the EM35X NCP-UART and NCP-SPI?

Answer

For the pre-built NCP images we include in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.1\protocol\zigbee_5.10\ncp-images

NCP-UART:

• PB1 – TXD
• PB2 – RXD 
• PB3 – CTS
• PB4 – RTS 

NCP-SPI:

• PA0 – MOSI 
• PA1 – MISO 
• PA2 – SCLK
• PA3 – nCS
• PB2 – nHOST_INT
• PB6 – nWAKE

1. Enable the Centralized Network Initiator Support option in ZLL Commissioning plugin. If this option is disabled, the coordinator will not be as an initiator.

2. Issuing the CLI command <plugin zll-commissioning link> on the coordinator. The target device will be added to the centralized network.

Question: Was the coordinator able to be as the target and the joining device as the initiator?

Answer: No, if the coordinator is the target, it will be stolen from the centralized network. and the coordinator will not be able to communicate with the nodes in the previous network

You may meet problem when you develop the project with IAS zone server in EmberZnet 6.3.1. The IAS zone server plugin is grayed and can't be chose even you enable the IAS zone server cluster in *.isc file.

This is a known bug in EmberZnet 6.3.1, and it is easy to fix it by deleting `emberAfWwahAppEventRetryManagerConfigBackoffParamsCallback`and `emberAfWwahAppEventRetryManagerSetBackoffParamsToDefault` from the implemented callbacks in plugin.properties.

I also attach the plugin.properties, so that you can easily to replace the plugin.properties in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\protocol\zigbee\app\framework\plugin\ias-zone-server\.

After you do that, restart the Simplicity Stduio, and the  IAS Zone Server plugin is appeared now.

Please feel free to contact Silicon Labs if you have further problem. 

This is an example to demonstrate a trust center swap out with the EmberZNet 6.3 stack, Zigbee 3.0, and a SoC configuration for the trust center node. It completes that task by providing a CLI-based interface for both printing and saving necessary trust center parameters and restoring the network.

This project was built for trust center replacement with a SoC setup on EmberZNet 6.3, but it can be adapted easily for individual use cases.

To leverage the attached demonstration code, create a Zigbee 3.0 SoC application with the plugins necessary for the particular trust center instance (likely Network Creator, etc.) and ensure that both Serial and Simulated EEPPROM are included and that command line communication is possible. Then, place the source code into the callbacks file of the application and also include the header file. To print individual trust center parameters, uncomment DEBUG on the first line of the header file to access additional commands.

Usage and Test Procedure

To perform a basic trust center swap out, incorporate the source code and the header file into the application associated with the trust center of the current network. To display the parameters of the live network, use the command "custom trust-center-swap-out print all" to print the current network parameters - copy these to a file or some other easy-to-access location. Then, replace the hardware, flash the device with this same application, and use "custom trust-center-swap-out save " for each parameter (the exact naming can be found under the "save" sub-menu). Note that the eui64, extended PAN ID, network key, and global key all need to be passed as hex strings (enclosed by brackets with spaces separating each bit). Once each of these has been saved (and their values can be confirmed with the command "custom trust-center-swap-out print backup"), restore the network with the command "custom trust-center-swap-out restore all".

A basic test procedure with two individual nodes (one trust center node and one joining node) can validate the functionality of the trust center swap out:

To create the two nodes in the network:

1. Mass erase the flash memory on both of the chips. In commander, the command is: "commander device masserase".
2. Flash an SoC application incorporating the sample code onto one of the nodes - this device will act as the trust center. In Simplicity Commander, the command to flash firmware onto a board is "commander flash /path/to/image".
3. Flash firmware onto the other node - this device will join the network. While any image should work, the most straightforward method is to use the default Z3Switch SoC image. In Simplicity Commander, the command to flash firmware onto a board is "commander flash /path/to/image".

To create the network:

1. Open the serial console to connect to the trust center node. Start the network with the command "plugin network-creator start 1".
2. Use "keys print" to get the link key for the network.
3. On the side of the joining node, open Simplicity Studio. Add the key through File - Preferences - Network Analyzer - Decoding - Security Keys.
4. On the host-NCP side, open the network using "plugin network-creator-security open-network".
5. Get the PAN ID of the network with the command "info" on the trust center side. On the joining node side, connect to the device and start capturing on that PAN ID.
6. To join the network from the joining node, use the Serial interface and the command "plugin network-steering start 0".
7. Once they connect, try sending packets between each of the nodes to ensure that they are able to communicate.

To save the current network parameters.

1. Print the current network parameters to ensure that they reflect what the backup copy should contain using the command "custom trust-center-swap-out print all".
2. Manually record the printed parameters by copying them to a text file.

To temporarily disable the network and simulate a hardware replacement:

1. Mass erase the trust center node, and be sure to erase the tokens as well. The commands are "commander device masserase" and "commander device pageerase --region @userdata".
2. Re-flash the trust center node with the original image.

To re-populate the backup data:

1. Reconnect to the trust center node with the serial interface.
2. For each trust center parameter manually saved from the origin network, use the command "custom trust-center-swap-out save ".
3. Confirm that the values have been saved correctly with the command "custom trust-center-swap-out print backup".
4. Restore the network with "custom trust-center-swap-out restore all".
5. Reconnect to the joining node and rejoin the network with the command "network rejoin 0 0"
6. Once the node has joined, send a few messages to ensure that the connection has been restored.

For more details, see the attached README and header file

This is an example to demonstrate a trust center swap out with the EmberZNet 6.3 stack, Zigbee 3.0, and a Host-NCP configuration for the trust center node. This sample application code completes that task by saving the restoration data to a text file (assuming that the host has a filesystem) and reloading network parameters from this file or through means of a CLI and manual recording and upload.

This project was built for trust center replacement with a Host/NCP setup on EmberZNet 6.3, but it can be adapted easily for individual use cases.

To leverage the sample app code, place the source code into the callbacks file of the application and also include the header file. To gain access to  structures such as the restoration data structure during the session, uncomment the first line of the callbacks.c file to enable DEBUG features. DEBUG features include a CLI means for extracting current trust center parameters, manually setting the values of parameters in the data restoration structure, changing loaded trust center parameters, etc.

Usage and Test Procedure

To perform a basic trust center swap out, incorporate the source code and the header file into the application associated with the trust center of the current network. To display the parameters of the live network, use the command "custom trust-center-swap-out print all" to print the current network parameters - copy these to a file or some other easy-to-access location. Then, replace the hardware, flash the device with this same application, and use "custom trust-center-swap-out save " for each parameter (the exact naming can be found under the "save" sub-menu). Note that the eui64, extended PAN ID, network key, and global key all need to be passed as hex strings (enclosed by brackets with spaces separating each bit). Once each of these has been saved (and their values can be confirmed with the command "custom trust-center-swap-out print backup"), restore the network with the command "custom trust-center-swap-out restore all".

A basic test procedure with two individual nodes (one trust center node and one joining node) can validate the functionality of the trust center swap out:

To create the two nodes in the network:

1. Mass erase the flash memory on both of the chips. In commander, the command is: "commander device masserase".
2. Flash an SoC application incorporating the sample code onto one of the nodes - this device will act as the trust center. In Simplicity Commander, the command to flash firmware onto a board is "commander flash /path/to/image".
3. Flash firmware onto the other node - this device will join the network. While any image should work, the most straightforward method is to use the default Z3Switch SoC image. In Simplicity Commander, the command to flash firmware onto a board is "commander flash /path/to/image".

To create the network:

1. Open the serial console to connect to the trust center node. Start the network with the command "plugin network-creator start 1".
2. Use "keys print" to get the link key for the network.
3. On the side of the joining node, open Simplicity Studio. Add the key through File - Preferences - Network Analyzer - Decoding - Security Keys.
4. On the host-NCP side, open the network using "plugin network-creator-security open-network".
5. Get the PAN ID of the network with the command "info" on the trust center side. On the joining node side, connect to the device and start capturing on that PAN ID.
6. To join the network from the joining node, use the Serial interface and the command "plugin network-steering start 0".
7. Once they connect, try sending packets between each of the nodes to ensure that they are able to communicate.

To save the current network parameters.

1. Print the current network parameters to ensure that they reflect what the backup copy should contain using the command "custom trust-center-swap-out print all".
2. Manually record the printed parameters by copying them to a text file.

To temporarily disable the network and simulate a hardware replacement:

1. Mass erase the trust center node, and be sure to erase the tokens as well. The commands are "commander device masserase" and "commander device pageerase --region @userdata".
2. Re-flash the trust center node with the original image.

To re-populate the backup data:

1. Reconnect to the trust center node with the serial interface.
2. For each trust center parameter manually saved from the origin network, use the command "custom trust-center-swap-out save <VALUE>".
3. Confirm that the values have been saved correctly with the command "custom trust-center-swap-out print backup".
4. Restore the network with "custom trust-center-swap-out restore all".
5. Reconnect to the joining node and rejoin the network with the command "network rejoin 0 0"
6. Once the node has joined, send a few messages to ensure that the connection has been restored.

For more details, see the attached README and header file.

As you know, the OTA file will be created automatically after enable the OTA Client related plugins in *.isc file. This is because there is a script (Z3LightSoc-postbuild.py) running after the project building succeed. Sometimes, you may want to create an OTA from the existed *.gbl file directly, instead of re-building the project again. During this article, we are talking about how to create an OTA file manually.

1. First, we need the tool image-builder-xxxx to create the OTA file, which can be  found in the directory as below:

   C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\protocol\zigbee\tool\image-builder

    

2. There are two version of the image-builder-xxxx, one is for Linux and another is for Windows.
   • image-builder-linux
   • image-builder-windows.exe
3. In this KBA, I use image-builder-windows.exe in Cygwin. Launch cmd.exe and go to the directory of image-builder, type“image-builder-windows.exe -h” to get the details of the tool: 

   

4. Create OTA file with the following command: 

   >image-builder-windows.exe --create "Z3LightSoc.ota" --version 3 --manuf-id 0x1002 --image-type 0 --tag-id 0x0000 --tag-file Z3LightSoc.gbl

   

    

5.  Then we can see the OTA file is created. Use “-p” to print the info the OTA file. 

   

    

6. More information please refer to the attached Image-Builder-Instructions.pdf