DigiMesh 900HP: leaf→sink unicast routes through a relay fine, but sink→leaf unicast fails `0x01` (MAC ACK fail) — sink attempts direct delivery instead of routing through the same relay. Why?

XBee & XBee Gateway XBee - DigiMesh
1

Hi all,

I have a 3-node DigiMesh network where the forward direction routes through an intermediate correctly, but the reverse direction will not — the sink keeps attempting a direct (single-hop) delivery to an out-of-range leaf and fails with Delivery Status 0x01, instead of routing the reply through the relay that demonstrably works in the other direction.

Hardware

  • 3 × XBee-PRO 900HP (S3B), ATVR = 0x8075.
  • API mode (AP=1), driven by an MCU over UART.

Nodes

  • Sink — fixed; all traffic targets it; connected to a host PC.
  • Leaf — a roaming handheld; sends a short unicast to the sink, expects a
    short unicast reply. Important: to conserve a 2×AAA supply, the leaf’s MCU
    powers the XBee completely off between transactions and cold-boots it
    (hardware reset + re-init) at the start of each scan.     So the leaf’s radio is
    only present in the mesh for the few seconds around a tag scan, and rejoins
    fresh every time    . It does not use XBee sleep modes (SM=0); the MCU gates
    power via the reset/regulator lines, not SM/SP/ST.
  • Relay — fixed, higher-power module between leaf and sink.

All three are configured identically for DigiMesh and verified in XCTU:
SM=0, CE=0, TO=0xC0, NH=7, BH=0, MR=7, identical ID/CH/HP.

What works

  • Leaf → sink (forward) routes through the relay. Confirmed: with the leaf out of the sink’s direct range, forward delivery works; unplug the relay and forward stops; restore the relay (leaf unmoved) and forward resumes. So the relay is genuinely bridging multi-hop in this direction.
  • All individual links are good. From the relay (on an XCTU dev board), a Remote AT (0x17) to the leaf’s 64-bit address returns Delivery Status 0x00; XCTU network discovery shows the leaf at ~ −87 dBm. The relay reaches both the sink and the leaf.

What fails

  • Sink → leaf (reply) fails 100% when the leaf is out of the sink’s direct range (but in the relay’s range). Delivery Status = 0x01 (MAC ACK failure), returned ~300 ms after the request.

The 0x01 is the puzzle: if the sink were routing the reply via the relay, the next hop would be the relay (which ACKs fine — forward proves it), so we’d never see a MAC-ACK failure. 0x01 means the sink is attempting a direct transmit to the leaf (next hop = the out-of-range leaf, no ACK) and not routing through the relay — and not recovering via route repair despite MR=7.

It looks like the sink has cached the leaf as a direct neighbor (presumably from occasionally hearing the leaf’s relayed forward packets at a marginal level) and keeps retrying direct delivery rather than using the known-good multi-hop path.

What we’ve tried

  • Swept the per-packet Transmit Options byte (0x40 works for forward; 0x00/0x80/0xC0 broke all delivery — so we’re on 0x40).
  • TO=0xC0 confirmed on all three; network-reset / power-cycled all three.
  • Aggregator: issued ATAG from the sink (returns OK) — no effect on the reverse path.
  • Verified every node’s SM/CE/TO/NH/ID/CH/HP, MR=7, and all links.

Questions

  1. In a correctly-configured DigiMesh network, why would the sink attempt a direct unicast to a leaf (failing 0x01 MAC-ACK) instead of routing the reply through a relay that is actively bridging the forward direction? What makes a node choose direct delivery and not fall back to route discovery/repair for an out-of-range destination?
  2. How do I force the sink to route the reply through the relay — e.g. clear/expire a stale direct neighbor entry, force a route discovery (DN/explicit route) before the reply, or a Transmit Options / CE / MR / NO setting that changes this?
  3. Does DigiMesh treat a node that frequently resets/rejoins (our leaf power-cycles its radio between transactions) differently for inbound routing — i.e. routes to it don’t establish/persist even though routes from it do?
  4. Confirm ATVR=0x8075 is the DigiMesh function set for the 900HP (the function-set name from XCTU is [FILL IN]).

Happy to post raw API frame captures (the 0x10 request + 0x8B 0x01 status, and the relay’s successful Remote AT) if useful.

Thanks!
Hongwei

2

In your situation, the node that you are calling the “Leaf” is in the parents neighbor table. This is why it fails when going through a hop instead. You can force a rout discovery by doing an ATND to the NI value of the “leaf”.

1 Like
3

thanks. The forced discovery works