API, assemblying packet, not seeing on destionation

XBee & XBee Gateway XBee - 802.15.4
1

[Modem] [Function Set] [Version]
XB24 XBEE 801.15.4 10CD

[Coordinator]
CH=C
ID=3332
DH=0
DL=0
MY=1
CE=1
A2=0
SH=13A200
SL=4030EF90

[EndDev-1]
CH=C
ID=3332
DH=0
DL=0
MY=3
CE=0
A2=2
SH=13A200
SL=404B47EB

[X-CTU ver]
40002637_c

[Packet assembled to send to Coordinator]
7E 00 13 00 55 00 13 A2 00 40 30 EF 90 00 01 00 48 65 6C 6C 6F 21 F0

in packet window on EndDev-1 I attempt to send this stream to the coordinator but i do not see any data arriving at the coordinator. something in that assembled packet i have incorrect so another pair of eyes would help out as i haven’t quite gotten the hang of this API.

q1. when req’ing TX via 64-addr, API ID is 0x00, yes?

q2. do i need to include the destination 16-bit addr also?

q3. checksum can be calc’ed like this pseudo code,

unsigned byte chksum;

chksum = 0xFF
for i = 3 to sizeof(dataarray)
   chksum = chksum - dataarray(i)
next

q4. btw, is there any editing capabilities with the x-ctu app, like copy/paste/space?

2

Well, the packet looks fine: here’s the output of my packet-check program:

Packet: 7E 00 13 00 55 00 13 A2 00 40 30 EF 90 00 01 00 48 65 6C 6C 6F 21 F0
7E // Correct packet header byte
00 13 // payload length (decimal 19)
00 // Packet type: TX request with 64-bit address
55 // frame id
00 13 A2 00 40 30 EF 90 // 64-bit destination address
00 // TX options
01 // transmitted data
00 // transmitted data
48 // transmitted data
65 // transmitted data
6C // transmitted data
6C // transmitted data
6F // transmitted data
21 // transmitted data
F0 // checksum - correct

In response to your questions:
q1. Yes
q2. No
q3. Yes, assuming 1-based array indexing
q4. Pass

I don’t see anything obviously wrong in the info you’ve posted, so I guess you’ll need to look elsewhere. First thing to check would be that API mode is enabled at both ends (ATAP=1).

Failing that, you could use X-CTU to save the settings from each XBee as a .pro file, and post those files. That might provide a clue.

3

Following up to my own answer, I notice that your transmitted data starts with 01 00 and then has “Hello!”.

How are you detecting that the packet is received? If it’s something like a C program that’s expecting a string, the initial 01 00 will look like a zero-terminated string that won’t print anything.

I don’t really expect that to be the answer, but I thought I’d offer it anyway.

4

>>Following up to my own answer, I notice that your transmitted data starts with 01 00 and then has “Hello!”.

honestly, i put the 01 in for the 16-byte MY addr as a “just in case” experient. at the time, i wasn’t getting a readout on the coordinator so those bytes were inserted as a trial-error test.

i take it that with the frame-type ID as 0x00 then a 16-byte MY addr isn’t necessary?

>How are you detecting that the packet is received?

after trying your tcl script, this is the exact question i was going to post too. glad you brought it up.

i.e., if the SOH-NUL isn’t required then i need some beg delimeter char and end delimeter char so my receiving pic can grab only the pertinent data and get it into a computer for data storage.

exactly, a C prog will read that as a nul-term string which i certainly do not want.

so what do you pro’s use when using these xbee’s regarding the start and end of the pertinent data bytes you need for your apps?

>>I don’t really expect that to be the answer, but I thought I’d offer it anyway.

as a newbie to these rf devices, ya never know, certainly glad you brought it up, you beat me to it.

thx

5

archendekta,
For any received frame the data payload is in a deterministic location within the frame. The code I use for receiving detects the frame start of 0xFE then pulls in the next pieces; length, type, id & 64bit addr, then the ‘remainder’. The ‘remainder’ is passed to a frame decoding routines according the the frame type where the ‘remainder’ decoding is done.
Since the data payload always starts at the same place within the frame there isn’t a need for a start of data byte.

You could, however, add a sequence number to ensure your data is receive in sequence (in multi-hop networks the data packets could be received out of order) and another cksum if an error in your data would have very bad effects.

wr

Message was edited by: waltr

6

@archendekta

Yes, I begin to see now. You’re trying to keep the software simple on the PIC, but as waltr suggests, that isn’t going to work quite as well as you hoped.

Using special byte values to mark the beginning and end of the data part will fail, because whatever values you choose can also appear in 64-bit addresses (over which you have no control because they’re factory-set), and in the checksum byte.

Consider also the existence of the Modem Status packet. This will be sent from the XBee to its host when certain events happen, and the host won’t be expecting it. So for robustness your code should at least be able to recognise and ignore such unexpected packets. That means you’ll have to write some of the code that waltr refers to in any case.

For the packet sequence number, that’s what the Frame ID byte is for. It can take any value, so to be able to check the sequence just increment it for each packet and reset it to 1 after it’s reached 255. Avoid the zero value because that special value means “don’t acknowledge this packet”.

Also on the packet sequence number: since this is the 802.15.4 forum, I don’t believe that there’s any way for packets to arrive out of sequence because there are no routers and therefore no multi-hops. So you can probably stop being concerned about that, at least for now. You could use the sequence number to detect missing packets, but then you’d have to decide what your code would do in response. While you’re still in experimental mode I don’t think it’s worth worrying about.

Another thought occurs to me. From your comments you’re using coordinator mode, which is necesssary with battery-powered remotes but not necessary otherwise. While you’re experimenting I guess you’ll have mains-driven power available. Setting all XBees as end points - the default - and getting them to communicate that way would be a much simpler task (in my humble opinion). Once at that stage, you’d then be more prepared to tackle the extra issues that come with coordinators. Ok, well, as I said it was just a thought. Still, if I were writing a tutorial on the XBee I’d make the use of coordinators one of the later chapters.

7

hey johnf,

for this particular project, it doesn’t [have] to be in coordinator mode, i guess? i also have the xbp24-zb modules i can use for that but i want to see if i can make use of the 802.15.4 coordinator function set.

there will be one xbee module connected to a computer to collect and store data received from module end points. i thought, maybe incorrectly, that i would have more control over the data from proximity sensors sent to the xbee coordinator module attached to a computer.

as the 802.15.4 xbee modules do have the function set for coordinator/end-point, well, just thought i would attempt to make use of it. it seems from many posts on this forum though, that this function set with the 802.15.4 modules, that it isn’t as robust/flexible as say the pro zb/meshnet series. though i could be way off base on that perception.

hey waltr,

>>Since the data payload always starts at the same place within the frame there isn’t a need for a start of data byte.

that is good to know, then i can write my own function(s) to grab my frames and manipulate them as needed. i would have to eventually write them anyway for other projects. might as well write them and learn from trial/error now.

as johnf pointed out, for this particular project there will not be any routers involved thus no reason to make use of seq nums from hops. although from a learning perspective, i am benefited that it was brought up. johnf made a good point, that i didn’t consider, that packet seq wouldn’t be an issue due to these modules are all 802.15.4, thus, they’ll arrive in order anyways. but that is a very important point though. the manual do have a bunch of pages! :wink:

>>Consider also the existence of the Modem Status packet.

i do want to consider this for sure. my projects will require this to a small degree. so a reusable include file with some generic functions along this line i’ll try to develop for that.

>>Using special byte values to mark the beginning and end of the data part will fail, because whatever values…

you saved me some dev time by mentioning that. can’t get very unique with byte values. waltr helped me out with that one too, that is i can check for a length val versus a particular byte val.

things are progressing considerably better now thanks to your time & help. design issues have taken a better turn too.

i have them tx/rx’ing now, coordinator and end-point 802.15.4 modules from their respective breadboards and pics. now to make use of more of your suggestions and do some decoding functions so the lcd’s don’t have the unwanted garbage.

until the next time, many thanks,
archendekta,