Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Route hops order in create_source_route vs CreateSourceRoutePacket vs XBee User Guide #278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bennevados opened this issue Aug 5, 2022 · 4 comments
Closed

Route hops order in create_source_route vs CreateSourceRoutePacket vs XBee User Guide #278

bennevados opened this issue Aug 5, 2022 · 4 comments
Labels
bug

Comments

@bennevados
Copy link

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
Copy link
Contributor

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
Copy link
Author

@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 added a commit that referenced this issue Aug 17, 2022
@tatianaleon
zigbee: source route: reverse hops order for a 'Create Source Route' …
0cb53bd 
…packet

'Create Source Route' packet (0x21) must include the hops to a destination node
from closest node to destination to closest neighbor to source. See:

https://www.digi.com/resources/documentation/digidocs/90001539/#reference/r_frame_0x21.htm

#278

Signed-off-by: Tatiana Leon <[email protected]>
@tatianaleon tatianaleon mentioned this issue Aug 17, 2022
Merged
@tatianaleon
Copy link
Contributor

Hi @bennevados,

Issue solved in commit 0cb53bd.

This fix will be included in the next release.

Thanks for reporting.

@bennevados
Copy link
Author

Thank you, @tatianaleon! That was very fast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tatianaleon @bennevados