Home/Support/Support Forum/Xbee end node constantly transmitting random Receive Packet Frames - Frametype 0x90?

Xbee end node constantly transmitting random Receive Packet Frames - Frametype 0x90?

0 votes
I’m having a few problems with an Xbee end node. I have a network of 35 Xbee sensors including 7 repeaters. I’ve given each sensor the following settings:

FW Version: 29A7
API Mode = 1
SM – 4 (Cyclic sleep)
SP – 7D0 (Sleep for 20 seconds)
SN – 1E ( 30 sleep cycles)
SO – 6 (Extended sleep)
IR – 800 ( Send a sample every 2 Seconds)
ST – 7D0 (Sleep timer = 20 seconds)


All the nodes are working perfectly except one. Its constantly sending a unicast data transmission to the coordinator which is putting out a lot of random Zigbee Receive Packets – Frame Type 0x90. Why would it just randomly do this? Its spitting out this data pretty much every second but with varying RF data. Also I have no communications back to it and can’t send a reset command or any AT command.

Sample frame:

900013a2004089bf9cf45e41f0fff87fdff8fffcfffffefefefefefc3b6244fefffff8fcfefefefeffff70e5fffff8fffffcfffcfffcfffcffffe8e6f
e95fffff0fffffcfffcfffcfffcffdf2600125afefffff0fffff8fffcfffff8fffff87f

Any suggestions or solutions will be greatly appreciated.

Thanks
asked Apr 30, 2013 in IEEE 802.15.4 by quati10 New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
Can you provide us with the actual frame it is providing?
answered May 1, 2013 by mvut Veteran of the Digi Community (15,108 points)
Hi,

This is the sample frame. When I store the string I strip the start delimiter, length and checksum from the API packet.

Here are some more sample frames all from the same end node with 64bit address - 0013a2004089bf9c.

900013a2004089bf9cf45e41fe
900013a2004089bf9cf45e41bd7f3b0c20fcfae493f5ffffffff

The RF data starts after the receive options - 41.

Do you have any idea why the coordinator is receiving this API packet as my end nodes are only setup to sleep for 10minutes, wake up and force a sample and go back to sleep after 2 seconds. Could it be a faulty end node?
...