802.15.4 Received Packet 16-bit Address IO Encryption RF Data not the same

XBee & XBee Gateway XBee - 802.15.4
, , , ,
1

I am using X-CTU with two 802.15.4 series 1 XBee modules and testing 16-bit Address IO Sample.

One of the XBee will sample ADC pin and send the reading to another XBee.

I tried 2 expreiments: one is non-encryption transmission and another one is transmission with encryption enabled.

Set EE=0 or 1, KY = 128 bit HEX string, Sample Rate = 2000ms etc…

The problem is that when I compare the 2 results (read the console output in the X-CTU), the RF Data part I got under Encryption mode is different from the Non-Encryption mode. It has 4 more bytes.

By right, the RF data content should remain the same content with OR without encryption. But the below results said NO and it puzzled us. Can anyone here explain why on earth there are more bytes in the RF data (original message should not be altered after decrypted).

API Mode 2, 802.15.4 Series 1, firmware 10e6

0x83: Recieved Packet 16-bit Address I/O without encryption

Frame: 7E 00 0A 83 00 10 2D 00 01 02 00 01 CC 6F
RF Data: 01 02 00 01 CC

0x83: Recieved Packet 16-bit Address I/O with encryption

Frame: 7E 00 0E 83 00 10 2C 00 FF 04 B5 47 01 02 00 01 CC 71
RF Data: FF 04 B5 47 01 02 00 01 CC

2

No it should not be the same as you have enabled encryption. When you do this all data is encrypted before it is sent. This includes ADC and DIO functions. In order to receive it and understand what is sent out, you must have encryption enabled on the receiver as well with the proper key set.

3

OK, so it is different.

How different? Is there any specification on the different frame? Any manuals I can look into?

My sender and receiver have the same key and enabled the encryption. They should know each other’s message.

Based on using X-CTU console mode, I can clearly see the frame “RF data” part is being decrypted except those extra 4 bytes.

Why include those 4 bytes since you have already decrypted the RF data?

If I write you a letter and put it a box with key lock, when you open it with the same key, the letter will have extra letter header?

This is where it puzzles me and no documentation on this from Digi.

4

OK, so it is different.

How different? Is there any specification on the different frame? Any manuals I can look into?

My sender and receiver have the same key and enabled the encryption. They should know each other’s message.

Based on using X-CTU console mode, I can clearly see the frame “RF data” part is being decrypted except those extra 4 bytes.

Why include those 4 bytes since you have already decrypted the RF data?

If I write you a letter and put it a box with key lock, when you open it with the same key, the letter will have extra letter header?

This is where it puzzles me and no documentation on this from Digi.

5

RX (Receive) Packet 16-bit Address IO (API 1)

7E 00 0E 83 00 10 2C 00 FF 04 B5 47 01 02 00 01 CC 71

Start delimiter: 7E
Length: 00 0E (14)
Frame type: 83 (RX (Receive) Packet 16-bit Address IO)
16-bit source address: 00 10
RSSI: 2C
Options: 00
Number of samples: 01
Digital channel mask: 00 B5
Analog channel mask: 02 00
DIO0/AD0 digital value: High
DIO2/AD2 digital value: Low
DIO4/AD4 digital value: Low
DIO5/AD5 digital value: Low
DIO7 digital value: Low
DIO0/AD0 analog value: 02 00 (512)
Checksum: 71

6

This is from XCTU decrypting the API frame. Looks valid to me.