XTCU can't discover local XBees

I have 3 XBee-PRO 900HP modules and 3 grove development boards (I bought the DigiMesh kit). Initially XTCU was able to discover all of the modules when plugged into my usb ports, but then it stopped being able to discover all three of them. Today it can discover one of the three modules, but still cannot discover the other two. I have tried using the XBee Recovery tool. When I do so, XTCU tells me that the “Firmware Updated Successfully”, but XTCU still can’t discover the modules. I found some additional trouble shooting tips on the digi website, but those tips seem to be written for a PC and I have a mac. I haven’t had them long (I’ve only worked through the tutorials) and I can’t think of anything I could have done to damage them. More frustratingly, I can’t figure out how to determine if they are damaged. Any advice or suggestions would be appreciated. Thanks.

How are you discovering the radios in XCTU? Are you using the Add New radio function (+) or the Discover New radio (magnifying glass)?

What baud rates are you telling XCTU to use?

I’ve used both the Add Radio function and the Discover New Radio function. In my experience both methods work (for all 3 XBees initially, but only 1 XBee now), or neither of the methods work (for two of the XBees now).

9600 is the only baud rate that I’ve successfully discovered an XBee with (using both the Add Radio and Discover Radio methods). I’ve also tried using the Discover Radio method and selecting all possible baud rates to see if it had any affect. It didn’t. XTCU still discovers one XBee, but doesn’t discover the others.

Try this. Open a terminal window in XCTU (Tools> Serial Console) and set it to one of the COM ports your two radios that are having issues is on. Set it for 9600 baud, 8 data bits, No parity and 1 stop bit.

Open the port up.
Disable RTS and enable Break (BRK)
toggle the reset switch on the board.
Disable BRK
You should get an OK indicating you are in AT command mode. At that point, issue an ATRE followed by an ATWR and an ATCN.

The module should then be restored. repeat the steps for the 2nd module.

I followed your instructions.

“toggle the reset switch on the board.”
After this step the Associate LED stopped blinking

“Disable BRK”
A few seconds after this the Associate LED started blinking again.

“You should get an OK indicating you are in AT command mode. At that point, issue an ATRE followed by an ATWR and an ATCN.”
I didn’t receive an OK signal, or any signal in the serial console.

I also tried your instructions with the XBee module that XTCU can discover.

At the last step I got a message, but it was “~u” not “OK”

I’m not sure if that’s helpful information or not.

That means you are getting a baud rate mismatch on your USB driver.

Hmm. I did manually install the VCP Mac OSX drivers from FTDI (it was a troubleshooting step suggested by digi: https://www.digi.com/resources/documentation/Digidocs/90001110-88/reference/r_xctu_cannot_discover_xbee.htm?TocPath=Troubleshooting|_____5 ), but I didn’t try that until after XTCU stopped recognizing my XBees.

Do you have any suggestions for how to fix and/or find the cause of this mismatch?

Update:
I uninstalled the FTDI USB drivers (following the directions in FTDI installation guide). I think that means my system is now using the native mac OSX drivers. I rebooted my system and repeated your instructions, but got the same result for all of the XBees.

You can try issuing a remote AT command from a node that is in API mode. The command would be ATRE with the ATWR commands.

I don’t know how yo do it in a Mac but on a Windows based system you go into device manager, ports, properties of the USB COM port and Advanced settings. Then set optimize them for Low speed devices by settings the buffers to the smallest values they support.