This project has moved. For the latest updates, please go here.

Node Identification Indicator Frame (0x95)

Coordinator
Feb 29, 2012 at 11:48 AM
Edited Feb 29, 2012 at 11:49 AM

I know this frame is sent after a new node has joined the network. I have made a test in which i have two XBee (coordinator and router) and i reset each of them. After i reset the coordinator i get this:

 

0013A20040692938 <- ModemStatusResponse ApiId=8A,Length=02,Checksum=75,Error=False, status=0

0013A20040692938 <- ModemStatusResponse ApiId=8A,Length=02,Checksum=6F,Error=False, status=6

 

This means coordinator (serial number 0013A20040692938) send out its uart two modem status response frames indicating it was rebooted (status=0) and started (status=6). Next i did the same with router:

 

0013A200406E92A6 <- ModemStatusResponse ApiId=8A,Length=02,Checksum=75,Error=False, status=0

0013A200406E92A6 <- ModemStatusResponse ApiId=8A,Length=02,Checksum=73,Error=False, status=2

 

This means that router (serial number 0013A200406E92A6) was rebooted (status=0) and associated (status=2). In this case i get an extra frame received by the coordinator - Node Identification Indicator (0x95). This is good because it means that a new node has joined the network. This is how it looks like:

 

0013A20040692938 <- ZNetNodeIdentificationResponse ApiId=95, Length=20, Checksum=13, 
Error=False, senderAddress=897C, senderSerial=0013A200406E92A6, remoteAddress=92A6, 
remoteSerial=897C0013A200406E, deviceType=1, mfgId=4126, nodeIdentifier=, option=2, 
parentAddress=FFFE, profileId=49413, sourceAction=3

The question is what does the senderSerial and senderAddress mean? I though those values were indicating which module send the frame and remoteSerial and remoteAddress were indicating which module has joined the network but in my case those values should be equal (there are no hops possible). I tried sending remote at command to this unknown serial and network address but received failed to send status. Any ideas? Can anyone reproduce it?

Coordinator
Feb 29, 2012 at 11:55 AM

Here is the documentation

Developer
Feb 29, 2012 at 12:56 PM

The remote addresses are meant to be the target device, I.e. The coordinator.

Maybe, as this was a broadcast packet these values were not set and ended up being filled with random data ? Just a guess. Can you provide the raw byte data received ?

Coordinator
Feb 29, 2012 at 2:06 PM
Edited Feb 29, 2012 at 2:07 PM

Now the serial is different but the same network address... But this packet is always a broadcast isn't it?

LowDebug	Received 6 bytes
LowDebug	Read Length MSB byte, val is 0
LowDebug	Read Length LSB byte, val is 2
LowDebug	packet length is 02
LowDebug	Read API ID byte, val is 138
LowDebug	Handling ApiId: 138
LowDebug	Read Modem Status byte, val is 0
LowDebug	Checksum byte is 117
LowDebug	Read Checksum byte, val is 117
Debug		Received ModemStatusResponse: 
		ApiId=8A, Length=02, Checksum=75, Error=False, status=0
LowDebug	Received 6 bytes
LowDebug	Read Length MSB byte, val is 0
LowDebug	Read Length LSB byte, val is 2
LowDebug	packet length is 02
LowDebug	Read API ID byte, val is 138
LowDebug	Handling ApiId: 138
LowDebug	Read Modem Status byte, val is 2
LowDebug	Checksum byte is 115
LowDebug	Read Checksum byte, val is 115
Debug		Received ModemStatusResponse: 
		ApiId=8A, Length=02, Checksum=73, Error=False, status=2
LowDebug	Received 38 bytes
LowDebug	Read Length MSB byte, val is 0
LowDebug	Read Length LSB byte, val is 32
LowDebug	packet length is 20
LowDebug	Read API ID byte, val is 149
LowDebug	Handling ApiId: 149
LowDebug	Read 64-bit Address byte 0 byte, val is 0
LowDebug	Read special byte that needs to be unescaped
LowDebug	found escape byte
LowDebug	next byte is 0x33
LowDebug	unescaped (xor) byte is 0x13
LowDebug	Read 64-bit Address byte 1 byte, val is 19
LowDebug	Read 64-bit Address byte 2 byte, val is 162
LowDebug	Read 64-bit Address byte 3 byte, val is 0
LowDebug	Read 64-bit Address byte 4 byte, val is 64
LowDebug	Read 64-bit Address byte 5 byte, val is 110
LowDebug	Read 64-bit Address byte 6 byte, val is 146
LowDebug	Read 64-bit Address byte 7 byte, val is 166
LowDebug	Read Address 16 MSB byte, val is 104
LowDebug	Read Address 16 LSB byte, val is 39
LowDebug	Read Option byte, val is 2
LowDebug	Read 64-bit Address byte 0 byte, val is 104
LowDebug	Read 64-bit Address byte 1 byte, val is 39
LowDebug	Read 64-bit Address byte 2 byte, val is 0
LowDebug	Read special byte that needs to be unescaped
LowDebug	found escape byte
LowDebug	next byte is 0x33
LowDebug	unescaped (xor) byte is 0x13
LowDebug	Read 64-bit Address byte 3 byte, val is 19
LowDebug	Read 64-bit Address byte 4 byte, val is 162
LowDebug	Read 64-bit Address byte 5 byte, val is 0
LowDebug	Read 64-bit Address byte 6 byte, val is 64
LowDebug	Read 64-bit Address byte 7 byte, val is 110
LowDebug	Read Address 16 MSB byte, val is 146
LowDebug	Read Address 16 LSB byte, val is 166
LowDebug	Read Node Identifier byte, val is 32
LowDebug	Read Node Identifier byte, val is 0
LowDebug	Read Address 16 MSB byte, val is 255
LowDebug	Read Address 16 LSB byte, val is 254
LowDebug	Read Device Type byte, val is 1
LowDebug	Read Source Action byte, val is 3
LowDebug	Read Profile MSB byte, val is 193
LowDebug	Read Profile LSB byte, val is 5
LowDebug	Read MFG MSB byte, val is 16
LowDebug	Read MFG LSB byte, val is 30
LowDebug	Checksum byte is 255
LowDebug	Read Checksum byte, val is 255
Debug		Received ZNetNodeIdentificationResponse: 
		ApiId=95, Length=20, Checksum=FF, Error=False, 
		senderAddress=6827, senderSerial=0013A200406E92A6, 
		remoteAddress=92A6, remoteSerial=68270013A200406E, 
		deviceType=1, mfgId=4126, nodeIdentifier=, option=2, 
		parentAddress=FFFE, profileId=49413, sourceAction=3
Developer
Feb 29, 2012 at 9:45 PM

In the documentation, the second set of addresses are marked down as being 16bit then 64bit, but the raw output suggests that it's been read in the opposite order.

Coordinator
Mar 1, 2012 at 9:37 AM

Bingo! I didn't see it and it's so obvious! This was rewritten from Java project - just send the patch to them. Thanks!