I was able to restore my bricked xBee by following these instructions. Hope this helps!!Using the sparkfun USB explorer board.1. Take the module out of the interface board.2. Connect the interface board to the computer.3. Open X-CTU make sure Baud Rate is set to 96004. Go to "Modem Configuration"5. Put a check in the "Always update firmware" box6. Select proper modem from drop down menu,7. Select proper function set and firmware versionfrom drop down menus.8. Click on the "Write" button. After a few seconds oftrying to read the modem, you will get an Info boxthat says Action Needed. At this point, CAREFULLYinsert the module into the interface board.9. You may get the info box again a short while after,just use the reset button on the interface board.This should get you back up and running.It may take more than one try to get it to work, but mine worked the first time.The original problem was that some how a glitch corrupped the xBee so it wouldn't respond to the "AT" commands.Let me know if this works for anyone else.Doug
I have some news, I could not restore my ground side test xBee Pro 900, even with above tips, I switched Adafruit XBee Adaptor v1.1 and was able to restore on first try. So I have a damaged 3.3v regulator IC1 or 74AHC125N U1 chip is shorted. I will test and repair soon.
I actually "bricked" one of mine 868 XBee PRO modules this morning after a night of driving around to "range test" these little miracles. Exactly HOW I did it is a bit of a mystery, but it happened when I was experimenting with "over-the-air" configuration of my drone. (That is I had the GCS side XBee set up to use API which is a must in this case. For some reason or another I decided to play with the addressing options of the XBee's. I don't know exactly why, but I decided it was a good idea to see what they did to the communication between the modules... WRONG! Suddenly I couldn't communicate with my GCS XBee using X-CTU anymore. The X-CTU felt that there was an XBee present, but no more than that. I didn't get type, firmware or anything else, just the dreaded
" Communication with modem..OK"
" Modem Type= Name Unknown" (ID ="
" 42949672483278832"
" Modem version ="
Heck! Anything I tried didn't work, until I tried this procedure a few times. I have the original Digi Development boards, and when trying this with the RS-232 board I didn't have much luck. (I never got the message box complaining about that there were something wrong, just some crap at the bottom lines of X-CTU telling me I still was screwed. Ten I decided to try the USB board. This was another story. Exactly as described above, the message box stating there was some error and you should hold in the reset button came up. I plugged in the XBee and VOILA! There were signs of life again (the X-CTU managed to re-flash the XBee to factory default!)
Thaks VERY much for the writeup of this un-bricking process! This saved me close to $100!
Gents, I've found a solution for who's having problems with the xBee being corrupted when starting Ardupilot.
Everytime I had to pull of the blue wire to not damage my xBee, but now I found a solution.
I've added a delay command right before the serial initialization serial.begin() in the setup() session of ardupilot.
Looks like that:
void setup() {
#if GPS_PROTOCOL == 0
delay(3000);
Serial.begin(FIFTY_SEVEN_K_BAUD);
#endif
#if GPS_PROTOCOL == 1
delay(3000);
Serial.begin(FIFTY_SEVEN_K_BAUD);
#endif
#if GPS_PROTOCOL == 2
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
#if GPS_PROTOCOL == 3
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
#if GPS_PROTOCOL == 5
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
init_ardupilot();
}
That causes a 3 seconds delay during the initialization, allowing the modem to startup before sending the serial init.
You've saved my life...tks for the instructions.
What should be the process for not damaging the modem? I'm using Ardupilot with the Shield V2 + Ublox GPS + Firmware 2.6...
Should I do something to avoid that?
I really have no idea on how you do it, but checking from the status leds, i'm pretty sure that the XBee module is not started on it's usual boot mode (since the power led never comes on, and the RSSI leds behave differently)..
Is there some less-drastic way of doing this? Maybe a switch on some specific pin? A sequence of events I can get a pic to do? :D:D:D
Just wondering, if it's not under an NDA, where did you learn this?
Yes I know, I found this issue with the xbee's & the ardupilot with shield....But trying to just remove that with shunt or external jumper is extra work. I simply plug mine in manually after bind process and all systems go. And Take it out after, or simply remove the power connector from the adafruit and plug it in after bind process. That is even easier.Also doesn't require any additional soldering or cabling.
Also its not going to harm the xbee being manually plugged in and removed, they are very hard to TRULY BRICK...Taking them in and out is not going to brick an xbee....
@Peter:
Just remove the Tx (Rx on Xbee) will do. The 5V and GND still could be connected when u power up.
The Tx is the one causing the xbee to be malfunction.
Guys, Here is the workaround for the shield frying the Xbees.
When you start the Ardupilot with shield, plug everything in, the adafruit adapter the gps - everything. But DO NOT Connect the XBEE to the adafruit. First go through the full bind and configure of the ardupilot, then once everything is set, and you have calibrated the sensors etc...and removed the bind plug, then connect the xbee to the adafruit. This will not fry your xbee, and it will start communicating normally. This is the only way to avoid the xbees getting a ZAP from the bind process. I have successfully flown this way over 30 times now.
One other thing, once the flight is finished, you MUST REMOVE THE XBEE before powering off.
Trust me, do these steps and you will not zap the xbees ever again.
I been using hardware setup a long time and never gave me problems at all. I always leave it connected even in programing (i only use TX, PWR and GND). I do believe that maybe the new firmware matches some configuration bytes for Xbee and is changing something. But careful, only happens if you use 38400 as baud. You are secure if you use 57600 or anything else. In the mean time i disconnect the xbee before uploading code.
Comments
I have some news, I could not restore my ground side test xBee Pro 900, even with above tips, I switched Adafruit XBee Adaptor v1.1 and was able to restore on first try. So I have a damaged 3.3v regulator IC1 or 74AHC125N U1 chip is shorted. I will test and repair soon.
I actually "bricked" one of mine 868 XBee PRO modules this morning after a night of driving around to "range test" these little miracles. Exactly HOW I did it is a bit of a mystery, but it happened when I was experimenting with "over-the-air" configuration of my drone. (That is I had the GCS side XBee set up to use API which is a must in this case. For some reason or another I decided to play with the addressing options of the XBee's. I don't know exactly why, but I decided it was a good idea to see what they did to the communication between the modules... WRONG! Suddenly I couldn't communicate with my GCS XBee using X-CTU anymore. The X-CTU felt that there was an XBee present, but no more than that. I didn't get type, firmware or anything else, just the dreaded
" Communication with modem..OK"
" Modem Type= Name Unknown" (ID ="
" 42949672483278832"
" Modem version ="
Heck! Anything I tried didn't work, until I tried this procedure a few times. I have the original Digi Development boards, and when trying this with the RS-232 board I didn't have much luck. (I never got the message box complaining about that there were something wrong, just some crap at the bottom lines of X-CTU telling me I still was screwed. Ten I decided to try the USB board. This was another story. Exactly as described above, the message box stating there was some error and you should hold in the reset button came up. I plugged in the XBee and VOILA! There were signs of life again (the X-CTU managed to re-flash the XBee to factory default!)
Thaks VERY much for the writeup of this un-bricking process! This saved me close to $100!
Thank you, thank you, thank you!
Kind regards
// Marc
This method worked on the second try.
Everytime I had to pull of the blue wire to not damage my xBee, but now I found a solution.
I've added a delay command right before the serial initialization serial.begin() in the setup() session of ardupilot.
Looks like that:
void setup() {
#if GPS_PROTOCOL == 0
delay(3000);
Serial.begin(FIFTY_SEVEN_K_BAUD);
#endif
#if GPS_PROTOCOL == 1
delay(3000);
Serial.begin(FIFTY_SEVEN_K_BAUD);
#endif
#if GPS_PROTOCOL == 2
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
#if GPS_PROTOCOL == 3
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
#if GPS_PROTOCOL == 5
delay(3000);
Serial.begin(THIRTY_EIGHT_K_BAUD);
#endif
init_ardupilot();
}
That causes a 3 seconds delay during the initialization, allowing the modem to startup before sending the serial init.
Cheers,
Leonardo
What should be the process for not damaging the modem? I'm using Ardupilot with the Shield V2 + Ublox GPS + Firmware 2.6...
Should I do something to avoid that?
thanks,
Leonardo
I really have no idea on how you do it, but checking from the status leds, i'm pretty sure that the XBee module is not started on it's usual boot mode (since the power led never comes on, and the RSSI leds behave differently)..
Is there some less-drastic way of doing this? Maybe a switch on some specific pin? A sequence of events I can get a pic to do? :D:D:D
Just wondering, if it's not under an NDA, where did you learn this?
Also its not going to harm the xbee being manually plugged in and removed, they are very hard to TRULY BRICK...Taking them in and out is not going to brick an xbee....
Just remove the Tx (Rx on Xbee) will do. The 5V and GND still could be connected when u power up.
The Tx is the one causing the xbee to be malfunction.
When you start the Ardupilot with shield, plug everything in, the adafruit adapter the gps - everything. But DO NOT Connect the XBEE to the adafruit. First go through the full bind and configure of the ardupilot, then once everything is set, and you have calibrated the sensors etc...and removed the bind plug, then connect the xbee to the adafruit. This will not fry your xbee, and it will start communicating normally. This is the only way to avoid the xbees getting a ZAP from the bind process. I have successfully flown this way over 30 times now.
One other thing, once the flight is finished, you MUST REMOVE THE XBEE before powering off.
Trust me, do these steps and you will not zap the xbees ever again.
-
1
-
2
-
3
-
4
of 4 Next