This project has moved. For the latest updates, please go here.

usage of ExplicitTxRequest

Oct 28, 2014 at 2:01 PM
Good afternoon,

I'm looking at the possibility of creating a ExplicitTxRequest for retrieving the routing table of a XBee node. It's a school project to make the make see how the routing table addepts is self within the mesh.
I already tested the functionality with the XCTU software, it works. So the XBee settings are OK

Is it possible to use the NETMF.OpenSource.XBee.Api.Zigbee.ExplicitTxRequest?

What I've tried is the following;
ExplicitTxRequest routingTableRequest = new ExplicitTxRequest(xbee.Config.SerialNumber, payload, srcEndpoint, destEndpoint, clusterID, ProfileID);
var response = xbee.Send(routingTableRequest).GetResponse();
The response doesn't contain the data needed.
Is there a way to retrieve a ExplicitRxResponse?


Thanks,
Remco
Coordinator
Oct 28, 2014 at 4:54 PM
Hi Remco,

Yes, this should be possible, but this is more advanced and it's been some time since i last dug deeper into XBee protocol. Could you describe step by step how are you retrieving the routing table using X-CTU? This might refresh my memory and I might be able to help you out. Are you retrieving the table from your local or remote node?

Jakub
Oct 28, 2014 at 6:05 PM
Hello Jakub,

I'm using the latest version of XCTU.
For receiving ZDO command responses you have to place the AO(API output) parameter of the XBee to 1.
XBee is loaded off course with the API firmware :), my case router API.
I used this app note as a guidance

I composed a custom frame in the console window.
The frame looks like this:
Explicit Addressing Command Frame (API 1)
7E 00 16 11 01 00 13 A2 00 40 9B AF 94 FF FE 00 00 00 32 00 00 00 00 01 00 EA
    - Start delimiter: 7E
    - Length: 00 16 (22)
    - Frame type: 11 (Explicit Addressing Command Frame)
    - Frame ID: 01 (1)
    - 64-bit dest. address: 00 13 A2 00 40 9B AF 94
    - 16-bit dest. address: FF FE
    - Source endpoint: 00
    - Dest. endpoint: 00
    - Cluster ID: 00 32
    - Profile ID: 00 00
    - Broadcast radius: 00 (0)
    - Transmit options: 00
    - Payload data: 01 00
    - Checksum: EA
Then the response frame in my test was like this:
Explicit RX Indicator (API 1)
7E 00 62 91 00 13 A2 00 40 9B AF 94 00 00 00 00 80 32 00 00 01 01 00 28 00 0F 17 6D 00 17 6D F3 01 00 17 6D 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 09
    - Start delimiter: 7E
    - Length: 00 62 (98)
    - Frame type: 91 (Explicit RX Indicator)
    - 64-bit source address: 00 13 A2 00 40 9B AF 94
    - 16-bit source address: 00 00
    - Source endpoint: 00
    - Destination endpoint: 00
    - Cluster ID: 80 32
    - Profile ID: 00 00
    - Receive options: 01
    - Received data: 01 00 28 00 0F 17 6D 00 17  6D F3 01 00 17 6D00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00 00 00 03 00 00
    - Checksum: 09
In the response are two routing table entry in little endian byte order.
This is one 17 6D 00 17 6D and the other one is F3 01 00 17 6D
The second entry for example tells me that to send a message to 01F3 the next hop address is 6D17

If all the XBee nodes are connect straight to the node talking to, the routing table entry's are all like 00 00 03 00 00 00, empty.

Hope this helps in refreshing your memory :-)
Thanks for you help.

Regards,
Remco
Nov 6, 2014 at 8:55 AM
Hi gralinPL, did you press F5 already for refreshing your memory ;-)