How often you poll will depend on your application’s requirements as well as your desired battery life or power constraints.
There are certainly worst-case values for how long your end devices can go without polling, and these are discussed in the FAQ How long can my end device go without polling its parent? What happens after that timeout?. However, for determining how often the end device should poll, it is important to consider the Indirect Transmission Timeout, which dictates how long a parent will hold onto a packet for relaying to its child before the message is discarded. While this timeout is configurable (via the EMBER_INDIRECT_TRANSMISSION_TIMEOUT or EZSP_CONFIG_INDIRECT_TRANSMISSION_TIMEOUT), ZigBee Pro PICS (the conformance specification) dictates a prescribed value of 7.680 seconds for this timeout and therefore recommends polling at least once per 7.5 seconds to ensure reliable communication, since polling outside of this timeout can result in missed messages or missed APS ACKs.
If you are implementing an application under an official ZigBee application profile, the profile specifications generally contain more guidance about suitable rates of polling.
For example, in Smart Energy (SE), looking at the latest SE spec as of this writing (075356, revision r15), Section 5.2 (concerning stack profile features) says the following about recommended rates of polling:
In their normal operating state, ZigBee end devices shall poll no more frequently than once every 7.5 seconds except where this specification indicates otherwise for a particular device description, or under the following conditions.
•ZigBee end devices may operate with a higher polling rate during commissioning, network maintenance, alarm states, and for short periods after transmitting a message to allow for acknowledgments and or responses to be received quickly, but they must return to the standard rate indicated previously during normal operation.
•It is recommended that ZigBee end devices poll much less frequently than once per 7.5 seconds, especially when the device normally only communicates due to user interaction. To further clarify, except for one condition in the Simple Metering cluster (refer to DD.3.3), all cluster interactions that read or write attributes, or cause command exchanges should limit transactions to once every 30 seconds.
Section 5.3.4 (End Device Parameters) also briefly mentions polling, saying that 'an end device that is designed to receive data should poll its parent every 60 seconds', which seems to contradict the 7.5 seconds, but that same table (Table 5.4) also contains a 'Value' field for that parameter, which says 'Set by stack profile', so the Stack Profile section (5.2 as quoted above) takes precedence here.
An informal interpretation of all this would be that your end device should operate in one of a few poll intervals depending on what’s going on:
•If your device never receives data except in response to something (which seems unlikely in the SE profile, where the ESP may send DRLC events asynchronously), it only needs to poll rarely (to stay connected to the network and pick up the occasional network-wide events, like channel/key/PANID changes), except when waiting on ACKs/responses for things it sent.
•If your end device expects to receive occasional asynchronous transmissions (like commands or reports) from other devices, it should poll at least once a minute to increase the likelihood of catching these events (bearing in mind that any poll rate beyond once per 7.68 secs cannot ensure reliable delivery, but if you’re lucky you might catch the incoming event, especially if it’s being retried every 9 seconds or so, which is contingent on APS retries being enabled and the sender knowing you’re a sleepy device).
•If your end device needs to participate in a reliable APS transaction with another node, such as during a command/response exchange, commissioning, key establishment or service discovery process or anything where asynchronous transmissions are sent to this end device regularly, it should poll about once per 7.5 seconds to make sure it gets the messages and ACKs them in a timely manner.
•If your end device is undergoing some low-latency or high-bandwidth process, like streaming of data, firmware uploading, joining/rejoining, or the 'real time feedback' loop described in Section D.3.3.2, it should probably poll more often (like once every 1-2 seconds) to reduce latency and maximize throughput.
This may be a bit vague and perhaps somewhat confusing, but this is ZigBee SE’s attempt to balance flexibility (and varying battery life requirements) with reliability and standards-based interoperability, so ultimately the application developer has to make his/her own choices about what specific poll rates to use under which circumstances.
For more information on polling, especially regarding HA1.2, please see:
How do I enable Boost Mode or an External PA on Ember EM3xx chips?
The EM3xx chipset is capable of entering a special 'boost' mode, where higher transmitter output power levels are available at the expense of significantly more current consumption. In this mode, receiver sensitivity is boosted by 1 to 2 dBm, and as a secondary side effect, normal TX output power at a given software txPower setting is increased by approximately 0.5 dBm. Additionally, the EM3xx chips allow the use of an external power amplifier circuit (via the TX_ACTIVE pin and RF_TX_ALT_P/RF_TX_ALT_N pins).
Note: When you set the radio’s transmitter output power to something higher than 3, the TX boost power levels (up to +8 dBm) are automatically available regardless of engaging the Boost Mode for the RX side.
In the EmberZNet API, these options are configured via the emberSetTxPowerMode() API, shown below. Refer to the EmberZNet Stack API Guide (ember.h file reference) for your software release for most accurate details about the usage for this function and the available txPowerMode enumerations.
EmberStatus emberSetTxPowerMode ( int16u txPowerMode )
If you are using the EZSP interface to communicate with a network coprocessor, the Boost Mode and External PA options are configured via the SetConfigurationValue transaction, through EZSP_CONFIG_TX_POWER_MODE option, which accepts a variety of option masks, similar to the ones used by emberSetTxPowerMode(), which are enumerated as EMBER_TX_POWER_MODE_xxx definitions. For more details about this usage, refer to the EZSP Reference Guide (UG100) describing the version of EZSP you are using on your device.
Note that the EmberZNet stack will enforce a txPowerMode value reflected by the MFG_PHY_CONFIG manufacturing token (with the bits inverted so that the default token value of 0xFFFF corresponds to txPowerMode 0×0000) as soon as emberInit() is called (if running your own application with the EmberZNet API) or the NCP application boots up (if using EZSP). If an EmberZNet application wishes to override this setting with its own txPowerMode, it should do so after calling emberInit() so that the desired setting is not overridden by the default.
If you are using Silicon Labs’ NodeTest firmware to perform low-level functional testing of your EM3xx device, the Boost Mode and External PA options can be enabled via the SetTxPowMode command through the program’s serial interpreter. This command takes two numeric arguments, interpreted as boolean (0=FALSE, 1=TRUE) values. The first argument controls whether the chip’s Boost Mode (for both RX and TX) is enabled. The second argument controls whether the external PA circuitry is enabled. For example, to enable Boost mode and use only the internal amplifier (no external PA), use the following command:
More details about using NodeTest can be found in the Bringing Up Custom Devices For EM3xx application note (AN710).
What are the different levels of debug in the EmberZNet and Silicon Labs Thread stacks, what features are enabled, and how do I access them?
Here is a summary of the three different debug options and how to access them.
Note: The Packet Trace Interface (PTI) provided on PTI_FRAME and PTI_DATA (also called FRC_DFRAME and FRC_DOUT) pins is a separate peripheral configured in the HAL and isn't affected by the choice of debug levels below.
•NO DEBUG: Select this by disabling both the Debug Basic Library and the Debug Extended Library. This causes the firmware not to use SWDIO or SWO at all for communications at runtime, but the Debug JTAG. PTI ("Packet" events in Network Analyzer) will still be available if the peripheral is enabled, however.
•BASIC DEBUG: This is the default behavior for new application configurations. This requires the Debug Basic Library plugin and the Debug JTAG plugin. Basic debug includes the following features:
1.node reset message ("Reset" events) with "ZnetVer" events to track stack version at init time
2.the assert output ("Assert" events)
3.core dump output ("CoreDump" events)
4.virtual UART input and output ("Printf" events) when "serial 0" port is enabled
5.basic node information request and response ("NodeInfo" events)
6.EZSP command and response transactions ("EZSP" events)
•FULL DEBUG : This is a superset of Basic Debug functionality and requires adding the Debug Extended Library plugin to the above prerequisites of Basic Debug. Added features in this mode include:
1.API call trace output ("APITrace" events)
2.debug error output (some additional "Printf" events)
3.debug printf output ("Debug" events) from emberDebugPrintf()
I am selecting the crystal for Si443x now and I want to know whether the Si443x's oscillator have the limitation on the maximum of drive level. I read the datasheet of the crystal you recommended in AN417 and its values vary from 100 to 200uW.
Could you please give more details/advise on this?
First of all here is the definition of the crystal drive level:
'Drive level indicates power consumption by crystal resonator while oscillation circuit works.'
So this is more likely a limitation of the crystal not the radio chip's oscillator. Considering that we run the crystals in parallel mode, and the crystal's has big Q, the _current_ running through the crystal is expected to be quite low. According to the function: Pdrive_level=I^2*Resr, drive level more likely could cause problems during series operation modes (eg.: different applications of the crystal), when higher currents flow.
So basically in this parallel operation of the crystal you do not have to worry about the drive level overload (we did not experience / got feedback at all about this problem in the past).
Where can I find RF matching values for the Si102x / Si103x / Si106x / Si108x wireless MCU family?
The Si102x and Si103x Wireless MCU devices are based on Si4431 or Si4432 radios. Application notes written for the Si443x devices also apply to the Si102x and Si103x Wireless MCUs.
Similarly, the Si106x and Si108x Wireless MCU devices are based on Si4455, Si4460 or Si4463 radios. Application notes written for the Si4455 / Si446x devices also apply to the Si106x and Si108x Wireless MCUs.
The Si1020/21/22/23 and Si1030/31/32/33 devices are based on the Si4432 +20dBm radio. These designs should use a TX/RX RF front end topology, described in AN427 and AN435.
The Si1024/25/26/27 devices and the Si1034/35/36/37 are based on the Si4431 +13dBm radio. These designs should use a Direct Tie RF front end topology, described in AN427 and AN436.
The Si1060/61 and Si1080/81 are based on the Si4463 +20dBm radio. These designs should use RF front end topologies described in AN643 and AN648.
The Si1062/63 and Si1082/83 are based on the Si4460 +13dBm radio. These designs should use RF front end topologies described in AN643 and AN627.
The Si1064/65 and Si1084/85 are based on the Si4455 +13dBm radio. These designs should use RF front end topologies described in AN643 and AN693.
All application notes include suggested starting component values for various frequency bands.
Beside these application notes, reference design files for Si102x/3x/6x/8x RF Evaluation Boards that are available on the Silicon Labs website can be used as a starting point for matching network component values.