Product family: XB3-24. Function set: Digi XBee3 Zigbee 3.0 TH. FW version: 1010 and 1013. API mode: API without escapes.
Issue:
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).
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?
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).
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.
Can you please explain what it was?
How to avoid such a long AS solution without pause? This is an empirical solution and I need a logical solution.
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?
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.
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.
