- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
04-12-2017 03:03 PM
I'm trying to understand the ZigBee routing tables from the Ember - or more specifically, the associated devices list. See below - this shows no associated devices, but we have neighbors, and routes to other devices.
The "associated devices" comes from the IeeeAddress ZDO call - the devices shown as neighbours were directly associated to the coordinator - clearly they are still communicating as they operate correctly, and have a good LQI - why are they not showing in the list of associated devices in Ember processor?
04-14-2017 02:48 PM
What is the RequestType for your IEEE Address Request? According to the zigbee spec:
Request type for this command:
0x00 – Single device response
0x01 – Extended response
0x02-0xFF – reserved
I believe the "associated device" is only required to be in the response frame if the RequestType is 0x01 for extended response.
04-14-2017 02:56 PM
Yes, request type is set to 1 -:
14:44:27.047 DEBUG TX CMD: IeeeAddressRequest, nwkAddrOfInterest=0, requestType=1, startIndex=0
I'm reasonably sure this works fine with the TI CC2531 (although I'll double check that this is still the case).
04-14-2017 03:00 PM
Could you share your packet trace with us so that we can analyze the details? If it contains sensitive information you can share it through the support portal.
04-14-2017 03:04 PM
Sure - what exactly do you want? Since this doesn't go over the air I don't have a capture, but I can provide the debug logs from my software (EZPS/ASH packet dumps).
04-14-2017 04:33 PM
Wait - now I'm a little confused. Do you mean you are not sending the IEEE Address Request to a remote device but to itself, and it's a local loopback? In that case wouldn't you just look up the neighbor table locally? Could you describe the transaction in more details: the source and destination of the request and response, and device types, and purpose of this request, etc.?
04-14-2017 05:19 PM
Yes - this is sent locally between the host and the NCP, and yes, I realise we could use another (EZSP) request rather than the native ZigBee ZDO messages. However in this case we're using the ZDO requests to get this information for a number of reasons, and I understand that the Ember should response to the ZDO requests (and it does).
We have a NCP application, communicating to the Ember via EZSP/ASH. The Ember is configured as a coordinator and has other devices (mainly routers) connected to it. We request the IeeeAddress, ManagementLqi and ManagementRouting requests - these all work fine - as shown in the image above we get the neighbor table, routing table, but the associations are normally empty - not always, but normally, and it's certainly not consistent between these three tables.
The three calls I mention above are all sent very close together (ie milliseconds apart - one after the other), so I would expect a consistent dataset?
These ZDO calls are sent to the Ember in the SendUnicast EZSP message.
As per the initial message, this all works ok with the exception that the associated device list is empty.
04-17-2017 03:45 PM
For comparison, I used the Ember GetNeighbor call at the same time (roughly) as the ZDO message, and they are returning consistent data. See below - the first 2 lines are the Ember calls - returning a single neighbor, and the third line is the ZDO call - also returning consistent data.
21:05:40.594 DEBUG EzspNeighborCountResponse [value=1] 21:05:40.610 DEBUG EzspGetNeighborResponse [status=EMBER_SUCCESS, value=EmberNeighborTableEntry [shortId=29342, averageLqi=255, inCost=1, outCost=1, age=3, longId=000D6F00056B43CC]] 21:06:09.873 DEBUG RX command: ManagementLqiResponse, status=SUCCESS, neighborTableEntries=1, startIndex=0, neighborTableListCount=1, neighborTableList=[NeighborTable [extendedPanId=987654321, extendedAddress=0022A300001732BF, networkAddress=0, deviceType=COORDINATOR, rxOnWhenIdle=1, relationship=PARENT, permitJoining=2, depth=0, lqi=255]]
Likewise, the routing table also seems consistent (from a quick check).
So, hopefully this alleviates your concern about HOW I'm getting the information, and brings us back to the original question - what does the list of associated devices returned from Ember mean?
I thought that this was the list of devices to which the Ember was parent, but if we look back to the image I posted at the top of this, we see that the coordinator has known routes, and neighbors, but no associated devices.
Given that these devices have joined the PAN, shouldn't they be in the associated devices list?
06-06-2017 04:06 PM
@cdjackson: here is what the spec says with regard to the extended response request type:
"... The Remote Device shall also supply a list of all 16-bit NWK addresses in the NWKAddrAssocDevList field, starting with the entry StartIndex and continuing with whole entries until the maximum APS packet length is reached, for all devices in its nwkNeighborTable where the Device Type is 0x02 (End Device)."
Note that only end device children should be included in the list of associated devices; not routers. Could this explain why sometimes you see the list empty - could you confirm the coordinator does have end device children?
I have run some tests myself and verified that the packets over-the-air agree with what the spec requires. Specifically, in my test the coordinator has one child in its child table; a router sends IEEE address request to the coordinator with extended response request type 1 and StartIndex 0, and the coordinator does report the child in its IEEE address response.