Route hops order in `create_source_route` vs `CreateSourceRoutePacket` vs XBee User Guide

[bennevados]

In the documentation for ZigBeeDevice.create_source_route(..):

hops (List): List of intermediate nodes (:class:.RemoteXBeeDevice) ordered from closest to source to closest to destination node (source and destination excluded).

In the documentation for CreateSourceRoutePacket.__init__(..):

hops (List, optional, default=None): List of 16-bit addresses of intermediate hops in the source route (excluding source and destination).

In the documentation for Create Source Route - 0x21 in the XBee User Guide:

The addresses should be entered in reverse order (from destination to source) to match the order provided in Route Record Indicator - 0xA1.

As far as I can tell:

• In ZigBeeDevice.create_source_route(..), the hops are passed in order to CreateSourceRoutePacket.__init__(..).
• In CreateSourceRoutePacket, the hops are packed in order into a 0x21 frame.

I have tested this by creating a source route and then sending a request for a DB. When I send with a destination to source order, contrary to the documentation, the packet has a signal strength that corresponds to the last hop as expected. When I send with a source to destination order, the packet has a signal strength that corresponds to the first hop even though the DB would return the signal strength of the last hop suggesting that the request took the reversed path.

Note that in XBeeDevice.__route_record_callback(..), the list is specifically reversed, so that looks OK.

[tatianaleon]

Hi @bennevados,

Keep in mind that:

• Source routing must be used with many-to-one route requests (see Source routing)
• You must acquire the route and not set the route you want using a 0x21 frame (see Acquire source routes)
• Routes must be stored as they are received to be used later (see Store source route and Send a source routed transmission)
• DB command reports the RSSI of the last received packet or APS acknowledment. It only indicates the value for the last hop and it is not accurate for a multihop link, that is what you are mainly using with source routing (see DB (Last Packet RSSI))

Best Regards

[bennevados]

@tatianaleon

Just to address all of your points:

• Source routing and many-to-one route requests are being used.
• Only using acquired routes and not being able to set routes is is contradicted by (1) a reply I received from digi's tech support, and (2) my experience using this feature.
• This is the key point of this issue: the library specifically reverses the received source route from the XBee but does not re-reverse the same source route before sending it to the XBee. If the XBee provides the route to this library in D, C, B order, then this library will provide it to the application in B, C, D order. When the application provides the route in B, C, D order, that is then sent to the XBee in B, C, D order which does not match the original XBee provided route.
• I can confirm that the DB command is not always accurate for a multihop link at least due to automatic route healing/discovery and early route end. It is however useful enough to get some information. It would be nice if the XBee's ZigBee firmware stored some information about RSSI that could be queried, but as far as I can tell this information is unavailable. (Though stored RSSI information is available in the XBee's DigiMesh firmware.)

Based on my answers above (specifically point 3), I still believe there is an issue with this library's implementation.

[tatianaleon]

Hi @bennevados,

Issue solved in commit 0cb53bd.

This fix will be included in the next release.

Thanks for reporting.

[bennevados]

Thank you, @tatianaleon! That was very fast.