Problems with API 0x92 frame

Question

Hello¡¡:
I am initiating me with Xbee.

I have a router whose configuration is the one shown in Figures. The configuration file is:

XB24-ZB_23A7.mxi
80
0
251
23A7
0
[A]ID=1234
[A]SC=FFFF
[A]SD=3
[A]ZS=0
[A]NJ=FF
[A]NW=0
[A]JV=1
[A]JN=0
[A]DH=0
[A]DL=0
[A]NI= Router_3
[A]NH=1E
[A]BH=0
[A]AR=FF
[A]DD=30000
[A]NT=3C
[A]NO=0
[A]CR=3
[A]PL=4
[A]PM=1
[A]EE=0
[A]EO=0
[A]BD=3
[A]NB=0
[A]SB=0
[A]D7=1
[A]D6=0
[A]AP=2
[A]AO=0
[A]SM=0
[A]SN=1
[A]SO=0
[A]SP=20
[A]ST=7D5D
[A]PO=0
[A]D0=2
[A]D1=3
[A]D2=3
[A]D3=3
[A]D4=3
[A]D5=3
[A]P0=3
[A]P1=3
[A]P2=3
[A]PR=1FFF
[A]LT=0
[A]RP=28
[A]DO=1
[A]IR=3E8
[A]IC=0
[A]V+=0



I have a coordinator connected to Arduino and I want to read data from 0x92 frame. Arduino code is:

void loop(){
// make sure everything we need is in the buffer
Serial.print("Try to connect, package size : ");
Serial.println(mySerial.available());
nbytes=mySerial.available();
if (nbytes >= 23) {
// look for the start byte
byte0=mySerial.read();
if (byte0 == 0x7E) {
// blink debug LED to indicate when data is received
digitalWrite(debugLED, HIGH);
Serial.print(" Byte ");
Serial.print("0");
Serial.print(" ");
Serial.print(byte0, BIN);
Serial.print(" ");

Serial.print(byte0, HEX);
Serial.print(" ");

Serial.print(byte0, DEC);
Serial.println(" ");

for (int i = 1; i < nbytes+1; i++){
byte1 = mySerial.read();
Serial.print(" Byte ");
Serial.print(i);
Serial.print(" ");
Serial.print(byte1, BIN);
Serial.print(" ");

Serial.print(byte1, HEX);
Serial.print(" ");

Serial.print(byte1, DEC);
Serial.println(" ");

}
digitalWrite(debugLED, LOW);
}
else
{
Serial.print("No Start Delimiter: ");
}
}
delay(100);
}


The problem I have is that the bytes that arduino is receiving do not match the specification of 0x92 frame:

Try to connect, package size: 26

Byte 0: 7e 126 ok
Byte 1: 0 0 ok
Byte 2: 14 20 Not true, is 24¡¡¡
Byte 3: 92 146 ok
Byte 4: 0
Byte 5: 7d 125
Byte 6: 33 51
Byte 7: A2 165
Byte 8: 0 0 This byte means????
Byte 9: 40 64 ok, but in the reference is byte 8
Byte 0: 8B 139 ok, but in the reference is byte 9
Byte 1: 6A 106 ok, but in the reference is byte 10
Byte 2: 98 152 ok, but in the reference is byte 11
Byte 3: 48 72 ok, but in the reference is byte 12
Byte 4: 7D 125 ok, but in the reference is byte 13
Byte 5: 5D 93 Is that the Package acknolewgement?? This byte means????
Byte 6: 1 1
Byte 7: 1 1
Byte 8: 1C 28
Byte 9: 3E 62
Byte 0: 1 1
Byte 1: 1C 28
Byte 2: 3E 62
Byte 3: 2 2
Byte 4: D 13
Byte 5: 60 96
Byte 6: FF 255

I can follow the sequence until byte 14 but because new bytes are appearing (e.g bytes 8 and 15) I am not sure about this frame.

Thank you in advance for your help

Answer 1

Try some basic code for an analog sensor reading in API Mode 2 for instance.

You should have 1 Analog Pin turned on as ADC Input.

Code:

// make sure everything we need is in the buffer
  if (Serial.available() >= 23) {
    
    startByte = Serial.read();
    
    if (startByte == 0x7E) {      
      
      Serial.print(startByte, HEX);
      
      for (int i=0; i < 22; i++) {
        Serial.print(", ");
        Serial.print(Serial.read(), HEX);
      }
    }
    Serial.println();
  }

You'll get something like this:

7E, 0, 12, 92, 0, 7D, 33, A2, 0, 40, AC, BA, 9, 74, 8D, 1, 1, 0, 0, 1, 1, 43, C1

Notice that in my case, my MSB of the 64bit Address has a 0x13 value, and in API MODE 2 (Character Escape), that value is escaped by 0x7D byte and x'ored with 0x20.

So i have an extra byte in reference to the xBee Datasheet, since i'm getting that escaped byte with 0x7D resulting in 0x7D 0x33.

Check this cheat sheet: http://www.tunnelsup.com/images/XBee-Quick-Reference-Guide.pdf

Normally in API Mode you will get 22 bytes, from start byte to Checksum byte. In my case i've got 23 bytes since there's a escape char there...

Play a little bit, and i'm sure you'll get it ok,. Just be aware of the amount of bytes you are expecting and outputing, whether you are printing the Checksum or not, or you have some escaped characters or not, and also if there are any Analog or Digital pins enabled.

That will affect the length of the API Packet for Data RX so watch out for that one, or you'll get ackward results.

Cheers //