Reputation: 1
I am using XBee DigiMesh 2.4 API-2 and Raspberry Pi. I broadcast a frame from one node to another.
Frame to transmit: 7e 0 12 10 1 0 0 0 0 0 0 ff ff ff fe 0 0 41 6c 65 78 69
Frame received in the other node: 7e 0 10 90 0 7d 33 a2 0 40 91 57 26 ff fe c2 41 6c 65 78 1e
Byte which is bothering me, is c2. It should be 02. Why it appears in this way? What is more, checksum is not correct (I read how the checksum should be calculated in API 2 mode).
With byte 0x02 it should be 0xe3 or with byte c2 it should be 0x23. I was trying to obtain the result 0x1e in many ways but I never got this value.
When I broadcast the packet in opposite direction (from second node to the first one) the same problems appear.
Both XBee´s are configurated with 9600 baudrate, no parity. Raspberry Pi UART as well.
----- Edit: I found the answer regarding to C2 byte. C2 is a bit field. C2 = 1100 0010. Bits 7 and 6 are 11, it means here that it is Digimesh. Bit 1 is set so it is a broadcast packet. https://dl.dropboxusercontent.com/u/318853/XBee%20900.PNG
Still looking for the reason of this checksum.
Upvotes: 0
Views: 294
Reputation: 11694
You can simplify your code by using API mode 1 and eliminating the need to escape and unescape values as you send and receive them. It really isn't that difficult to have your code figure out framing and ignore 0x7E
in the middle of a frame: If you see a 0x7E
followed by an invalid length, keep looking. If your frame has a bad checksum, skip the 0x7E
and look for the next one.
If you absolutely must use escaping, ensure that the length value and checksum in your frame don't include the escaping bytes, and that you're properly escaping the necessary bytes as you send them.
On the receiving end, unescape the bytes and then calculate the checksum.
Upvotes: 1