[API AT Response Frame] Bad frame ID

Hello!

I am trying to send AT commands to my xbee module through AT API command frames.

for exemple:

7e 00 04 08 32 56 52 1d

to read the firmware version.
the response is read thanks to this simple test code:


  nbRead += read(xBeeDev,
		 byteField, 
		 11);

  for(i = 0; i < nbRead; i++){
  	printf("%x
", byteField[i]);
  }

(where byteField is uint8_t * initialized with a malloc of size > 11)

prints the bytes: 7e 0 7 8 32 56 52 00 10 66 27

my question: Why I always receive a bad frame ID (0x08 and not 0x88)
the checksum seems good for 0x88…

Using termios under linux, connected at 115200 8N2

Thanks by advance

Best Regards

The response should indeed have type 0x88. The firmware version in the reply would also be more believable if it reported 10E6 instead of 1066. Do you in fact have 10E6 loaded?

It looks to me as though you’re losing the most significant bit in each byte you’re reporting, though from your code I can’t see how. Try reading a few other parameters and see whether you ever get that top bit set anywhere.

Using packet-check and filling in the bits I think ought to be set I get this amended version of your response packet, which looks more reasonable:

[john@eccles ~]$ packet-check
API Packet analyzer version 1.2 for Series 1 XBee (802.15.4)
Note: if it prompts for more bytes and you’re done, hit return
Enter packet: 7E 00 07 88 32 56 52 00 10 E6 A7

Packet: 7E 00 07 88 32 56 52 00 10 E6 A7
7E // Correct packet header byte
00 07 // payload length (decimal 7)
88 // Packet type: local AT response
32 // frame id
56 52 // AT command “VR”
00 // status: “OK”
10 E6 // parameter value (decimal 4326)
A7 // checksum - correct

The firmware is the 10E6 indeed.

under gtkterm :


+++OK
ATVR
10E6
ATCN
OK

I am using XBIB-R and U (Serial and USB) development board REV.4.

XCTU (last version) does not work properly when I try to update the firmware (last time at 9600B). I must keep the reset button pushed while pushing the write button and then release the reset button otherwise I get something like: “lost of communication with modem”.
And it work only on USB development board, not on the serial one.

Maybe the firmware is not load as it must to be?

here is a try with others parameters:

PAN ID (under gtkterm 3332)

7e 0 4 8 33 49 44 37
> 7e 0 7 8 33 49 44 0 33 32 52

Scan Duration (gtkterm 4)

7e 0 4 8 32 53 44 2e
> 7e 0 6 8 32 53 44 0 4 2a

Packetization Timeout (gtkterm: 3)

7e 0 4 8 33 52 4f 23
> 7e 0 6 8 33 52 4f 0 3 20

Hardware version (under gtkterm : 1742)

7e 0 4 8 33 48 56 26
>7e 0 7 8 33 48 56 0 17 42 4d

Yes, those show the same symptoms.

Check your termios settings. I’ll bet it’s set to only pass through 7 bits of each received character. The ISTRIP bit in c_iflag might be set, for instance. Try
stty -a -F /dev/ttyS0
or whatever the device is.

Yes! You are absolutely right!
I done this mistake when I changed “port_settings.c_iflag &= ~(…” for a “port_settings.c_iflag |= …” and I forgot to remove the ISTRIP flag.

Thank you very much! :slight_smile:

Is there a way to set this thread to “solved”?

Not as far as I know: threads here are just records of conversations. Others can decide whether it was solved for them and if lots of people turn up with the same problem I’ll add it to the Unofficial FAQ. Glad it worked and hey (belatedly) welcome to the forum!