API: unicast using ONLY 16-bit address

Setup: Xbee S2 with API mode

Is there a way to send a proper unicast Tx by using only a 16-bit address?
(64-bit address unknown, unavailable or simply one does not care about it)

Official manual (excerpts below) leads to understanding
(especially Transmit Mode Sequence diagram on page 31)
that one only needs a 16-bit address to send a packet,
whereas 64-bit address is used to discover 16-bit address when not known in advance.

Problem is that when one knows only 16-bit address (e.g. discovered by MP) and want to send a unicast Tx,
64-bit address field still needs to be set.
(supported options: 0x00 00 (coordinator), 0xFF FF (broadcast), or exact address of a destination)
(N.B. 0x FF FE (unknown) is not supported like for 16-bit addresses)

Funny enough, I can put my money that Address Table can resolve a 16-bit address to a 64-bit one
since it contains both of them (it is populated on ND, join, etc).

Any thoughts would be appreciated.


Manual Excerpts:

Addressing

All ZigBee transmissions are sent using the source and destination 16-bit addresses.
The routing tables on ZigBee devices also use 16-bit addresses to determine how to route data packets through the network.
However, since the 16-bit address is not static, it is not a reliable way to identify a device.
To solve this problem, the 64-bit destination address is often included in data transmissions to guarantee data isdelivered to the correct destination.
The ZigBee stack can discover the 16-bit address, if unknown, before transmitting data to a remote.

Unicast

When sending a unicast transmission, the ZigBee network layer uses the 16-bit address of the destination and each hop to route the data packet.
If the 16-bit address of the destination is not known, the ZigBee stack includes a discovery provision to automatically discover the destination device’s 16-bit address before routing the data.

Address Table

The application can then send both the 16-bit and 64-bit addresses to the XBee in the API transmit frames which will significantly reduce the number of 16-bit address discoveries and greatly improve data throughput.

Each entry in the address table should contain a 64-bit destination address and its last known 16-bit address.

ZigBee Transmit Request

The 64-bit destination address should be set to 0x000000000000FFFF for a broadcast transmission (to all devices).
The coordinator can be addressed by either setting the 64-bit address to all 0x00s and the 16-bit address to 0xFFFE, OR by setting the 64-bit address to the coordinator’s 64-bit address and the 16-bit address to 0x0000.
For all other transmissions, setting the 16-bit address to the correct 16-bit address can help improve performance when transmitting to multiple destinations. If a 16-bit address is not known, this field should be set to 0xFFFE (unknown).

I guess you are right. One must know 64 bit address of destination node to send it a unicast packet.

The only way I can think of is to use “DN” parameter to get 64 bit destination address. But for this “NI” node identifier of destination node should be known in advance.

Unfortunately, yes.
According to my empiric observations and some reading of the Digi Forum this seems to be the case.

Quite disappointing and above all misleading taken in account what is written in the official documentation.

Furthermore, along with DN, one can use
ND: full blown network discovery

Which is kind of overkill, especially that an address table is maintained but Digi decided not to make it accessible.

Finally, both DN and ND seems like heavy artillery for a simple common task of knowing one node’s parent address-64 (MP only gives 16-bit)

Can’t express enough my frustration and disappointment…

Hi bogprs

I did further investigation and realize that its possible with “0x11 Explicit Addressing Command Frame”.

Put 0xFFFFFFFFFFFFFFFF in the 64DestAddr field to indicate the 64 bit address is unknown. Put the 16 bit address in the 16DestAddr.

The network stack will either use the 16 bit address to look up the 64 bit address in its addressing tables before transmitting the message, or it will generate a ZDO request to learn the 64 bit address from the 16 bit address and then transmit the message.

Hi killer32,

Thank you for your answer.
Unfortunately, the proposed solution does not work in practice for the same reasons as previously stated.
User manual is quite strict:
64-bit address field supports only 0xFF FF (broadcast) and 0x00 00 for coordinator from the generic pool of addresses.

Hence, putting all 0xFF FF FF FF FF FF FF FF yields an error (Network ACK Failure) similarly when sending Tx (0x10 type).

Best,
Bogdan (bogprs)