XBee-PRO 900HP / S3B — 0x10 Tx Request fails when Tx Options bit 0x80 (Trace Route) is set; works fine without it

Hi all,

I’m building a custom firmware for a HCS08-based host that drives an XBee-PRO 900HP (S3B) over UART in API mode
(AP=1). The module runs DigiMesh firmware. Unicast packets work normally until I enable Trace Route — at which point
every transmit fails immediately at the radio level, and the host never sees any 0x8D Route Information Packets.

I’d like to confirm whether this is a firmware-version limitation, a bit-combination issue, or something else.

What works

Frame builder produces this 0x10 Transmit Request for a unicast to a 64-bit destination:

7E LL LL 10 <dest 8B> FF FE 00 40

  • Broadcast Radius = 0x00 (use NH; NH is set per the deployment).
  • Tx Options = 0x40.

End-to-end delivery succeeds; 0x8B Tx Status returns Delivery=0x00 OK. We’ve been running this in production with
multi-hop traffic for a while.

What fails

For diagnostics I tried Trace Route — set bit 0x80 in the Tx Options byte. Two combinations tested:

(a) Tx Options = 0xC0 (= 0x40 | 0x80, just OR’ing the trace bit in)

(b) Tx Options = 0x80 (dropping the legacy 0x40 entirely)

In both cases, every traced unicast fails. Observed:

  • 0x8B Tx Status returns near-instantly with a non-zero Delivery Status.
  • Zero 0x8D Route Information Packets are emitted by the local module — not even one for the source’s own hop.
  • The packet does not appear to be sent over the air (verified by listening on a sniffer XBee at the destination —
    nothing is heard).
  • The moment I clear bit 0x80, the same packet (same dest, same payload) goes through normally.

So it really looks like the local module is rejecting the frame internally before any RF activity.

Module info

  • Hardware: XBee-PRO S3B, OEM MAC 00:13:A2:00:41:xx:xx:xx.
  • AC5124 carrier board, host firmware version “8.00”.
  • ATAP=1, ATCE=0, ATSM=0, ATNH=7, ATBH=0.
  • Will report ATVR shortly — currently in the field, will edit with the value as soon as I have access.

Questions

  1. Is bit 0x80 of the Tx Options byte the correct way to request Trace Route on this firmware, or is there a separate
    API frame / AT command I should be using instead?
  2. Is there a minimum VR (firmware version) that supports Trace Route in DigiMesh 900HP? If so, what’s the cutoff
    value?
  3. The 0x40 Tx Options bit was carried over from an older 802.15.4-era firmware in our code (predates my involvement)
    and Digi’s current 900HP docs describe 0x40 as reserved on DigiMesh. Is setting 0x40 while sending a normal unicast
    actually safe, or could it be misinterpreted as something else (APS encryption flag, etc.) and contributing to the
    failure when combined with 0x80?
  4. Is there a way to read out a Delivery Status code that distinguishes “frame rejected by local API parser” from “RF
    delivery failed”? The single-byte status we currently consume doesn’t seem to.

Any pointers appreciated — happy to capture more API frame traces if useful.

Are you using the AG command at all? The AG is used when trying to use 0x80 API frame.

XBee®-PRO 900HP and XSC RF Modules User Guide?