One of our suppliers has sent a notification of the EOL of one of the Zigbee modules which we use in many of our products. We currently use between 10,000 and 20,000 of the XB24-Z7WIT-003 modules yearly.
The EOL notice suggests XB24CZ7WIT-004 as the replacement for the XB24-Z7WIT-003. If I remember correctly, the trailing numbers in the part number specify which firmware is loaded into the module. We require the Router API firmware to be preloaded into our modules. Does the XB24CZ7WIT-004 have the router API loaded, or do we need a different part number?
Are there any compatibility or interoperability issues between these two modules? Will we have to change our software to support these new modules? Do they have different initialization requirements, or are the transmit and receive commands different in any way, or are they drop in replacements?
We also use around 1,000 to 2,000 XBP24BZ7SIT-001 modules. Are these modules (Coordinator API mode firmware) also going EOL, and if so, what is the suggested replacement? If they are also going EOL, the same questions about compatibility and interoperability issues with the replacement?
The New product that is replacing the old XBee ZB module has a larger processor. As a result it does not require a total of 6 different firmware versions to cover Coordinator, Router and End devices in both AT and API mode. It only requires one firmware version for ALL.
The module will come pre-configured as a module in Router AT mode. To configure it for Router API, simply set the AP command to either a value of 1 or 2.
If I have current code to only deal with API firmware, how much trouble would it be to detect that this module is installed instead of the old one, and send it this command? I’m assuming I would have to a) know the proper baud rate, b) send it an AT command and see if it responds, and if so c) send it the command to switch, and if not, then either d) I’m not at the right baud rate, e) I’ve got an old module with API firmware, or f) I’ve got a new module that has already been switched to API mode. I also assume that this setting sticks past power cycles (possibly after issuing the API version of the AT command to save parameters)? If this is doable, then I may not have to go through a pre-processing step to make sure these are in API mode before soldering them to our boards.
Well, that’s exactly what we don’t want to do. We used to do that back in the old days to update the stock firmware to the API firmware, before we found out we could order modules directly with API firmware. It is a time consuming and error prone process (too easy to miss a module, and then you’ve soldered it on a board and can’t easily get it back off). Plus it adds extra steps to the production process, which adds time. Might be ok for a hobby application, but when you are deploying 10’s of thousands, it doesn’t work out so well.
We’ve done that, and such options involve additional cost. Since I don’t have to worry about new modules going onto old boards, then I should be able to modify my software as above to detect a new module, put it into API mode, then continue as before, and not have to worry about the difference. That is as long as nothing else changes. I’ll have new modules to test soon and will be able to verify if this is a workable solution.