undiscoverable digi device

I have 2 XBees (one API and another in transparent mode) with the same MAC/PHY configuration.

These two XBee could communicated when the remote has a DL parameter that point to another XBee?

Are they DigiMesh or Zigbee module? Can you tell its part number.

Module with API mode cannot transmit raw data feed to it on UART pin (that’s transparent mode). User or connected MCU needs to design API packet frame and then this will be processed by module.

1 Like

They are DigiMesh modules.

My concern is not about API or transparent modes at all (sorry for emphasize that) is about communication between XBees and if is possible for a remote end device XBee with a DL parameter other than the coordinator SL to communicate (be discoverable and change parameters of remote XBee) even when they have the same MAC/PHY parameters. I think that this is a kind of address packet filtering but sometimes I can communicate with device with different addressing destination and sometimes not.

Any node that is in the network and in API mode can modify a remote modules settings.

I found the cause of why I can’t communicate between nodes.

The configuration is as follow (applicable to XBee Pro 900HP 200K with firmware 8071 on all modules):

  • Non-Routing Coordinator (API mode) (A)

  • Non-Routing Module (Transparent Mode) (B )

    • DL configured to point address of XBee C (this XBee has the same configuration as A)
    • IR = 0 (this parameters seems insignificant but it is not)

XBees A, B and C have the same MAC/PHY settings.

With the configuration above, A and B can communicate without problems.

When IR parameter is setting to some value on B then A and B cannot communicate, there is always TX errors when you attempt to communicate with B from A. Obviously there is no problem between A and C as it sends samples to its DL address. But when you change IR to 0 then communication is possible between A and B.

So in conclusion,
when you change IR parameter on a Non-Routing Module to some value different from 0 then you cannot communicate using another Coordinator that uses other DL parameter that the Non-Routing Module points. So if the Coordinator fails for whatever reason you cannot restore the Non-Routing Module wirelessly using another Coordinator.

The node became deaf to other Coordinator when sending samples.

that is not applicable to the above scenery. Have you some clues of how to deal with this?