I have an end point that I periodically, and on demand, make remote AT requests to (over API). SP is set to 2000 (decimal) on everything, so 20 seconds.
Currently I make requests from the coordinator. There are routers in the network, but the end point is (I’m pretty sure) a direct link.
This works 
My problem is that if I make a request to the end point (say, request IS for an immediate sample), I will sometimes get a no response error from the coordinator after much less than 20 seconds has passed - perhaps 6-8 seconds or so. Then, a little later, I get the response!
Question is, why do I get a timeout at all? All documentation I’ve seen suggests that the coordinator should wait considerably longer than the SP timeout before it assumes the end point is unreachable.
The coordinator has no way of knowing what the end point’s sleep time is set to, so its retry period doesn’t take this into account; it just retries the set number of times and gives up.
Have you considered using synchronous sleep mode? You could put the coordinator into Sleep Support mode and set the Sleep Options register to 1 to make it the Sleep Coordinator. This way the coordinator will not sleep but will only send packets when the end point(s) are awake.
I’m expecting the coordinator to act like a router for the end point, so the end point polls for data, rather than the other way around. The coordinator’s SP is configured the same as the end point’s SP, which documentation suggests is the key to getting correct end point timeouts.
In my documentation the SO bit 1 appears unused, and I can’t find a mention of the terms you are using relating to “synchronous sleep mode” - perhaps that’s for a different (non-ZigBee?) series of devices?
Just to clarify, and example might be:
@T + 0: Send ATIS request via API to end point
@T + ~8 seconds: Get “NO RESPONSE” response.
@T + 10 seconds: Get the ATIS data in a good response.
Sometimes the data arrives early enough to avoid the “NO RESPONSE” - I expect it to take anywhere from 0 seconds to 20 seconds. The odd thing is why a “NO RESPONSE” is arriving earlier than the 20 second SP value on the coordinator and all nodes.
You are correct; my apologies. I thought all XBee radios had this ability, but I guess the ZigBees do not.