Is it possible to obtain an inventory of all the nodes in a ZigBee network?
In our ZigBee stack, there is no active list of all of the devices being maintained at any point. So any network list would have to be custom code.
If your device is the coordinator of the network, you can get access to the node ID and EUI64 of each device as it joins the network via the emberAfTrustCenterJoinCallback().
However, if you don't gather this information during the joining process for each device, you need to find out the nodes in the network using the ZDO LQI Table Request (which provides details about the neighbors and children of each router), which is a more difficult and slower process. See emberLqiTableRequest() API in app/util/zigbee-framework/zigbee-device-common.h for an interface to transmit this LQI Table Request to other devices. Details about the frame format of the request and response can be found in stack/include/ember-types.h; search for LQI_TABLE_REQUEST.
There are several new products being introduced into the emerging IoT market space which include multiple radios on the same printed circuit board operating on different wireless protocols, often at the same time. In order for these radio networks to operate efficiently and coexist, they need to have some higher level network management and control. This article provides information about EM3xx features which are currently available and can be used by network management software and hardware to help facilitate the coexistence of the ZigBee and Thread based radios with other radio networks such as Bluetooth and Wi-Fi. For those designs where network management is not possible, there is also a discussion of best practices to utilize in order to maximize the robustness of an un-managed co-existence network.
Currently, the available functions which can be utilized for EM3xx network coexistence are Radio Hold-off (RHO), which is a feature in the software stack and PTI_FRAME (PA4) and TX_ACTIVE (PC5)/nTX_ACTIVE (PC6), which are hardware functions within the IC.
RHO is a feature of the ZigBee software stack code. It is an input function normally residing on pins PA6 or PA7. The network arbiter, which can be another radio’s MCU, asserts RHO when the non-ZigBee/Thread network radio is active. This causes the ZigBee/Thread software stack to hold off the transmission of packets, until after RHO is de-asserted. Management of the RHO pin by the ZigBee / Thread software stack is done by forcing a return of channel busy for the CCA (clear channel assessment) algorithm, which then triggers a random back-off period for packet retry with a default of up to 3 total retries.
PTI_FRAME (PA4) is hardware function that must be enabled in software and the GPIO alternate function selected in order to be utilized. The primary function of PTI_FRAME is a debug port frame signal for network level debugging. It is asserted when TX preamble begins or when RX sync is detected. Thus PTI_FRAME can be used as an input to the network arbiter to indicate the ZigBee/Thread radio is active.
TX_ACTIVE (PC5) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The primary function of TX_ACTIVE is to operate an external switch within a FEM or discrete PA / LNA solution to select either the transmit path or the receive path. When asserted it marks the start of TX operation and when de-asserted it marks the end of TX operation. As an input to the network arbiter, TX_ACTIVE can be used as a flag to indicate when the ZigBee/Thread radio is transmitting. Used in conjunction with PTI_FRAME, TX_ACTIVE can also be used to identify if the ZigBee/Thread radio is in TX mode or RX mode, adding another layer of feedback to the network arbiter. The reason for this signal combination is the ZigBee/Thread radio is not always active in RX mode when TX_ACTIVE is low. For example, when PTI_FRAME is asserted and TX_ACTIVE is high, the radio is in TX mode. When PTI_FRAME is asserted and TX_ACTIVE is low, the radio is in RX mode. If PTI_FRAME is not asserted and TX_ACTIVE is low, the ZigBee/Thread radio is either not enabled or is simply not receiving packets.
nTX_ACTIVE (PC6) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The nTX_ACTIVE function is the inverse of the TX_ACTIVE function which is primarily the same except that nTX_ACTIVE de-asserts at the start of TX operation and asserts at the end of TX operation and is meant for separate LNA mode switching. nTX_ACTIVE can be used in the same manner as TX_ACTIVE as an input to the network arbiter to indicate when the ZigBee/Thread radio is active and in conjunction with PTI_FRAME to indicate when the ZigBee/Thread radio is transmitting or receiving.
In summary, connecting the non-ZigBee/Thread network radio’s transmit active and /or receive active output to the ZigBee/Thread RHO pin allows the ZigBee/Thread radio stack to hold-off on transmitting. Connecting PTI_FRAME and TX_ACTIVE or nTX_ACTIVE to the non-ZigBee/Thread network radio’s inputs allows the other network radio to know when the ZigBee/Thread radio is active and whether it is in transmit or receive operation. For the functionality described in this article to be fully utilized, the customer will need to develop the appropriate level of network arbiter / management functionality into the non-ZigBee/Thread network radio’s software application.
There are some design strategies that do not involve active network management and should be utilized in all cases where the ZigBee/Thread radio cannot be controlled at the same time as the non-ZigBee/Thread radios included in the design. The following strategies are also useful for designers who are looking for a more simplistic approach in applications where co-existence is not a priority or for managed network designs as supplemental and best practice design strategies. Note that these strategies are not a replacement for the above network management functions for which the designer should always implement whenever possible for robust network operation.
For enabling the hardware functions, refer to the EM3xx datasheets for more details.
For more details about CCA, refer to the IEEE 805.15.4 technical specification.
When an ISA3 is connected to a line powered EM3xx target, there is potential for causing damage to the ISA3 or the EM3xx target, due to a difference in potential between the ISA3 reference ground and the reference ground of the EM3xx target. The reason is due to lack of isolation between the AC component of the AC Mains reference and the reference ground used for the EM35xx target, for example such as found in custom EM3xx designs using bridge rectifiers. The ISA3 design assumes the EM35xx target reference ground is floating. When the EM35xx target reference ground is not floating, i.e., when it is referenced directly to an earth ground, AC mains neutral wire or AC mains hot wire, care should be taken to verify the isolation of the ground connections between the ISA3 and the EM3xx target in order to prevent damage.
The ISA3 ground is normally connected to the custom EM3xx target via the Packet Trace Port connector and in some rare cases via the DEI connector. The difference in ground reference potential often happens when the ISA3 USB cable connection from the PC or the Ethernet port POE (power over Ethernet) connection provides an alternate ground reference to the ISA3. To solve this problem, we recommend breaking the ground conductors within the Packet Trace Port cable and the DEI cable. A continuity check between the ISA3 reference ground and the EM3xx target should then be made to prove the two device grounds are isolated.