I’m trying to set the extended PAN IDs on some XBee3 Zigbee modules that I’m testing to separate out my network from other ones in the building. I’m having issues with setting the extended PAN IDs and keeping the setting. I set the extended PAN ID to a value for the Coordinator through XCTU. I then have another Xbee3 Zigbee module I’m using as a router that is connected to a microcontroller. I set the extended PAN ID on the router using the AT Command Frame (0x08) in API mode. I do network discovery from the Coordinator in XCTU and I see the router is part of the network. Checking the router’s configuration settings through XCTU (i.e., Coordinator querying router for settings over the air) I also see the extended PAN ID is set for the router.
At this point, if I power cycle the router it rejoins the network without issue. However, when I check the router’s configuration again, I see that the extended PAN ID is now set to 0. Is the extended PAN ID not being written to non-volatile memory, or is it being reset to 0 for some reason during the rejoin process?
I’ve been doing a little more testing and it’s even more confusing. I have my coordinator on the Xbee eval board and I’m talking to it with XCTU on my PC. I have the coordinator discover the router and view its settings. If I remotely change the PAN ID of the router through XCTU, the new PAN ID persists through power cycles. However, if my microcontroller changes the extended PAN ID using a AT Command Frame (0x08) in API mode, then the setting does not survive a power cycle. When I remotely view the router’s configuration in XCTU I see a blue triangle in the corner of the extended PAN ID signifying that the change has been committed to non-volatile memory.
From the microcontroller I am only sending the one AT Command Frame to change the extended PAN ID. Is there another command I need to send to commit it to non-volatile memory? From the description of the AT Command Frame it does not sound like anything else is necessary.
In case it helps, I’m running firmware version 1003 on all by XBee3 Zigbee modules.
I figured it out. After changing the configuration parameter, I needed to send another AT Command Frame with the “WR” command. After re-reading the user manual, I see it states that for the AT Command Frame, “Any parameter that is set with this frame type will apply the change immediately.” Meaning the AT Command Frame implicitly calls the “AC” AT Command. However, when viewing the updated parameters remotely through XCTU there was no indication that the parameter still needed to be written to non-volatile memory.
I believe it would be useful to have further clarification of this behavior in the user manual.