SparkFun Forums

[Excalbian]

I get the "unable to communicate with modem" message when the baud rate is wrong or the #bits is wrong and the module is in AT command mode.
I get "name unknown (ID=42949672481228316)" if the module is in AT mode and the API box is checked. I also get this message with a module in API mode and the baud rate is wrong.
Keep trying different baud rates with and without the API box checked.

Thanks for the suggestion. I've gone through all the baud rate options (in the drop down) without any success. I am inclined to think that it is not a baud rate issue, because when set to 9600 I can get an "OK" response ocassionally in the terminal tab. It always happens after resetting the module (shorting the RST to GND) and doesn't happen consistently.

[waltr]

Since these are the PRO modules they do use a higher current than the non-Pro. The XBee explorer boards have a small linear regulator. Check the voltage on the XBee with a scope. It could be that the voltage is dropping when the module transmits. Or try bypassing the Explorer regulator with an external 3.3V PS.

The only other suggestion I have now is to open a trouble ticket with Digi Int.

[Excalbian]

Since these are the PRO modules they do use a higher current than the non-Pro. The XBee explorer boards have a small linear regulator. Check the voltage on the XBee with a scope. It could be that the voltage is dropping when the module transmits. Or try bypassing the Explorer regulator with an external 3.3V PS.

The only other suggestion I have now is to open a trouble ticket with Digi Int.

Waltr,
Thank you very much for the continued advise and help. I don't have access to a scope so I couldn't try exactly what you suggested. I did hook up both my DMM and my logic analizer, and neither registered a significant drop in voltage (the DMM registered 3.32 alternating with 3.33 but it didn't appear to correlate with any particular activity).

I did hook up the other (XBee pro 900) module using a second SF XBee explorer regulated and using my PicKit2 as a uart tool. Interestingly enough, for every (and any) byte transmitted, I recieved one (and exactly one) null (0x00) charater on the other module. This behavior was confirmed going both ways (module one to two and two to one).

Any suggestions are welcome, and appreciated . If not, I'll plan to open a support ticket with digi in the morning.

[stevech]

I did hook up the other (XBee pro 900) module using a second SF XBee explorer regulated and using my PicKit2 as a uart tool. Interestingly enough, for every (and any) byte transmitted, I recieved one (and exactly one) null (0x00) charater on the other module. This behavior was confirmed going both ways (module one to two and two to one).

Any suggestions are welcome, and appreciated . If not, I'll plan to open a support ticket with digi in the morning.

Is it possible that the PicKit2 software is indeed sending the null?

[Excalbian]

Is it possible that the PicKit2 software is indeed sending the null?

I have used the PicKit2 device and software with other devices and it has worked as expected. I also noticed that when I would enter characters in the terminal tab of the XCTU (connected to the FDDI board) it would appear as nulls on the PicKit2 connected XBee.

[waltr]

It may also be possible that the XBee module has the sleep function on. Therefore it spends most of its time asleep and non-responsive.

Read the parameters in the Modem Config tab of X-CTU (it may take a number of try's to catch it awake. Then check the sleep parameters.

[ahare]

I get the "unable to communicate with modem" message when the baud rate is wrong or the #bits is wrong and the module is in AT command mode.
I get "name unknown (ID=42949672481228316)" if the module is in AT mode and the API box is checked. I also get this message with a module in API mode and the baud rate is wrong.
Keep trying different baud rates with and without the API box checked.

you simply cant believe how many times we have tried!!! now our temper is just a thin line behind to smash it down!

some questions arises in my mind during this diagnosis period,

1. if it is a common problem, shouldnt be there a easy solution? if not, why the manufacturer dont stop producing series 2 until they can fix it!

2. why every time we need to write the updated firmware, if the initial version works fine why we need to upgrade it as it seems most of the time something goes wrong while we updating!

i just wanted to share it, no offense guys, you cant believe how much nightmare this problem can produce!!! [believe me!]

[gypal2010]

Hi guys


I had the same problem with my Xbee Pro, I coudn't write it because comunication was lost with modem and either I coudn't read it (Failed to enter command mode-Unable to read Version (ATVR) )....

After looking for a solution in so many forums and blogs (in english and spanish) finally I found the solution here.

I use the XBee Explorer USB card, so it doesn't have a reset button, but doing the steps posted by jimmyhowarth, the xbee worked

1) Select "Always update firmware"
2) Under modem select "XBP24-B"
3) Under function set select "ZNET 2.5 COORDINATOR AT"
4) Put XBee module into USB board and plug into computer
5) Press write button
6) When dialog button pops up, reset the XBee module. I did this by turning over the XBee module and sticking an unraveled paper clip through the two holes marked "GND" and "RST".
7) The firmware should start to load.

Hope this helps.

Jim

I hope this solution works for people who has this problem

Regards from Colombia

Thnx

[Excalbian]

After opening a support ticket with Digi (they directed me to update the firmware which also didn't work), someone else (on an R/C UAV forum) suggested that a solution he's found is to short out the diode in front of Din. Sure enough, as soon as that was done, not only could I read and write the module from XCTU but it worked with the other module as a transceiver.

[gtwilliams]

GYPAL2010 is absolutely right. I stumbled upon this solution a couple of times by accident and never could remember what I did to get the units to load new firmware! How frustrating.

My experience is that the first time through the procedure the units do not reset, so I end up gently removing them from the USB explorer and placing them back in a few times. If that doesn't reset them then I hit the cancel button and try again.

Best of luck.

[alaa]

i got a used X-bee modulo that gose to sleep mode each 10 sec and i wand to reset it to the factory settings so i can use it propaply any idea how to do so ??
and i want to mention that i have the RS232 board and the USB board .

[waltr]

Use Digi's X-CTU utility. Software and Document is on Digi's web site.

[briang]

I am struggling with an XB2B-WF - SMT.
I've read many posts on baud rate changes and recovery - none seem to work ! I have a custom board, but DIN, DOUT, DTR and RTS are connected to PC USB via FT232, and I have a reset button.

After reset with UART lines held for bootloader recovery, the XBEE sends out 1 byte at 38400 - 'U' (hex 55). I do not get the suggested bootloader menu, but to a 'B' it responds with '1000U' ?? So I set the PC comms to 38400 and tried to write parameters with "update firmware" checked.

The PC sends the entire image at 38400. The XBEE starts responding (with 'U') at 38400, then after 2 or 3 secs switches to 115200 baud rate !!!! no wonder the device is never able to accept and load the firmware image - always fails !

anybody seen this ? any ideas ?

Thanks
Brian
(ps have raised a ticket at Digi - waiting for feedback..)

[briang]

Fixed ! a combination of USB port settings, plus powering device while holding reset worked....

[stevech]

one trick, with series 1 (not sure about S2)...
If you have an XBIB...
run XCTU at 9600 baud. Select the correct product, e.g., XBee 802.15.4 vs. the XBee Pro.
Select firmware version you have used.
Press/hold RESET button on XBIB
Tell XCTU to write firmware
wait a second or two
Remove finger from button.
Often this works.

No XBIB, or you can try this too with XBIB
Remove XBee from socket
get XCTU to state as above
tell XCTU to write firmware
quickly and accurately plug XBee into socket that already has power