Xbee Multiple Unicast gets unstable and delays when 1 router offline

Question

I need to send messages to multiple routers (18) in AT mode as fast as possible and reliable.
Broadcast was as dissaster.
Now I try unicast from coordinator to routers with API mode.
This works good as long as all messages with 64bit addresses used in API frames reach their destination.

If one router is offline, or if one 64bit address is not correct all goes wrong, long delays and some messages not reach the online routers anymore.
I disabled the bit in byte 5 to ask for a confirmation, but that seems not to help.

Why this problem is happening?
How can I solve this please?
Desperate know....
Thanks in advance,
Wim

Answer 1

When you have a Node that is no longer on line or in the same path, a Rout Discovery is Required. This rout discovery is what takes time. To resolve your issue, you need to not send the next packet till the first has sent back the ACK indicating it was received.

Comments

Hi, thx for y reply but now I am very confused...
How can I wait for an ACK if it will never come? If the router gets powerless for example, it will never send an ACK.. this makes no sense no? If we have 18 routers to respond to messages from the Coordinator, and one of them stops working, I would expect the other 17 can receive messages normally, if this is not the case the hole concept is not ready to use in a profesional and relaible way no??
I not understand it at all ..
Why promote a self healing network that stops working properly when 1 node gets without power?
Please help,
Thx

---

Providing you are not turning off the ACK function in the API frames, you will get a status frame telling you if it was received or not. If the rout has changed, a New rout discovery will occur if the first attempts fails.  That is providing you have not turned off ADHOC function.   Just understand that all of that takes time.  It is not something that happens instantaneously. There are built in delays and re-transmissions that must occur that are part of the protocol you are not taking into account.

Maybe reading over http://knowledge.digi.com/articles/Knowledge_Base_Article/XBee-ZigBee-Addressing/?q=Zigbee+Adhoc&l=en_US&fs=Search&pn=1 will help you understand.

---

Yes I turned off the ACK function in the API frames, I just send all API frames from MCU to the coordinator by serial, I would like that all messages from coordinator to all 18 routers arrive fast, 10 Hz/ router would be ok, so 18 * 10 * 20 ( length) is what I try to achieve. If 1 router is offline for any reason I would like that the other 17 get the mesages fast and reliable. How to get this done please?
Remark: If a router goes offline and the coordinator has a 1 time delay this is acceptable, but in my tests the delay and not stable performance of the network is continiously.
How can I solve this? The requirement is getting all messages as fast as possible to all routers on line. not need to check if the message really arrived. Priority is speed. Thanks in advance.Wim

---

I did a simple test in XCTU
I sned at 100ms interval 4 messages with API from CO to 2 different routers. ON to R1 ON to R2 Off to R1 Offf to R2 , all messages arrive nicely in the XCTU terminal.
When I take out power of 1 router the problem starts.. the router still powered not gets all the messages anymore.  IS there any parameter I can change to stop this problem? I not need to know if the messages arrived, speed is the priority.
Thanks for help,
Wim

$@09/4/C5/ON/1/7B@$
7E/00/21/10/00/00/13/A2/00/40/D4/AD/7A/FF/FE/00/00/24/40/30/39/2F/34/2F/43/35/2F/4F/4E/2F/31/2F/37/42/40/24/F3/
$@09/5/C5/ON/1/7A@$
7E/00/21/10/00/00/13/A2/00/40/BF/D9/A1/FF/FE/00/00/24/40/30/39/2F/35/2F/43/35/2F/4F/4E/2F/31/2F/37/41/40/24/B5/
@0A/4/C5/OFF/1/4D@$
7E/00/22/10/00/00/13/A2/00/40/D4/AD/7A/FF/FE/00/00/24/40/30/41/2F/34/2F/43/35/2F/4F/46/46/2F/31/2F/34/44/40/24/AE/
$@0A/5/C5/OFF/1/4C@$
7E/00/22/10/00/00/13/A2/00/40/BF/D9/A1/FF/FE/00/00/24/40/30/41/2F/35/2F/43/35/2F/4F/46/46/2F/31/2F/34/43/40/24/70/

---

You can try using Source Routing but even then I don't think you are going to be able to do what you want.  What you want to do is not something a Mesh network is designed to do. At least not in that way.  The buffers are all First in = first out. So you must finish with the first packet before you can move on to the next.

---

thank y for your answer.
Is the problem in the mesh network, the routers that keep trying? Or is it the coordinator that is trying to deliver the message to a destination that is not there?
I can not understand why this causes serious problems, in every system there are power problems, product failures, if we have huge networks and only 1 node goes offline.. all the nodes and the complete network will get in trouble? That sounds dramatic to me..
I set the ACK request at coordinator to 0 ( disable I mean) why the coordinator still desperatly wants to wait and get disturbed to reach the other nodes?
2/ You write we must finish the first packet, but if the node is broken or offline, what do you mean with finish exactly?
3/ We plan to use Xbee in home automation projects all over Asean, but this issue is not a small thing. IF one point has a problewm the complete building gets a problem, that can not be the meaning of a reliable and sefl; healing mesh network right?
4/ Are there settings for coordinator or network to solve this problem?
5/ Is this similar for all mesh networks or only for Digi mesh?
Thakns for support, we are eager to solve this.
Kind regards from Thailand

---

When issuing a transmit request, regardless of who the node is that is sending the data, the first thing that occurs is that the node checks its child, Neighbor and Routing tables to see if it knows how to get the data there.  If it is NOT in any of these tables, then a Rout Request is performed.  Once a rout is determined, the Data packet is then sent.

If the Node is within one of the tables, the node tries to send it using the none rout.  If that fails, a rout request is performed.

If it is not able to find the node at all, then the packet is discarded and the next packet is moved up in the buffer to be transmitted and the cycle starts over.

Setting the bit in your API frame to Disable ACK only turns off the ACK coming out of the UART.  The RF ACK's still occur.

What I mean by Finish is that all of the retries at all levels must expire before the packet is discarded and the next packet is moved up to be transmitted.

The Rout Discovery and transmission process is the same for all mesh networks.

---

In XCTU you can send messages in an infinit loop and choose the speed ( we choose 100ms). We choose a small message( 25 bytes) and send it continiously! If the frame ID is 00 ( I think this means not checking ACK) the messages arrive perfect at Router at 10 Hz. BUT if the frame ID is 01 everything is slowed down to 2Hz instead of 10HZ. FIVE times slower. But y said in previous answer this bit only sends ACK to Uart or not, so how it can slow down everything 5 times?
1/ what happened with the 8 messages that not arrived?
The delivery status message is no succes.
2/ It looks like waiting for the  transmit status takes a long time, 1-2 seconds if not succesfull and also to long when messages succesfully arrived.
3/ Is there test info available from Digi what speeds are realistic?
4/ It looks to me that something important is missing in the whole concept. The broadcast we used first was also slow and not reliable.
( I never understood why it can not work properly). Now the multiple unicast seems also not fast. Is there anybody who found a way to use the high speed delivery of messages in a reliable way?
Xbee has so much potential to be used in medium speed home automation (dimming, color changes) , but if a transmit slows down to 20% by checking status and an offline node gets all other nodes in trouble, it seems not ok to me. Any changes this can improve or be modified?
Thanks.

---

1: The packets were dropped or lost for some unknown reason.
2: It is possible that you are not taking into account the UART time and time needed to process the data?  No mesh network can stream data at a 10 Hz rate and continue at this rate if packets are dropped for ANY reason.  There must be some time included to allow for propagation and rout discovery's as well as retries.  That is after all the nature of a Mesh network.

3: Yes, check your product manual for Maximum throughput rates between two nodes in a Unicast connection ...