Probable channel selection bug in latest XB24-ZB router firmware (22A7)

Question

I've encountered what I believe is a bug in the current (22A7) XB24-ZB firmware. When I setup a router to join an existing PAN with an active coordinator, the router appears to join successfully, but is reporting the WRONG channel. I am able to transfer data between the router and coordinator, but range is severely limited. Even when side-by-side, the RSSI is severely degraded. Opening a console to the router, I force dis-association, the PAN is re-joined (at least most of the time) on the CORRECT channel. See the console capture below:

---

+++OK
atch
E
atdb
4F
atda
OK
atai
FF
atai
0
atch
1A
atdb
26

---

The coordinator was verified to be on channel 1A. The router first detected it on channel E, but after ATDA forced dis-association, it was re-joined on the correct channel (1A).

A few notes (may be helpful to resolve):
- I've only seen this behaviour when the coordinator selects a channel high in the band (i.e., I've seen it with coordinator on channels 18 & 1A).
- When I've seen the router select the wrong channel (doesn't always happen), I've noted the channel reported seems to track the true channel the coordinator is on (i.e., when coord is on 18, router reports C, when coord is on 1A, router reports E). In these cases, the reported channel is 12 channels below the actual channel. If this is always true, that would mean that only channels 17,18,19 & 1A were susceptible. Unless there are some really odd side-lobes on the redio emissions, I find it hard to believe the router is really ON a channel 12 below that actually used by the coord, and still able to communicate.

I can provide XCTU profiles of the router and coordinator. I've also taken screenshots of XCTU register settings, to document the channel change (ATCH) & RSSI (ATDB), before & after executing a forced dis-association (ATDA).

Answer 1

What you are seeing is a Known issue and is an issue with the EM250 processor.

To keep this from occurring, don't use the full scan channel range possible of FF. Next, use the Coordinator verification (JV) function on the router.

Comments

I am already setting JV=1. However, this doesn't address the problem, since communication _does_ occur if the router & coord are close (so the router _does_ find the coordinator, and locks to this channel). If the router then moves out of the coordinators very limited range, the router does not appear to re-scan to find the coordinator on the 'real' channel, regardless of JV=1.

- Could you tell me where this known issue is documented? I'd like to obtain further details.

- Which channels are 'safe'? Is it only the top 4 channels that have to be masked off? Obviously, the mask would have to be applied on both the router & the coordinator.

---

Yes Channel Verification should take care of that as that is the reason why that command exits. It verifies with the Coordinator that they are actually on the same channel.

Check the release notes of the firmware.  You will see it listed as a Cross talk issue.

You can use any channel mask you want as long as you do not use more than 12.

---

Thanks, mvut.
I did find the firmware release notes (xbee_zb.txt, buried under the 'XCTU-NG\radio_firmwares' directory), and found the 'Crosstalk' issue - mentioned since 2011!). I have applied a suitable SC mask for a new release of firmware. Unfortunately, this will still leave the issue in play for systems already in the field.

I also did further testing to check JV=1 operation. It _does_ work as intended. Unfortunately, the router in this situation is part of a hand-held unit. When 'radio communication problems' are experienced, it is human nature to move closer to the base (coordinator), which 'fixes the issue' by again finding the coordinator on the side-band (wrong) channel. The router must still get enough dribs & drabs of packets to not actually drop the link & attempt re-scanning when it is in the 'transition zone'. If the user were to move further away from the base, the router does drop the link, and find the coordinator on the _correct_ channel (again, with JV=1). From the user's perspective this is counter-intuitive. At least we understand what is going on.

I was also surprised to find that Zigbee is NOT AGILE - the coordinator WILL NOT select another channel if it determines there is too much congestion or too many errors on the current channel. I understand WHY this is, and that it is part of the design of the standard. So as part of this firmware update, we've added a mechanism to allow the user to force the coordinator to select a new channel, then force the router to locate it. This will allow us to handle changing environments in the field.