There are 3 ways to request a device to leave the network, although none of them are perfect in that they do not guarantee the result of having a device exit immediately, or to force it to stay out of the network in the future ("kicking out a device").

Here are some descriptions of the leave request methods with pros and cons.

1) Send ZDO Leave to ZR parent with ZED's EUI as target
-Pros: Will always succeed (if ZED is still in the child table of ZR and ZR is reachable) with response status, regardless of what ZED's polling rate is.
-Cons: If ZED isn't polling parent regularly, parent's NWK Leave command to child could time out before child gets it, and child gets erased anyway. When child polls next time, parent will tell him to leave and rejoin because it's an non-child end device, so that gets you back to before the ZDO Leave.

2) Send ZDO Leave to ZED with ZED's EUI (or all-zero EUI) as target
-Pros: ZDO response clearly indicates whether ZED received the leave request. No confusion as above with ZED accidentally being told to rejoin.
-Cons: If ZED isn't polling parent regularly, it won't receive this request, so sender needs to be careful about timing of sending the request. In older EmberZNet stack versions (4.6 through 5.4), a bug existed that would sometimes reject a ZDO Leave Request sent to an end device depending on who was the sender. In EmberZNet versions 5.6.0 and earlier, the ZED won't get a ZDO Leave Response out before it leaves the network, so the requester must rely on the APS ACK rather than the ZDO response to confirm receipt.

3) Send APS Remove Device command (emberSendRemoveDevice) to ZR parent with ZED's EUI as deviceToRemove.
-Pros: APS-authenticated (unlike ZDO messages), so devices (even SE devices) can't choose to ignore this, and it is harder to spoof because it requires APS encryption.
-Cons: Need long address of child and parent for the command. No APS ACK available for APS commands, so can't confirm receipt by the parent. Still may encounter problem where parent deletes child before the child knows it was removed, causing child to rejoin on next poll attempt. Can only be sent by Trust Center.

In general, we recommend a fallback system, such as trying 2 and falling back to 1 (or 3) if it doesn't work.

Stack Migration Steps for Simplicity Studio 3.3

This discussion includes three kinds of migration simultaneously – changing projects from Ember Desktop to Simplicity Studio, updating from EmberZNet5.6.0.1 to 5.7.0, and changing platform from EM357 to EFR32. Some of the steps can be modified or left out if they are not germane. However, *items marked in bold with asterisks* are key to prevent compile or post-build errors.
For reference, this description was with a Studio download with public updates as of 5/26/2016, and I have EmberZNet 5.7.0-GA installed in C:\SiliconLabs\EmberZNet5.7.0-GA.

The technique is basically to move your existing project structure into the new stack, then use Studio to import it and make some changes.

• Move your project into \EmberZNet5.7.0-GA\app/builder\
For this example, this would look like \EmberZNet5.7.0-GA\app\builder\AppEM357\
If your project is already in the stack you want, create a working copy so you don’t damage the original, like \EmberZNet5.7.0-GA\app\builder\AppEM357Migration\
• Start Studio, and go to Simplicity IDE.
• Make sure C:\SiliconLabs\EmberZNet5.7.0-GA is added and detected in SDK preferences.
• Execute File >> Import >> Simplicity Studio >> MCU Project
• On the next wizard page, browse to the project file:
\EmberZNet5.7.0-GA\app/builder\AppEM357\AppEM357.isc
• On the next wizard page, choose the Kit, Part, SDK, Toolchain and Executable configurations. Many of these could be populated with cached values from what you were doing before, but those values do not necessarily represent the imported ISC configuration. This step lets you explicitly pick these options. In my case I am selecting the following:
      o Kit: EFR32 Might Gecko 2.4 GHz Mesh Networking Kit
      o Part EFR32MG1P132F256GM48, which is essentially set by the Kit selection
      o SDK: EmberZnet, which in this case refers to the \EmberZNet5.7.0-GA install location
      o Toolchain: IAR ARM
      o Build Artifact: Executable
      o Converted configurations: Debug (or Release)
• Click Next to specify project name and location
• The project name should have the same name as the project directory. It doesn’t *have* to but it’s highly recommended.
• *Uncheck Use default location and browse to the target directory (in this example \EmberZNet5.7.0-GA\app\builder\App_EM357\*
o In the upper section of the wizard page you will see a text telling you that the project location already has contents, and this perfectly acceptable in this case.
• Click Finish
• You will now get your project (App_EM357) in your Project view. Expand that project.
• Open the isc file, and you might see a message about the isc file being upgraded
• *On the General Tab, change Directory for generated files: to \EmberZNet5.7.0-GA*
• *On the HAL Configuration tab, change Selected Architecture to the EFM32 part, in my case it’s EFR32MG1P132F256GM48*
• Generate
• *By default, the App_EM357_board.h file comes up as not being selected for ‘Overwrite?’ operation, so you have to change that. Meaning, check the ‘Overwrite?’ box for App_EM357_board.h.* (You may need to go back and re-make any manual changes to the board header file you have made. If you are using EFR32 and need to modify the headers for custom hardware, doing so will be a different process from this migration to default headers.)
• Build

For proper operation of the EM3xx RF block, it is very important to minimize transmit frequency offset, as well as comply with the 802.15.4 specification of +/-40ppm.  The frequency offset is adjusted through the txtone (carrier tone) transmit function, as the 24MHz main clock offset directly relates to the transmitter frequency offset.

Use a spectrum analyzer to measure the frequency offset of the carrier. Set the amplitude reference level higher than the expected output power of the device in order to avoid possible damage to test equipment. For ceramic balun designs, this would be +10dBm, while for PA designs +30dBm should work fine as an initial setting and can be adjusted according to the actual PA TX power maximum capability.  Configure the radio to transmit a continuous unmodulated tone at 2445MHz by issuing the commands ‘setchannel 13’ and ‘txtone’ with the nodetest application installed on the device.  Measure the frequency offset by selecting the frequency counter setting on the spectrum analyzer followed by a marker peak search.  To determine the PPM of the frequency offset, use the following equation:

                Channel offset PPM = (expected / (measured – expected)) * 1E6

The frequency offset needs to be improved by adjusting the crystal loading caps only if it appears it will not comply with the +/- 40 PPM 802.15.4 specification. The intent is to tune the frequency to be as close to the desired frequency as possible.  Refer to AN700 section 2.6, Transmit Frequency test http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf and KBA article EM35xx-24MHz Crystal Selection http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24-MHz-Crystal-Selection/ta-p/144602 for additional information.

Some customers testing EM3xx device transmit functionality over temperature observe transmit issues such as signal degradation and varying frequency offsets during large changes in temperature. This happens when the customer places the device in a continuous transmit mode, for example with standalone tx, txtone or txstream test modes using the nodetest application or manufacturing library based test commands in the customer's application, and then change the temperature without exiting the continuous transmit mode.  This test method, where the device resides in a continuous transmit mode, does not reflect the device’s normal transmit behavior as it would function in a real application.

The reason for the customer seeing these performance issues is the device is not able to recalibrate the channel when left in this continuous transmit mode and recalibration is not triggered when the temperature changes. When a device is powered up for the first time after programming and it selects a channel, a calibration is run automatically for proper configuration of the device. This calibration occurs the first time each channel is selected (since default channel calibration token data exists for that channel in simulated EEPROM), as well as any time there is a change in temperature (when compared with the temperature at the time of the previous calibration event) which is large enough to trigger recalibration.

Silicon Labs recommends not to remain in a continuous transmit mode while changing temperature.  We recommend instead to bring the unit to the desired temperature, start the continuous transmit mode, take the desired test measurement, exit / stop the transmit mode, move on to the next temperature set point, and repeat.  This allows all channel calibration checks and events to occur normally, thus allowing transmit operation to function normally at all test temperatures.

Related articles:

http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24MHz-Crystal-Tuning/ta-p/157154

http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24-MHz-Crystal-Selection/ta-p/144602

Related application note:

http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf