I have a simple setup that only involves RX/TX; Data being sent from my unit to computer seems to be fine and clean, but data from the computer to unit bounces back with extra/irrelevant characters.
I am passively monitoring my com port to see the communication, first off, it seems some of the data I am transmitting from the computer to the XBEE is bouncing back to the computer, sometimes characters are straight duplicated or received with extra/irrelevant characters in addition (and sometimes not). Also, the timing is off, by the time it sends the data sometimes my program will just say connection timed out. YES, I tested for a short between my DIN/DOUT lines on the remote XBEE.
I am using a XBEE connected to the computer with XBEE explorer, the device connected to the other XBEE ONLY uses the DIN and DOUT (TX/RX) transmission. I have been using this device with cables on 9600 8N1 perfectly; I have checked all my baud rates and even tried different ones. I have tried default settings on the xbees, 64 bit addressing (leaving MY=0) on both xbees, using MAC addressing with MAX header, with and without ACKS, etc. and NOTHING will clean up this sloppy communication I’m getting. I have tried messing with the virtual com port settings, etc, etc. The most useful setting I changed was the packet timeout, which I put to 0 so that the xbee does not wait to send any communication to one another, this resulted in the device not timing out the program when it is trying to download, but it is still impossible to download because the password is always sent incorrectly, yet is very close sometimes (I shouldn’t know this, but as I said, it will bounce back what it has received). Both devices are put as “END”… Im about to stomp on these things they are driving me crazy.
So I wonder, WHY does it seem that the XBEE Im trying to speak to is bouncing back the data packets? The only setting I never enabled was data collision prevention, and the two xbees are within a foot of each other using full power… is this a possible culprit? I wouldn’t think so since I also used 64 bit addressing.
XBEES IM USING:
XBEE SERIES 1 (XB24)
FIRMWARE: 1084
so the question becomes regarding transmission from computer to unit:
I encountered the same problem a year ago and I was using the 1083 firmware. I updated the firmware and also discovered I had a damaged antenna. After the changes I never had the problem again.
I upgraded firmware to latest, 10C8, and no improvement at all. Only difference is now it seems I can’t configure/write anything to the modem in XCTU with error = lost communication with modem (but I can still read settings). Please remember that I swap the units and it always give the same problem, data from the unit is fine, it’s data going to the unit that I see in my com port analyzer as bouncing back for no reason (with extra / wrong characters too). This isn’t half as easy as I thought it would be, lol.
Ok a restart solved the writing to the xbee issue, but regardless, I’m nowhere closer then I was before. I swwap the xbees to make sure its not an antenna issue, as the data from the unit to the computer is fine. But for some reason, data from the computer keeps bouncing back with extra/wrong characters… all the independant unit has attached to it is VCC/GND and DIN/DOUT. The actual chip its connected to works great with those connections on RS232 cable on standard 9600 8N1, I have checked those settings on XCTU, com port settings, etc… Do I have faulty units??? Should I enable a coordinator? Please give some explanation on how to implement any solutions if you can think of any. Thanks.
From your first post it sounds like you are using your own PCB/Breadboard for the remote Xbee. If this is so what are you using for the power supply and what size of decoupling capacitor are you using. I understand your frustration. When I was new to this I was ready to throw it all away but believe me, when you get it to work it will make life much easier and give you some satisfaction.
Into that port is plugged an explorer module, which in turn is connected to the local Xbee. So far, so good.
You have a remote device of some sort (unspecified) which is connected to the remote Xbee.
The remote device works fine when directly connected to the PC, but strange things happen when the remote device is connected to the remote Xbee.
If any of the above isn’t true, then I haven’t understood the situation.
Otherwise, it rather sounds as though the remote device might be using voltage levels that aren’t compatible with the XBee voltage levels.
I confess that I don’t have much confidence in that “diagnosis”. But if you could comment on the assumptions I’ve listed, and correct them where they’re wrong, maybe we could get further.
I am using a breadboard ford, as to your recap of the situation john, you are exactly correct, and both points are excellent suggestions I was starting to tread around.
The remote xbee is powered by a 3V lithium camera battery, I had also powered it directly from a 3.3V regulator LM1117(?) without capacitators but the battery seems to be working a little cleaner. I was considering voltage inconsistencies in rx/tx wired lines, I know that tx>DIN (to the computer) seems to be working fine, as well data IS getting through from rx>DOUT to the remote device as I am getting responses.
But, the data being sent to the device is bouncing back for some reason, and the data bouncing back has extra / wrong characters // ie. “hello” will bounce back after a slight delay “hjg7ello”, but the remote device I believe is receiving “hjg7ello” AND sending it back somehow.
The remote device / xbee are using 2 different power sources, device using a 3.3v voltage regulator, the xbee using the 3v battery, therefore both have different grounds and only share rx/tx lines; a common ground will not work (of course you say), I tried powering both off one power source, but it didn’t work (well), end device was fine but the xbee didn’t seem to be doing much of anything.
I now also upgraded the firmware to 10C0, and am now unable to downgrade to any other firmware I have tried. Simple says write parameters failed and lost communication with modem if I try.
Any lightbulbs turn on? Maybe flicker? I think I should look into the decoupling capacitators, attaching these to my power source and/or rx/DIN line will solve this problem? What value(s)/connection points would you guys suggest. Thanks for your ideas.
If you have access to an oscilliscope that would be the best way to determine the capacitor size. If not I would suggest at least a .1uF capacitor connect as close to pin 1 of the Xbee and ground. Since you are troubleshooting and not worried about other factors, I would also suggest putting a 4.7uF electrolytic capacitor with the .1uF also. What are you using to send the data to the Xbee connected to the computer? i.e. X-CTU, hyperterminal, or a program that you created
> therefore both have different grounds and only share rx/tx lines
If I’m reading that right, then only two wires connect the remote device to its Xbee - tx and rx. Surely there must be a common ground if it’s to work? I think if you connect the ground of the remote device to the ground of the Xbee it’ll make a big difference.
BTW, I do also agree with ford’s suggestions about checking the power supply. But make sure the grounds are connected first.
I’ve been using my own program as well as a serial port mon which I use to directly communicate with the remote xbee at times, quite similar to hyperterm.
I tried using a common ground, the data I was receiving becomes completely unrecognizable, consisting of greek looking p’s.
I tried powering the device off the 3V battery and the xbee off the regulator, or both off two different 3V batterys, again, same problem or it wasn’t actually responding by sending anything to the computer.
the power regulator is situated very close to the remote xbee on the pcb, could this be causing some sort of distruption? I tried configs without using it… but the data was garbled as usual.
I will try the bypass/elec capacitors, and although I can see why it would be a promising solution, it doesn’t feel like it will be the solution simply because the data is being (incorrectly) re-transmitted by the remote xbee… is this a feature of the xbee for debugging purposes? If not then I am hopeless after the capacitors. I was trying 1uf bypass for the heck of it and communication was broken down.
Now, one more question I’ve had, is without the use of an oscilloscope, when should I know to use a particular value .1 / .01 / .001 uf bypass capacitors? As in which value.
As for the size of the capacitors, .1uF is a common size. Lets try this, please use X-CTU to read the modem configuration for both Xbees and save the profiles. Attach the profiles to a message. Also, if possible take a few pictures of both Xbees while connected to your boards and attach the files also. This might help out a bit more since I am more of a visual person. Hang in there, we will get it to work for you.
I still agree with ford, and especially with the suggestion of providing more information in terms of configuration and pictures.
I remain bothered by this common ground business, though. You say:
> I tried using a common ground, the data I was
> receiving becomes completely unrecognizable,
> consisting of greek looking p’s.
If by a greek-looking p you mean the rho character (looks like p set in an italic san-serif font), then what display program were you using? Rho isn’t in the ASCII set, so no conceivable byte value could have generated it. Unless, of course, you’re using a computer whose localisation does include it.
You tried a common ground, and it didn’t work. Here’s my problem: you then conclude that a common ground must be a Bad Thing. I still think that a common ground is essential - if it didn’t work then something else is wrong.
The common ground provides the return path for each signal line. Without it, the signal lines end up trying to provide each other’s return paths, with results that could well be similar to what you are seeing.
If there are only two pieces of wire connecting your remote device to your remote Xbee (and they are tx and rx), then I think it will never work. If there are three, and one of them is the common ground, then it should work. If it doesn’t work, the fault is not the common ground. You need to keep the common ground, and look elsewhere for the problem.
For your other question, I don’t think it should be a problem having the regulator close to the Xbee. My circuits have the regulator very close, and I haven’t seen any problems.
And for the other question, I don’t think there are any hidden features of the XBee for debugging purposes. What you see described in the manual is what you get.