900HP DigiMesh: local AT unresponsive + reverse RREQ flooding under concurrent load — recover without a reset?

XBee & XBee Gateway XBee - DigiMesh
1

Module: XBee-PRO 900HP, firmware VR=0x8075, DigiMesh, API mode, host MCU on UART.

Setup: one mains-powered sink (host MCU + 900HP) and up to 11 battery “leaf”
nodes that are powered FULLY OFF between uses (not DigiMesh sleep). A leaf wakes,
sends one small 0xC0 routed unicast to the sink, waits for a small routed reply,
then powers off. ~2 routers for coverage.

Symptom under concurrent use (several leaves active within a second):

  1. The sink’s reply unicasts often return Tx Status delivery=0x25 (Route Not
    Found), discovery=0x02 (route discovery performed) — the reverse path keeps
    re-running RREQ floods.
  2. The sink’s local 900HP intermittently stops answering LOCAL AT (we poll ATVR)
    for >1 s during these bursts.
  3. Our only recovery is a hardware reset of the module, which costs ~7-11 s
    (reboot + reconfigure) — a visible outage we want to avoid at 11 leaves.

Questions:
Q1) Is this driven by route-table eviction at the sink (it must hold routes to
all 11 leaves), and/or by RREQ flooding toward leaves that are powered off
(the mesh doesn’t know they’re gone)? Is the route-table size / lifetime
adjustable, or should the leaves use DigiMesh sleep instead of powering off?
Q2) When the module won’t answer LOCAL AT for >1 s during route discovery, is it
simply BUSY and guaranteed to recover when the discovery/retries finish, or
can it genuinely hang? If it always recovers, we’d rather wait than reset —
is there a reliable “busy vs hung” signal (e.g., CTS), and an AT way to
abort an in-flight discovery instead of resetting?

(Happy to post full topology, parameters, and what we’ve already ruled out.)

2

Routing tables are not held through a power cycle. So what you are seeing is most likely the result of a rout discovery process. Since this is really not a meh network they way you are using them, try using the TO 40 function instead.