S2C, Issue with encryption in api mode

Question

In preparation of further use, right now I'm testing 2 XBee's with USB-Explorer and the XCTU-Software at my laptop.
One is configured as coordinator. PAN-ID is set. The other is configured as router. PAN-ID is set. Both are in API-Mode 1.

I can send unicast-messages from the router to the coordinator with frame-type 10, 64-bit-destination-address 00 00 00 00 00 00 FF FF, 16-bit-destination-address 00 00.
(7E 00 13 10 01 00 00 00 00 00 00 FF FF 00 00 00 00 6D 6F 69 6E 52 EB)


I can send broadcast-messages from the coordinator to the router with frame-type 10, 64-bit-destination-address 00 00 00 00 00 00 FF FF, 16-bit-destination-address FF FE.
(7E 00 19 10 01 00 00 00 00 00 00 FF FF FF FE 00 00 68 65 6C 6C 6F 43 62 72 6F 61 64 94)

All works fine without encryption!

When encryption is enabled, I can still send broadcast-messages to the router without problems.
Once I have sent the first unicast-message from the router to the coordinator (which is received succesfully), the router get a "Many to one request indicator" (frame-type A3) from the coordinator.
After this point the router can't receive broadcast-messages from the coordinator anymore. Instad of the broadcast-messages the router get only invalid frames. Most of them seems to be almost ok, but the Start-Delimiter is 00 instead of 7E and they are much to long (up to several hundred bytes). Some are totally broken.

What goes wrong in this case?

Regards!

Answer 1

What encryption options are you using (EO) and what firmware versions on the XBee modules?

Comments

sorry wrong reply

Answer 2

Sorry for the late answer!!

The Firmware on both XBees is 4059.

The Settings are:
EE = 1
EO = 0
KY = 0
NK = 0


A normally received package looks like this:
7E 00 15 90 00 13 A2 00 40 F7 53 98 00 00 02 11 00 00 00 00 00 00 00 00 85

A invalid received package looks like this:
00 15 90 00 13 A2 00 40 F7 53 98 00 00 02 11 00 00 00 00 00 00 00 00 85 FF FF FF FF ... and a lot more "FF"

Comments

What are you using for the API output?  Do you have the same issue if you use transparent mode?

Answer 3

Each of the XBee modules is connected to its own instance of XCTU. XCTU is version 6.3.0 , Build ID: 20151110-8.
I use USB-adapters with FTDI-Chip. The baud-rate is set to 57600.

I didn't try this in transparent-mode because I want to use the modules later in a mesh - setup with one coordinator and up to 20 routers.

In case its important, I've set the the ZigBee Stack Profile (ZS) to 2.

Thanks so far for your helpfullness!

Comments

Again, do you see corrupt files when using transparent mode over API mode? I am asking to help narrow down where the issue is.

Answer 4

"Again, do you see corrupt files when using transparent mode over API mode?"
Sorry, I didn't know this option before. That's why I didn't try it.
I let the coordinator in API-mode and switched the the router to transparent-mode. Did you mean this?
With this setup I don't get corrupted files. But when I was sending some more frames as sequence (transmit interval 500ms, repeat 16 or 32 times) I've got some big delays after sending the 9th frame and also some lost frames.

Meanwhile I fiddled around with some other settings and I've found, that the many-to-one-request is the problem not the encryption. First I've had the AR-Command disabled (AR = FF). When I've set it to a lower value I've had the same problem without encryption. Now even the transmit-status-frame that the router generates after sending a frame, was corrupted.

I've tried some other laptops and usb-adapters and finally tried to update the XCTU-Software. There was a Update available. And now the incredible, the second row of the changelog says:
"•Fixed a bug that was causing the API Console to stop parsing frames after receiving a 'Many to one Indicator' frame."
I think the problem is solved.

Thanks again for your help!!

But I think, there is another little bug in the XCTU-Soft. When the router generates an "Many to One Request Indicator"-frame, this frame will be followed from a invalif frame wich contains only a "85". Funnyly this "85" is the checksum of the former "Many to One Request Indicator"-frame.