in my XBee network i need to route data: end device -> 1 or 2 repeater -> coordinator. Therefore, am i right, that the only topology for that is DigiMesh on the XBee SX 868?
The end device is battery powered, so it sleeps most of the time. When i use DigiMesh, isn’t it possible to use asynchronous sleep mode, only synchronous sleep mode on the end device?
My opinion for that was an asynchronous cyclic sleep end device -> repeater (always on) -> coordinator (always on), isn’t it possible?
Only found te following topic but the answer wasn’t very clear for my questions.
I have read this manuel 10 times, but the asynchronous sleep mode isn’t realy clear for me.
“Therefore, to save battery life it is important to configure an indirect messaging sleep coordinator (CE (Node Messaging Options) 1) within range of the sleeping node. Also the sleeping node (CE 6) needs to point to the indirect messaging sleep coordinator with DH/DL set to the SH/SL of the indirect messaging sleep coordinator.”
When the node in range of the end device must be an indirect messaging sleep coordinator, then i think it isn’t possible to add routers between them?
“Indirect messaging only functions with P2MP unicast messages.”
But then a door lock or window sensor makes no sense with DigiMesh.
Your end device should be set to SM4 and CE2, The router would be SM 0 and CE4 and the Coordinator would be CE1
Thanks a lot mvut!
Then the sentence in the manual “Indirect messaging only functions with P2MP unicast messages.” makes no sense, because there are DigiMesh messages through an indirect message router.
The product supports both Point to Multi-point or Mesh modes. When you have it configured for Point to multi-point mode (Non Mesh/Router), it only supports indirect messaging is what it is referring to.
When sending a “Remote AT Command Request” i’m getting a “Remote Command Response” with status 04 (TX failure). So it’s not possible to send data reliable to the remote device.
Via remote sampling rate the lokal device get packets from the remote device every wake intervall.
Sounds like you might be using the wrong TO option bit in the API frame.
To make this easier i only try to communicate between my coordinator and end device, both connected via USB.
Coord.: API mode 2, SM=0, CE=1
End D.: SM=4, CE=2 (and tested as Non-Routing Poller), DH/DL set to SH/SL of the Coord.
The communication between end device and coordinator with TO option C1 works well (io sampling, read out the TO option of the incumming frame). But sending an API frame from coordinator to end device, the TX failure occur.
Any other TO options like C0 (Mesh), C1, 40, 41 failed.
The communication between one end device and the coordinator work’s well with the following settings:
CE = 6
DH/DL to SH/SL of the coordinator
SM = 4
CE = 1
TO = 0x40
AP = 1
Hope it will work with a router between them.
Why TO must be set to 0x40 on the coordinator, because it should be a Mesh network? For IO sampling (packets from the end device) the receive option is C1. But C1 as TO on the coordinator does not work very well.
That is probably because there are too many packets for the mesh to handle in the time you have.
I think the coordinator is not able to buffer DigiMesh only P2MP packets, when the end device is sleeping. When i set CE=4 for the router, this device is shown as an end device (E) in XCTU but it should be an always on router (R).
CE 4 is indirect messaging puller. It is not a coordinator.
I mean, when the coordinator (CE=1) can only send P2MP (0x40) messages to asynchronous sleeping end devices (CE=6), then it isn’t possible to route this packets with an router device (CE=4). So there is no chance to build a DigiMesh network with asynchronous sleep.
I am going to suggest you send an email to Digi support so they can help you with this. The email address is firstname.lastname@example.org
Also I had exactly your problems and I solved with the TO = 40 not only on the coordinator but also on the final device.
P.s. “So … first you give TO40 to the Coordinator, then the AT command to the Final Device and finally you give TOC0 back to Mesh.”