TX status packets byte order

XBee & XBee Gateway XBee - 802.15.4
1

after i TX my API data packet I receive a TX status packet such as the following when i print it out to a term window

byte0= [89] 'API ident
byte1= [4] 'frame ID byte
byte2= [7E] 'start delimeter
byte3= [0] 'msb len
byte4= [3] 'lsb len
byte5= [0] 'status byte

however, i thought it should be in this order according to the docs;

byte0= [7E] 'start delimeter
byte1= [0] 'msb len
byte2= [3] 'lsb len
byte3= [89] 'API ident
byte4= [4] 'frame ID byte
byte5= [0] 'status byte

is the TX status packet arriving OK or is it out of synch or something?

2

I suppose anything is always possible when dealing with an embedded system, but let’s assume for a moment that the radio is operating properly.

The API packets are generated at the UART and therefore sent to the host in the correct order. It would be helpful to understand how your connection is made to the terminal. Are you using the interface board? Is this a direct serial connection from the radio to the terminal program, or are you going through some middle software that interprets your API packets for you?

Using the X-CTU as the terminal, you should be able to generate your API packets, and see the status and receive packets come through on the Terminal screen. Is this how you are generating your TX packet?

3

i’m generating the API packet via a pic basic pro app on a pic16f88 to an Xbee that transmits it to the xbee connected to a pc.

connection to the terminal is made via an XBee 802.15.4 series I on a Droids.it 990.002 v2 usb board. X-CTU terminal picks up the data packet fine.

on the originating pic, there is a pin that sends the TX status packet to a terminal app, realterm. that is where i see the bytes “seemingly” out of order.

when i put an XBee on each dev board, generating the same packet manually, the TX status packet arrives in the order it should.

could be my code that is waiting/reading the TX status packet is out of sync or something. i’ll revisit it and see what i can do with it.

thx

4

i have it in the correct order now. it was my incorrect coding for waiting on the start delimiter for the TX status packet. now i can grab the status byte.

thx!