XBee 2mW Series 2.5
Richard S.
Posts: 70
Attached is a modified XBee_object_example.spin file with some notes to make it work with menu choices that display on the master xbee terminal that communicates with a slave xbee using AT (not API) protocol.· At the beginning of the program are comments on the changes made·and some set up suggestions.· It has been an arduous process to understand and successfully implement xbee's that can communicate.· Hopefully this small project will help some other struggling soul in the land of wireless communications via the PROP.·
(Profound gratitude and thanks to Martin Hebel for XBee Object Library and example programs and to Chip Gracy + Jeff Martin for Full Duplex Serial Driver.· Without these programs I would have gotten nowhere)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan
(Profound gratitude and thanks to Martin Hebel for XBee Object Library and example programs and to Chip Gracy + Jeff Martin for Full Duplex Serial Driver.· Without these programs I would have gotten nowhere)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan
Comments
Later edit:
With the coordinator connected to the PC and the other one also powered, when i use Parallax Serial Terminal (on COM4) and press keys, i have light activity on TX coordinator Xbee and the "Endpoint" Xbee RSSI LED light's up and DOUT Led also but this one very briefly. This is how they are set now:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/17/2010 4:38:34 PM GMT
Based on this:
XB.start(7,6,0,9600) ' XBee Comms - RX,TX, Mode, Baud
should i suppose the Rx is the pin 7 and Tx is the pin 6 ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Well i've got something working but i think i am not doing something right.
I have a communication between them (obiously) but i don't get that text on PST. Both Xbees are set to: 9600-8-N-1 and to use AT commands. This is continuously filling the PST screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
One thing: XB.AT_Config(string("ATDN C1"))' Set destination address to C1 (coordinator) That "C1" should be in any way programmed into my coordinator xbee?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
The serial data rate setting on the XBees controls the rate at which they talk to the controllers or terminals they're connected to. It does NOT affect how they talk to each other.
If you're using RX = pin 7 and TX = pin 6, then on the XBee side, your controller's pin 7 should go to the XBee DOUT pin and pin 6 should go to the XBee DIN pin.
It looks like you have them both on the same channel, and with the same PANID, which is good. The one whose destination is 0 should be able to send just to the one whose MY is 0, and the one whose destination is FFFF should broadcast to any XBee in range, so the settings look like they'll work. The gibberish that you get on the screen starts when you power up the remote XBee and stops when you turn its power off? In other words, are the data on the screen correlated with XBee transmissions, so you can be confident they're from the remote XBee?
If so, then I think your problem has to do with the connection to the PST window, either in baud rate or (as Mike suggested) inverted data.
You could set up a loopback on your remote XBee (that is, just give it power, and tie DIN to DOUT), and then use the one attached to the PC to run the range test, to verify that you're getting through.
Post Edited (sylvie369) : 2/17/2010 6:34:59 PM GMT
The data packages comes definitelly form the other xbee, if i cut it's power, the coordinator stops receiving those strings and starts imediately i power the other Xbee (endpoint). I will try to look on X-CTU setting of each, there are lots of fields that i have no clue what they do, all i did i changed the baud from 57600 to 9600 on both. But with same result... Given the fact that i use Windows 7, can someone tell me what should be the settings for the COM port? i have even changed the COM4 to COM3 and it is the same. I have already tried to switch P7 with P6 with no transmission whatsoever. Corectly conencted at least i get something. There is one more thing based on the explanations from the Xbee_Object_example_modified.spin It says to add some code to Xbee_Object.spin and to FullDuplexSerial.spin wich i did. I have also programmed the NI of the coordinator to be C1 and the endpoint to be N1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/17/2010 9:00:47 PM GMT
The good thing: when i type in one terminal window the result appears on the other. No matter in wich window i type, the same thing is mirrored on the other one. Print screen attached.
The bad thing:
ALL packets do arrive (this is the good thing about network protocol), they arrive in the correct order (another good thing), they are the correct data (another good thing), but they NOT arrive immediately (a very bad thing).
Further notes:
It seems that Loopback test is very unreliable because of the mesh/network nature of the series 2.5 xbees, packets are sent again if a collision is detected. This means that packets may not arrive within the timeout period of the loopback test. Sometimes they can take 2-3 seconds to arrive. This is because of collisions / interference on the channel, or if you have a network, because of the routing pattern used.
I am out of ideas and at this point i am willing to test whatever is necessary.
Thank you
later edit
Setting the "packetization timeout" to 0 in X-CTU (was 3) for each xbee helped a lot. Now i have instant communication between xbees with no packets lost whatsoever. Setting the DL and DH in coordinator to the ones provided by the ATND command in coordinator's window, actually established a true point-to-point that works flawless.
The spin code still sends a lot of gibberish on terminal window though... The only thing i've read on a forum regarding correect communication on 2.5 series is this: "your application must be able to issue an ATND command, parse and read the results"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/18/2010 4:20:57 PM GMT
What are the differences? Are they compatible?
Post Edited (nohab) : 2/18/2010 3:08:07 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
http://forums.parallax.com/showthread.php?p=870085
I hope Richard, Sylvie, Mike are going to see this thread soon, or at least someone with experience in Series 2 Xbee's. My boards can communicate perfect now between them and very fast, even between 2 different PC's, but still no luck to communicate corectlly with the spin code posted on the first thread.
Later edit:
I am attaching the code i am using, maybe i am idiot and something is wrong with the code i am using.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/18/2010 3:24:31 PM GMT
I do know that Series 1 and Series 2 XBees are NOT inter-compatible. You cannot communicate between a Series 1 and a Series 2. Unless you know that you need Series 2, I think you're probably best off using Series 1 XBees.
I'm not the best person to ask re. looking over Spin code for XBee use, especially if you're using Series 2. Hopefully someone with some expertise there will take a look.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
www.dudek.org/blog/180
blog.kevinhoyt.org/wp-content/xbee-setup.pdf
www.digi.com/support/forum/listforums?category=10&other_category_invisible=true
The last one is the official support forum for the devices.
I don't have Xbee's.... but the above links may help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Given the fact that i am connecting the ENDPOINT Xbee to the MSR1 board using an Xbee regulated board (5V) to the same kind of signals on MSR1 headers (after level translators) so basically using 5V logic signals not 3.3 i suppsoe there is nothing wrong.
later edit:
Almost DONE !
Explanation folows:
There was a problem with the translators. After i have deactivated that translator on MSR1 and have connected the P7 and P6 directly to the DOUT and DIN, i have this on the terminal window:
Hello coordinator # C1
This is node # N1
But form time to time, it misses some characters from that text. I still have to figure why
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/18/2010 4:48:44 PM GMT
The translators were a problem with some digital servo's as well.
It is ok to send a Propeller 3.3V output to an Xbee 5V input,
BUT
it is NOT ok to send an Xbee 5V output to a Propeller 3.3V input UNLESS you put a 1K resistor between them to limit the current, otherwise you may damage the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/18/2010 5:09:13 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Now i am VERY happy.
later edit:
Side note: i belive it should work the same with the level translators directly with 5V but it is something that i have to study again about MSR1. Maybe it needs a pullup resistor or something...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/18/2010 8:31:02 PM GMT
One thing that occurs to me is that your power supply on the remote end might be browning out and sending the transmitter into a short loop. I see that you have one XB pro and one ordinary XB, with the pro set up as end point/router and the vanillla one as coordinator. Which one is at the Propeller end? The XB pro draws considerably more current when it transmits.
For test purposes I'd suggest you try it without the Spin object. I don't see anything specifically in the object (which was developed for series one 802.15.4 XBees) that would cause a problem with series 2 znet xbees. But as you know, there are a lot of settings. One big difference is that in series 2, the MY setting is read-only and is assigned by the coordinator when the network starts up. The most reliable way to get started for peer to peer communication between two XBees is to use MAC addressing on each one.
-- Your coordinator serial number (=MAC address) is 13A300 404C03CF.
-- Your pro router/end point serial number (=MAC address) is 13A200 40338F1E
Note that you can turn the XBee over and read that number on the printed label, or you can read it on the X-CTU configuration screen, or you can read in any terminal window using the ATSH and ATSL commands. In X-CTU or in a terminal program using ATDH and ATDL, set the destination address of each to equal the MAC address of the other. Then write those settings to EEPROM, ATWR. (Also same panID and channel). Now when they power up, they will be pointing directly to one another without any question of intermediate steps. In Spin, put aside XBee_object for a while, and write a simple program that simply sends out a string using fullDuplexSerial or simpleTerminal. There should be no configuration at all required of the XBees. When they power up, they are preset to talk to one another only.
When the packetization timeout is set to zero (ATRO 0), the XBee sends each character as soon as it is received. That will be fine with just two XBees. But if there are several in a network, it is probably better to have a longer timeout, so that entire packets arrive whole, rather than interspersed, at the receiver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Here is what is written on Coordinator back:
XBP24-BSIT
0004 RevE
and on the front: model XBEEPRO2
And on the Endpoint:
XBP24-BSIT
0004 RevE
and on the front: model XBEEPRO2
Here is the whole package link:
www.coolcomponents.co.uk/catalog/product_info.php?cPath=55&products_id=295
Now everything works perfect but i am not using the MSR1 level translators anymore. I use just 3.3V, GND, DOUT connected to P7 and DIN connected to P6.
I have even set the packetization back to 3 on both and still works perfect. Attached is how the address are set now.
Later edit:
In the MSR1 manual it says about the level translators:
The translators require a minimum of 4.7K impedance on their output when connected. Measuring (on the xbee regulated board) between DIN and GND or DOUT and GND i have no impedance whatsoever, not under 200K anyway...
it also says :
The 24 available I/O pins are connected to three TXB0108 8-bit bidirectional voltage level translators that convert the voltage from 3.3 V at the Propeller chip to 5 V at the I/O headers and provides some short circuit protection with built-in 4 kΩ resistors.
No matter what i try on the servo headers of MSR1 (level translators ON) it is not working. I have tryied a pullup resistor with no luck. All i have succeded was to get almost full screen filled with . (point)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/19/2010 8:29:49 PM GMT
This is a response to your private email request re: series 2 XBee's.·
I ran into a similar problem with dropped characters particularly with longer strings transmitted back and foreth.· I have not solved the problem, except to use shorter strings in communication between the two XBee's.· I fiddled with 'receive and transmit buffers' on the XBee but to no avail.· It appeared to me to be a transmit data overrun of the receive buffer.· I have put my project aside for the present time.·
Good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Grants Pass, Oregon
I have managed to get it working even with the XBEE regulated board. Struggling to understand why i get unreadable charachters with it, but working perfect without this board , i have measured the DIN and DOUT on it (previously assumed that the DIN and DOUT should work at ~5V logical since the board says is for 5V signals...) and figured that they are both ~2.8V at their best. So, i have supposed that, even if this board works with 5V, the logical signals are not working at 5V at all. The signals on the MSR1 translators seems to be just fine though, so it's not from there.
So: I have connected the DIN and DOUT with resistors of 1.2K to P7 and P6 of the proppeler. It started to work instantly. Wich makes me happy because i wanted to keep the regulated board, mostly because of the connectors.
Case closed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro
Post Edited (mugur) : 2/19/2010 12:18:21 PM GMT