The "Association Indication" command always returns the code "0xFF"

Product family: XB3-24.
Function set: Digi XBee3 Zigbee 3.0 TH.
FW version: 1010 and 1013.
API mode: API without escapes.

Before associating an endpoint to a coordinator, I do this:

  • Disconnect the join (DJ: 1)
  • Start an active scan (AS).
  • If a PAN ID is detected, I write PAN ID value (ID: value)
  • Enable join (DJ: 0).
  • Then I poll with the AI command to find out the connection status.
Additional info
  • It is a part of an algorithm to automatically poll multiple coordinators, but in this case 1 endpoint and 1 coordinator.
  • After starting the device, I enter command mode and send ATID0, ATWR, ATCK, ATCN to check the XBee profile.

After the first power on, this works in conjunction with my MCU - joining in 5 seconds. But if I turn OFF the coordinator and then turn it back ON after 10-15 seconds, the endpoint detects it via AS, but after enabling the join (DJ: 0) the AI command always returns code 0xFF.

However, if do this via XCTU, this algorithm and the join works (although sometimes the 0xFF status is present several times).


What I tried:

  • Sent NR: 0 before/after writing PAN ID.
  • Sent WR before/after DJ: 0.
  • Paused for 5 - 10 seconds between AT commands.
  • Checked the voltage levels on the adapter when connected to the computer and to the MCU - the same.
  • After resetting of the endpoint, the first connection is always stable. The second connection is always with code 0xFF.

What could be the reasons for the constant “0xFF” code when calling the “AI” command?

Setting NJ to 0 will turn off Joining. You do need to have Joining enabled for a router or end device to join an existing network.

I would also suggest doing a Network Reset on your testing if you want a router or end device to try to search for a new network to join.

mvut, thank you for reply.

On the coordinator and endpoint, the NJ parameter is set to 0xFF, I manage to connect to it via the endpoint on the XCTU, but not via MCU with same commands (and I tried to swap devices). I also enable joining via the DJ command as described above.

I have done Network Reset before and after setting the PAN ID. When exactly should I do the reset?

I would suggest looking at the II and ID vales on your Coordinator. I suspect one of the two has changed.

I suspect one of the two has changed.

But I’m using the values from the response to the AS command, so the values are definitely valid. Also, I can connect via XCTU using the same commands and values.

Btw, I think I found a solution: use NR before the DJ command in the algorithm I described in the title of the thread. Now the connection is stable.

However, I encountered a new problem: the AS command keeps returning an error (see attached logs).

Logs with timestamps

You wrote here that NR command should be used before, but I do this step. Then I took a closer look and noticed that one AS command did not respond after 10 seconds of waiting (I marked this command in the logs). I observed this event at random times in 4 sessions.
Then I added a pause of 2 seconds after sending the NR command and never encountered this behavior with AS again.

  1. Can you please explain what it was?
  2. How to avoid such a long AS solution without pause? This is an empirical solution and I need a logical solution.
  3. Are there any flaws in my actions?

The Active Scan is going to scan all available channels. You would have to turn off desired channels using the SC command.

I’m using the default values for SC (11) and SD (3). The wait time according to the formula in the datasheet should be 1789ms.

([# of channels to scan] * (2 ^SD) * 15.36 ms) + (38 ms * [# of channels to scan]) + 20 ms

I almost always have a scan time of about 2 seconds, however just now I waited 30 seconds and have no response. What could this be related to?


During testing I set the maximum time to wait for a response from AS to 300 seconds and during this time the response did not come…

To summarize:
Active scanning (AS) works properly for some time. At one of the moments of exiting cyclic sleep, I send the DJ: 1, then NR, and then AS command as usual, but there is no response (in the logs I waited 8 seconds, but previously I waited longer). Then I send DJ: 1, then NR, and then AS again and then I get an error code from AS. After 3 seconds the situation repeats itself and the endpoint no longer scans and always returns an AS error. This happens both with a connected coordinator and without one nearby.

Please tell me what should be avoided so that there is no error in response to AS?
If an error occurs, how can I fix it?

I think you may want to take a closer look at the SC command. The default SC value enables 16 channels. Not 11.


There are 15 of them by default, I didn’t read the documentation correctly. Value 0x7FFF (channels 11 through 25).

Then the scanning time according to the formula will be 2433ms, but not >300 seconds, this is clearly a failure of the AS command. I would like to somehow reset this command. I’ll try to reduce the SC value, okay.


I have set the minimum value SC: 1 and SD: 2, but still this error occurs. Here is logs after the device power on.


I noticed that without the NR command there were no such failures with AS, but the AI always gave the error .

By the way, there is an error in the documentation, the range of the SC command cannot start from 0. AT response status 0x03.

Doc error

Exactly what is it you are trying to do with this process?


There are several systems consisting of a coordinator and endpoints with their own PAN ID. The task, when turning on a new endpoint, is to poll each detected coordinator one by one and try to connect to it. After association, pairing packets are exchanged. If this endpoint does not belong to this network, then it attempts to pair with others.

Thus, there is no need to flash the XBee module just to set PAN ID and manually change it if necessary.

It seems to me you are going about this the hard way as the radio perform a good deal of this on its own already.

Try simply setting the PAN ID to 0. Then let it associate and try its End point verification. If it is found to be invalid, the Coordinator can push the device off using the DA command or you can issue a local network reset on the end device. It will then look for a new PAN that is allowing Joining.


If I set PAN ID 0, then the endpoint will connect to an arbitrary coordinator, as far as I understand. I tried via XCTU. AS detects 3 coordinators, but the endpoint after NR only joins two of the three in turn. This option is not suitable, I need to poll all of them. And not repeat the request to those who have already refused pairing.

I didn’t find information about the DA command in the documentation, can you tell me where I can read about it?

Sorry the DA command is in the IEEE 802.15.4 firmware and not in the Zigbee version. That was my fault.

I think I found the other issue. The SD time is the time it spends on the channel and not how long it takes to process the scan and pass that response out of the UART. You have no way to measure the time the module spends on each channel for it to listen on each channel.

Do I understand correctly from this that sending an AS command and not receiving a response for 300 seconds is a normal situation? Maybe the endpoint is scanning all this time.

I just want the AS to work flawless or be able to fix it.

I am not seeing it take that long. But part of the Zigbee standard tells the system to increase its time between duration on each request you send within a given time frame. That is to say, if you send the AS five times within 1 min, the first response may take 100ms, the 2nd may take 200ms, the 3rd time may take 600ms and the forth may take 700ms. The 6th time you send it, it will revert back to the original 100ms time frame. (Not the timing on this is not accurate. It is only being used to give you an idea of how it works). That is part of the Zigbee standard and is that way to allow for propagation of the packet and for allowing for responses and reduce data collision.

mvut, thank you for reply.

I got the principle of scanning time formation.

Is there any way to stop scanning forcibly? Reset its parameters to the initial ones.

No, there is no way to change this. It is part of the Zigbee/802.15.4 standard. It is not something you can over ride.