I have problem with Xbee’s. One Xbee is connected to PC, second Xbee is connected to laptop. They are communicating over SERIAL port without problem, but Xbee’s wont recieve and trasmit code, because, they wont associate.
Channel C
PAN ID 3332
DL 456
MY 123
CE 1
A2 = 7
End point Xbee returns AI 0x02, No PAN ID found…
Version of Xbee’s firmware is 1084.
Where is a problem ? What should I do ? Thank you
First of all, please realize the forums are for peer-to-peer support and that Digi International does NOT guarantee a reply here (see our banner at the top level of the forum).
That being said, I’d say updating the firmware on both adapters to the current release of 10C8 would be a good place to begin. And if that doesn’t help, please contact Support either by phone or via the Web Portal on our Support site.
Have you loaded one xbee with the coordinator firmware?
Why do you say they cannot connect? Have you executed ND?
Are you using AT command or API?
Could you be more specific.
I have uploaded firmware to 10CD, and It works. Its strange, that older version didnt work 
but my problem is solved, so I am happy 
Now, I understand, how Xbee works. thank for reply.
I have last question. What happend, when 2 Xbee’s will send message at the same time to coordinator ?
Message was edited by: whisper
802.15.4, ZNet, and ZigBee-based XBee modules use CSMA/CA in order to allow “simultaneous” access to the radio medium. When two XBee modules attempt to transmit at once, a collision occurs and each module generates a random, very short, delay. The transmissions will be retried at different times and the collision will be avoided.
The data will arrive at the coordinator in the order it was received. If you are using the API mode at the coordinator the API packet will contain the address of the node the received data was from.
My message looks like this “A0000” A is identifier of senzor and 0000, this is value from senzor. So, if i understand right, if two Xbee’s will send messages at the same time, recieved message will lookslike this “A0000B0000C0000” or “B0000A0000C0000” …etc, not “A000CB000000000”, this is wrong message of course
I am not using API.
Whisper:
Yes, the receiving XBee will receive discrete packets if you can ensure that the trasmitting XBee modules are sending discrete packets. Of course, the simplest way to ensure this is by using API mode throughout your application. However if this is not an option there are some parameters you may tune.
You could adjust the RO “Packetization Timeout” parameter of your AT nodes such that it is at least as large as your packet size. This will ensure that RO “characeter times” are waited for before the XBee will transmit an RF packet.
Another suggestion I would have is that you may wish to add a checksum to your data packet. You could change your message format to be:
INNNNSS where I is the identifier, NNNN is the numeric value of your sensor reading (in ASCII), and SS is the checksum, in ASCII-encoded hexadecimal, of the entire packet. This way, if you did receive two packets on top of one another you would be able to reject the data because the checksum would be bad.
How would you calculate the checksum? Assume we have the packet:
A0123
If we took the ASCII values of A, 0, 1, 2, and 3 we would get:
65 + 48 + 49 + 50 + 51 = 263
Next we take 263 mod 255:
263 % 255 = 8
Now we convert 8 to hex and then to ASCII:
8 = 0x8 = “08”
Thus, our packet would become:
A012308
Now you could read in 7 bytes for every sensor read.
Assume you received the following:
A012308BB22220B
Reading in the two packets you would get:
A is 0123 (08 checksum good)
B is 2222 (0B checksum good)
…and know the samples for A and B are good. Again, here is how B’s checksum would be calculated:
66 + 50 + 50 + 50 + 50 = 266
266 % 255 = 11
11 -> hex = 0xb -> ASCII = “0B”
Assume you received:
AB22012308220B
Depending on how you implemented your parsing, you may still see two packets:
A (rejected because the next number is not an integer)
B is 2201 (checksum 23 is bad, sample rejected)
Why would it be rejected? How could you know two packets overlapped one another? Because:
66 + 50 + 50 + 48 + 49 = 263
263 % 255 = 8
8 -> hex = 0x8 -> ASCII = 08
08 != 23 therefore the sample is bad and it will be rejected.
There are, of course, more robust techniques you could use for data validation and packetization but I figured I would illustrate one just in case you might find it useful.
Best regards,
Jordan
jordanh: thank you very much for all information, which you gave me, really! Its really helpfull and I understand it.