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

**URL:** <https://forums.digi.com/t/900hp-digimesh-local-at-unresponsive-reverse-rreq-flooding-under-concurrent-load-recover-without-a-reset/38534>\
**Category:** XBee - DigiMesh\
**Created:** [June 19, 2026, 4:10pm UTC](https://forums.digi.com/t/900hp-digimesh-local-at-unresponsive-reverse-rreq-flooding-under-concurrent-load-recover-without-a-reset/38534 "2026-06-19T16:10:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![hlyu-coencorp.com](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@hlyu-coencorp.com](https://forums.digi.com/u/hlyu-coencorp.com)\
**Post date:** [June 19, 2026, 4:10pm UTC](https://forums.digi.com/t/900hp-digimesh-local-at-unresponsive-reverse-rreq-flooding-under-concurrent-load-recover-without-a-reset/38534/1 "2026-06-19T16:10:22Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\
**Post date:** [June 29, 2026, 12:22pm UTC](https://forums.digi.com/t/900hp-digimesh-local-at-unresponsive-reverse-rreq-flooding-under-concurrent-load-recover-without-a-reset/38534/2 "2026-06-29T12:22:25Z")

</div>

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.