3
\$\begingroup\$

We are trying to make two Xbees communicate with each other. One Xbee module (configured as transmitter) is connected to one PC (PC1), and the other Xbee module (configured as receiver) is connected to another PC (PC2). Using HyperTerminal of PC1, we tried sending multiple characters (e.g. my name is myriel kaye torres 1234567890) through the Tx Xbee.

We monitored the serial data received by the Rx Xbee thru HyperTerminal of PC2. On sending the characters, it will be received correctly by the Rx Xbee as shown in the HyperTerminal of PC2, but when we are not transmitting, we still receive garbage characters like in the image below. How can we delete the garbage characters so that the only received data will be the one that we sent?

printscreen of HyperTerminal from PC2

\$\endgroup\$
1
  • \$\begingroup\$ this is not garbage, this is a stream of valid datagrams from your XBee in API mode! \$\endgroup\$
    – zmo
    Mar 6, 2014 at 12:37

3 Answers 3

Reset to default
4
\$\begingroup\$

I had a similar problem recently with an XBee device receiving an unexpected sequence of six characters while not receiving anything while in transparent mode. It's not too easy to track this down because the diagnostic "pitch mode" isn't mentioned in the datasheet but after discussions with Digi support once I was aware of the name I tracked down this knowledge base article:

http://www.digi.com/support/kbase/kbaseresultdetl?id=3325

I was using a Sparkfun XBee Explorer Regulated and as mentioned the RSSI line was connected to a LED to ground pulling the line low that caused it to enter that mode. I removed the current limit resistor R4 connected in series with pin 6 and it solved the problem. But of course if you're using a different product the reference designators will be different so check the schematics for the particular board you're using.

\$\endgroup\$
2
  • \$\begingroup\$ We are using Xbee S1, configured in AT mode. We will try your suggestion removing the connection on pin 6. Unfortunately, we need the RSSI pin for our project. \$\endgroup\$
    – roseannvalorie
    Mar 7, 2014 at 3:08
  • \$\begingroup\$ @roseannvalorie From the documentation the S1 module doesn't use pin 6 for config mode, but it might be worth a try anyway in case a firmware or hardware revision has changed it. If it does fix it you can still use the RSSI it just can't be pulled to ground, so a LED going to positive would be OK as would an ADC pin. BTW Digi support was very good so if you don't have any luck it's worth giving them a try and if you sort it out you can post your own answer of what fixed it for the benefit of others in the future. \$\endgroup\$
    – PeterJ
    Mar 7, 2014 at 3:54
1
\$\begingroup\$

You do not say how do you send data to the XBee device. If you send data directly to the XBee device's serial line using hyperterminal it's not likely to work because your device is configured in API mode (which I can tell because every packet in API mode starts with 0x7e which is ~ in ASCII).

In order for your data to be sent through, you need to use a library that handles xbee API mode communication in your favorite language. I have written such a library a while back in C++ (which may not be the best, that one is newer and certainly better), or in python or …

Another solution would be to reconfigure your XBee using X-CTU to use the AT command firmware so you can send data through easily using a simple terminal. Though the AT commandset are less complete than the API mode commandset.

Though if you do communicate in API mode with your XBee, and still see that kind of garbage, then that's because you may have noise in your signal and all the packets coming gets shifted by a few bytes making it impossible to read from. Check the schematics, the wiring etc… That happened to me with a chip having a broken ground pin that made a false contact if the device is being moved/touched when transmitting. Random bytes were read in the middle of a datagram, making the CRC failing, and all the following datagrams impossible to read…

HTH

\$\endgroup\$
5
  • \$\begingroup\$ Our Xbees Series 1 are configured in AT mode. Frankly, we are not familiar with API mode. Could you please elaborate more on this? \$\endgroup\$
    – roseannvalorie
    Mar 7, 2014 at 3:14
  • \$\begingroup\$ Well this is API Mode and you can configure it using that. Basically, what they call "API Mode" is a binary format that includes a CRC calcul: [7E|Length|Bytes|API Id|API Frame ID|DATA|Checksum] \$\endgroup\$
    – zmo
    Mar 7, 2014 at 11:49
  • \$\begingroup\$ The XBee from which you're showing the output here is definitely in API mode. The ~……… stuff is an obvious proof. So I guess you got the other module in AT mode with which you successfully send your message and the one you're reading here that does not show your message as expected, but with all the ~ and other character you say are "garbage", which actually are just control data. Thus you need to reflash that XBee module using AT Mode, or use a library to connect to it to read the data. I'd advice you to do the latter, API mode providing a more stable communication and technical context \$\endgroup\$
    – zmo
    Mar 7, 2014 at 12:03
  • \$\begingroup\$ We tried the API mode but we were kinda lost with it. We want to transfer in transparent mode only (AP=0). We plan to receive the above data as is, but further process this using Arduino. We want to separate the control data from user data, and output the user data only. Do you have ideas how to treat this? we plan to first detect the ~ then count 6 bytes after. that will be the control data. so we will just delete this. the remaining therefore will only be user data. \$\endgroup\$
    – roseannvalorie
    Mar 8, 2014 at 10:07
  • \$\begingroup\$ that's not the way to go AT ALL. The control bits tells you where to find the data and how to extract it an you may have data split accross several datagrams. Counting 6 bytes is a terrible idea, as the amount of header depends on the type of datagram, i.e. you may have more stuff between API Frame Id and Data depending on the API Id… And the datagram length is 2 bytes. You should DEFINITELY use a library that talks API mode to get data from your XBee module, or reflash it with an AT Firmware! \$\endgroup\$
    – zmo
    Mar 8, 2014 at 11:25
0
\$\begingroup\$

It might be a lot easier than what I've said immediately below if Xbee supports "seamless" data transmission and reception but, if it doesn't then below is probably the bottom-line.

It's probably a case of you not transmitting a recognizable frame of data. You need to format your data (packetize it) into a frame with a header and quite likely an error check field. Then you may well have to send a preamble (before the frame) that allows the receiver to recognize that a frame is about to begin and correctly align itself. You can send a fixed length frame or you can embed the frame length into a header (usually straight after the preamble). Now, your receiver will know when the data begins and when it ends. Get writing some code. If the frame is in error (error check bits) then you'll need to develop a retry mechanism system.

Alternatively, and I'm no expert on Xbee, look for a mode of operation that does this for you. Plenty of RF transceivers offer "seamless" modes of communication and the packetizing stuff is all down for you - read the data sheet to find out what xbee offers in this area.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.