• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 57 subscribers
  • Views 959 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Duplicate Short Address Issue

"Henry"
Intellectual 675 points
Other Parts Discussed in Thread: CC2431, CC2430, Z-STACK

Dear friends,

I'm using TI's CC2430 and CC2431 to build a locating system. I met the duplicate short address issue in setup. The story is:

As we know, a router will get new short address from the parent node such as a router or coordinator when it is joining the network. The parent node should 'remember' which address had been assigned normally. My problem is when the coordinator has been replaced, the new coordinator DO NOT know which address has been assigned by the old one, so it will dispatch exisited short address to new join router nodes. So, same short address may existed in one network although the IEEE addresses are totally different.

The result is when send data to duplicate short address router, both of them will receive the data and do the same response. The worse news is duplicate short address routers will assign more duplicated short address to new join nodes since they have same address space. It's really a mess!!

In addition, how to change the short address in the run time? Can send command to these nodes o ask them rejoin network through coordinator SPI interface?

Have you met the same issue? How to solve it? Please advise, thanks in advance.

Henry

  • 0
    Intellectual 675 points

    I think if disable NV_RESTORE may 'solve' the issue, but it is not the right way since we need to use NV memory to save other configuration data such as reference node's XY value.

  • 0 in reply to "Henry"
    Prodigy 190 points

    Unfortunately, the Zigbee spec doesn't mention how to handle an occurrence where the coordinator fails. That remains one of the critical weak links in the network since a failover mechanism would be proprietary. Basically, the addresses that the coordinator hands out is based on the CSKIP algorithm if they're using tree addressing, or stochastic addressing if they are using that mode. In any case, the addresses are stored in the coordinator's neighbor table as well as the relationship (ie: child) so any change in coordinator would probably require backing up the neighbor table as well. I believe this may be possible via the ZDO of the Z-Stack although I'm not sure.

  • 0 in reply to FreakLabs
    Intellectual 675 points

    I found any duplicate address routers in the same channel and PANID is very dangerous to a network, because it will distribute more pertencial duplicate addresses to new joined nodes. Please be careful.

    My current solution is when replace existed router, make sure the new node has NOT been assigned same short address with existed routers in network.

    The better method is set PANID other than production PANID when testing.

  • 0 in reply to "Henry"
    Prodigy 50 points

    Hi Henry,

    I had the same problem where two reference nodes have the same short address.

    I tried to re-program one of the reference node with dongle code and let it run and then I programmed back to the reference node. Turning the reference node on, the short address was now different.

    Looking at the date, you might have already solved the issue or no longer interested in the solution but I posted it to let others know. : ) Hope this helps.

     

    Isaac

  • 0 in reply to Isaac Sung Jae Chang
    Prodigy 50 points

    I tried one more time and it works when the "older" one between the two references with same short address is re-programmed with reference code using flash programmer on the evaluation board. This process somehow invokes the dongle to re-assign the short addresses. All the other reference nodes have the same short address still but the one that has been just programmed has different short address. I know this is a hand-waving solution and hope it works for others too. :p

    Isaac

  • 0 in reply to Isaac Sung Jae Chang
    TI__Expert 4155 points

    It is also crucial to ensure unique 64-bit MAC addresses are assigned to each node. It is easy to forget this sometimes because you may forget to either program it using SRF flash programmer, or forget to check the "preserve IEEE address" option.
    Each device should have NV restore turned on in order to remember the short addresses that have been re-assigned. Otherwise, if the node resets for whatever reason, you lose the short addresses that have been previously assigned, and now there is a potential to assign duplicate short addresses to new nodes that join.