My experience is that with series one, in the API mode, a +++ sequence will get an OK response and you can do AT commands.
IMO most student/hobby apps should not use meshing- but rather, simple star or peer to peer (no coordinator needed).
stevech:
IMO most student/hobby apps should not use meshing- but rather, simple star or peer to peer (no coordinator needed).
Agree’d, that’s what I was trying to get at, use the default “Endpoint AT” firmware, unless you specifically need a different feature set.
oh great! why should it happened or we simply cant restore the firmware?
i’ve tried whatever every suggestions that i got from here or other forum, nothing could fix the same problem. isnt that funny? same problem but different solution? work fine for one and not for others?
btw, the problem is: couldnt communicate with modem. if api, it shows unknown version and couldnt write (whatever i tried, mine is series 2). and if not api, i even couldnt get any info at all (unable to communicate…). however, if try to reset (pin 5 & 10), it says lost communication…
arrrrrrrr, 2 out 3 are gone!!!
i know many of u face the same problem… any new suggestions?
i would appreciate any suggestions 
I had same issue as you and almost all mine were bricked and got sent back to Digi, one managed to get restored successfully using the usual techniques.
Its pretty basic, if you can’t re-flash the firmware using the correct technique, then its basically a gonner, Digi couldn’t offer me any other solutions themselves either other than to send them back.
Are you guys changing the baud rate’s or anything and then not changing X-CTU to match the new one? The default is 9600.
When reflashing the baud rate doesn’t matter as the base rate uses 9600… at least thats what my tests showed when I used them. Mine were originally flashed at 112k I think it is, and the one that was reflashed fine was reflashed at 9600, and I tried every rate for the others to no avail.
Sorry, you’re right, the bootloader for uploading firmware is at 115,200, once re-flashed the default is 9600.
Section 8.4 of the manual:
the module will send the Ember boot loader menu out the DOUT pin at 115200bps.
If the upload is interrupted with a power cycle or reset event, the EM250 will detect an invalid application image and enter bootloader mode. The entire ebl image should be uploaded again to recover.
Maybe the XBee is just always entering the bootloader, thinking the image is invalid? Can you see “BL >” at 115200? (When the xbee is powered up or reset)
rtaubitz:
Are you guys changing the baud rate’s or anything and then not changing X-CTU to match the new one? The default is 9600.
nope, not at all. both com port and xctu baud are same and 9600. so, how digi fixed by themselves and what is that ‘usual technique’? why not we can do it by our self? i am saying because, if it is so frequent, it should be easy to solve!
a complete nightmare!
oh, sorry forgot to mention earlier…
could that be the reason that when the firmware of xbee get corrupted, it automatically changed (or become zero) its own baud rate? so that no communications can be made? is there anyway to make a proper channel?
Did you try to see if anything shows up when plugging the XBee in while watching the port at 115200bps? If it comes up with “BL >” you’re in luck.
rtaubitz:
Did you try to see if anything shows up when plugging the XBee in while watching the port at 115200bps? If it comes up with “BL >” you’re in luck.
sorry mate, did you mean to set up baud rate that much on both xbee and com port? if it is, i have the same result (diff baud rate detected…lost communication…).
or is there anyway to watch the port? if so, please show me the way. and thnx very much for the reply.
Actually sorry that doesn’t appear to work. I just ‘bricked’ one of my version 1 XBee Pro’s by pulling it out half way through updating the firmware. It exhibited the problems you guys seem to be seeing, unable to communicate with it no matter what. Not sure if it was the same bricking though, but it doesn’t seem to respond to anything, but I was able to restore it using X-CTU by clicking “Read”, which then errors. Then selecing the correct Modem type and firmware, selecting Always update firmware and hitting Write.
But i’m guessing you’ve tried that…
I’ve rescued all XBees that seem to be bricked. Series 1 anyway. A couple were hard and I called tech support for their magic tricks.
Never had to toss one.
I do have one laptop whose serial port is flakey, voltage levels marginal. Just have to retry several times.
rtaubitz:
Actually sorry that doesn’t appear to work. I just ‘bricked’ one of my version 1 XBee Pro’s by pulling it out half way through updating the firmware. It exhibited the problems you guys seem to be seeing, unable to communicate with it no matter what. Not sure if it was the same bricking though, but it doesn’t seem to respond to anything, but I was able to restore it using X-CTU by clicking “Read”, which then errors. Then selecing the correct Modem type and firmware, selecting Always update firmware and hitting Write.But i’m guessing you’ve tried that…
yes, i am. read/write/reset/… etc etc every way. now what i am wanted to do is somehow fixed the baud rate. i guess it lost its own memory and dont get it 9600. i need to make it. it might solve the problem.
thanks anyway. if you find any other suggestions, that would be great and eager to try. you might find the images (that i tried on my post in this sections (ahare is my name))
good day.
i add the code here again…
http://www.postimage.org/image.php?v=aVpvT9r
http://www.postimage.org/image.php?v=aVpvVEA
http://www.postimage.org/image.php?v=Ts1hn190
http://www.postimage.org/image.php?v=aVpvY8J
A lot of the time the messages X-CTU gives aren’t quite accurate, it’s only guessing as to why it can’t communicate etc so you have to manipulate it about a bit to get it to do what you need it to do (enter bootloader mode and reprogram the XBee).
rtaubitz:
A lot of the time the messages X-CTU gives aren’t quite accurate, it’s only guessing as to why it can’t communicate etc so you have to manipulate it about a bit to get it to do what you need it to do (enter bootloader mode and reprogram the XBee).
oh thanks once again. do you mean usb explorer board (bootloader) to reprogram it?
another surprising things. before we program 2 xbees (series2) to communicate each other. to do that we program their destination address to match each others. since then we can read coordinator but couldnt router. however, they can send and receive datas which can be seen in terminal. isnt that funny?
we cant read or write firmware, but it can get signal from other xbee…
any comments?
one more thing, the bad one getting heated (scary type! too hot) but the other one is normal. any suggestions?
actually what i wanted to say is the router/end device is gone crazy and coordinator is good. so when we try to get info from router(bad), we get everything what we type on the terminal, but if we want to send something through coordinator(good) to the router(bad), we cant.
but at that time we always got rssi turned green until we stop typing on coordinator terminal. isnt that means it is trying to receive but couldnt? oh, i’m from mechanical background.
thanks very much and i really appreciate it (you know, 4 days and nights…)
I haven’t been able to get so much as a blip of signal out of my xbees. I’m trying to program one using an arduino duemilanove board with the microcontroller removed. Can the 3.3 converter source enough current to service an xbee? it seems like I’m the only one having trouble. I tried a resistor voltage divider to bring the uart logic down to 3.3v but when that didn’t work I tried using op amps to adjust the voltages going both ways to the right values. maybe my usb cord is too long? it doesn’t take much power though… I don’t know what’s wrong!! I get all the same messages from xctu whether or not the data lines are plugged in at all. what am I doing wrong? did I fry them both somehow?
one more thing, is there any way to format xbee’s memory?