Xbee forgets its NI (Node Identifier)

and a AT remote software reset brings it back.

I’m sending out ND (node Discovery) packets from the Coordinator and getting back 0x88 (AT Command Response) packets as expected. then sometimes one of the xbees that is replying will fail to send the NI, or more correctly sends a blank NI. This behavior moves from XBee to XBee.

Any ideas?

Also my NI’s are not unique across the mesh. I don’t see any requirement stating that the should be.

I’m using the latest firmware, they are configured as routers.

Do you control the PIC/micro attached to the XBee?

I know some devices try to manually form their ‘own’ XBee NI to some predefined value. Since a reset of the XBee brings back the original (XBee-flashed saved value), that would be my first guess … that the nodes are trying to manually set their own NI.

There are zero-requires for NI to be unique, and I have worked with many systems where every devices sets the same NI in the XBee (but most of those are API mode).

The XBees that have experienced this are all standalone, they are reading a analog input and sending 0x92 (IO Data Sample Rx Indicator) every few seconds. As well as the occasional x88 response. It is very intermittent. Also powering up/down the problem xbee brings back the NI. The remote software reset is my current workaround.

Ah, what firmware are you running? I can look through the release notes then.

version: ZigBee router AT 2270

2270 is actually quite old (from Nov 2009). There is a new release 2x8C ‘routing’ (aka: seeking diverse sign-offs). I sent you the ZIP via PM/Private Message. It is a ZIP 6.8MB big - nearly at the forum limit.

Looking through the internal release notes, I did find a comment which might relate to your issue:
“March, 2010 … where some end devices intermittently fail to report their I/O samples and to send NI …”

You are using a router, but still you are sending unsolicated IO samples, so this might not be related to router-vs-end-device.

thanks, news at 11
How come x-ctu “download new versons” does not pull these down.

Because approvals are “still routing”, so it cannot go into the support system until everyone signs off.

Given it requires literally hundreds of product BOM/bill-of-material to change (every gateway, every adapter, every ZB module shipped, every Zb dev kit), plus given the long supply chain (what to do with existing inventory?) there are a lot of people involved in approval.