The same here.
Using S1 then S2 for years without any problems, then XBee3 802.15.4 and some devices are reset to factory defaults.
Module configuration is done using XCTU, module is updated to latest firmware version, plugged into our device.
The devices just send data transparently, no AT commands.
Since the issue is not frequent, it’s quite hard to capture it : I am on this issue since 3 weeks, without any clue on what is happening…
Pascal
We gave up in the end, I read the xbee settings on boot and check if it’s using our custom network id. If it is I read the settings from the xbee and save them. If not I write the saved settings back to the xbee. It works, but it’s pretty poor that it’s necessary.
Oh, and I also tapped the serial lines and recorded all traffic to and from the xbee for three weeks with a PLC turning the system off and on every ten minutes to record this happening. I can confirm that during that time we never sent an xbee write command but this still happened.
We have anther product with an embedded XBee setup procedure; it never fails; this does not mean that the module is not reset to defaults from time to time.
I am using Through Hole modules only, I wonder if there was some subtle hardware changes between S2 and XBee3 particularly on RESET and DIN/CONFIG?
On you side, do you drive RESET with an open drain IO? Also; In some posts, I have seen that a pull up resistor is used on DIN…
I probably will implement a XBee config validation/update process if I don’t find any hardware issue.
Folks, the reset line just triggers a hardware reset similar to a power cycle. It does not do anything to the firmware or any written settings.
What I would suggest is looking at page 71 of the XBee 3 hardware reference manual. You may be causing brownouts.
Thanks for your reply,
the brownout issue is concerning B versions of the silicon, and I all the issues I have are on the C version.
I can also confirm that we saw this issue on the old xbee2 units as well as on the xbee3.
This can happen if parameter settings are assigned but not written with a ATWR command. The assigned settings will be lost on a reset or a power cycle. If no settings have been written the module will revert to factory defaults.
A low voltage or out of spec power conditions could account for unexpected behavior - for example, issuing a write command during a brown out condition may not complete, or could corrupt a location in volatile memory. Theoretically a recovery could be needed by the micro to defaults. The module is not tested for out-of-specification conditions so a solid recovery routine is recommended for battery powered applications or inconsistent power situations.
Hello, I came across your comments @TheGribble which are helpful. We have had similar problems with XBee3 radios resetting themselves to factory defaults. If you are still monitoring this thread, would you comment further on the test you did? I take it that during your test you were able to get the problem to repeat some number of times by power cycling the radio module every 10 minutes for 3 weeks. Is that correct? If a power cycle is what causes the issue that would be helpful to confirm. Maybe there is a problem with the XBee3 microcontroller supervisor circuits that on rare occasion a power transition will run code resetting the radio non-volatile or something related. In another forum posts the tech support response was to not run the XBee3 below VMIN, but voltage must pass below VMIN at some point when powering on and off.
FYI: Our experience has been this problem is rare, but consistent enough to be a problem. For us we only noticed this as a problem with the XBee3 radios (802.15.4), not the older S1 or S2C. Also of note, in my search I found four other forum posts of similar issues with the XBee3 radios:
Dear Ben,
I understand your frustration and concern about the XBees resetting to factory settings. It’s disheartening to have devices returned with default settings, especially when deployed in the field. You’re not alone in facing this issue, and it can happen due to hardware or software problems.
Electrical interference or manufacturing issues could be causing the hardware problem. On the software side, unintended commands or communication errors might trigger the reset. Review your code and seek assistance from the manufacturer’s technical support to find a solution.
Remember to stay proactive, seek community support, and remain persistent. Challenges like these can be overcome with collaboration and determination.
Best of luck in resolving the issue, Ben.
We have anther product with an embedded XBee setup procedure; it never fails; this does not mean that the module is not reset to defaults from time to time.
I am using Through Hole modules only, I wonder if there was some subtle hardware changes between S2 and XBee3 particularly on RESET and DIN/CONFIG?
On you side, do you drive RESET with an open drain IO? Also; In some posts, I have seen that a pull up resistor is used on DIN…
I probably will implement a XBee config validation/update process if I don’t find any hardware issue.
The XBee 2 is based off of an Ember EM250 or EM357 depending on if it is an S2 or S2C. The XBee 3 is based off of a Geko Processor.
It is more important on the XBee 3 that you do not drop below the VCC Min. then on the XBee S2 hardware without powering off the radio when you drop below VCC Min.
I’ll join the chorus. I’ve had 2 (maybe now 3) XB3’s (through hole) reset to factory default after they have been deployed. The end user can only change the CH or BT ID. My units are battery powered and the Li-Po is set to cut out at 3.0V so they should never even approach the MIN voltage requirement.
This is quite frustrating.
Anyone having this issue should contact Digi Technical Support with full details on how to reproduce the issue. You can contact Digi Support by sending an email to tech.support@digi.com or go to my.digi.com and log in and submit a support case.
I’m trying to get a workaround going by setting Custom Defaults. I have successfully applied new custom defaults that survive power resets and software resets. It seems there are two different types of default reset commands.
ATRE - Restore Defaults to FACTORY values EXCEPT Custom Defaults I entered
ATR1 - Restores Default values INCLUDING Custom Defaults.
If the device were to encounter this errant reset condition again, would the Custom Default values be present (like ATRE) or the real Factory values (like ATR1)? If the module goes back to the factory defaults, creating a custom configuration is a waste of time and effort. It sounds as if the custom defaults would be in non-volatile memory, no?
How can I then save the new Custom Configuration and apply it to more XBee’s? Typing these into each chip via AT commands individually will get boring fast.
As always, thank you for your help.
Chad
P.S. Can anyone elaborate on this?
Use the WR command sparingly; the device’s flash supports a limited number of write cycles.
My clients will change the CH as often as needed as they move to new locations.
Please contact Digi Support as indicated above.
The same here.
Using S1 then S2 for years without any problems, then XBee3 802.15.4 and some devices are reset to factory defaults.
All, please reach out to Digi Technical Support by either submitting a ticket at my.digi.com or by sending an email to technical.support@digi.com
It sounds like you’re experiencing issues with XBee Pro S1 modules in your devices. If the modules are being returned with default settings, it could potentially be a software-related problem. It’s a good idea to thoroughly review your software and communication protocols to ensure they are correctly configuring the XBee modules. There isn’t a specific “Factory defaults” command warrior, but inadvertently sending wrong commands during initialization could reset the settings.
We gave up in the end, I read the xbee settings on boot and check if it’s using our custom network id. If it is I read the settings from the xbee and save them. If not I write the saved settings back to the xbee. It works, but it’s pretty poor that it’s necessary.