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.

CC1310: Collector : assigning an already allocated short address

Part Number: CC1310

Support,

Using the CC1310, the collector sometimes assigns an allocated short address to a joining sensor. This results in two sensors with the same short address. At that point only one of the sensors communicates with the collector.  Is there are any such reports or if there’s something we may be doing wrong to cause this?

 Regards,

Marc

  • Which SDK version do you use?

  • There have been some changes to the address assignments in previous versions of the SDK . So in order to address this we need to know what version is this problem happening on.
  • I also noticed, that when I press the "disassociate" Button on the sensor-launchpad, than the address will be incremented. If you reach 0x33 (if you set the device limit to 50) all sensors who join afterwards will be addressed with 0x33. I guess it would be better if the collector checks if a smaller short address is "not assigned" e.g. because another sensor with a smaller short address has left the network.
    I am using SDK 2.10.0.36

    If this has been changed in the new SDK, can I exchange a small code snipped or do I really have to change the SDK for that feature?

  • Hi,

    This has been fixed in SDK v2.4 Please update to the latest SDK.

    If you don't want to update to the latest SDK you should replace the function "maintainAssocTable" in the SDK you are using with the one from SDK v2.4
  • I replaced this function in my code and so far couldnt notice the collector assigning the same short address twice. However, I wonder why it is always incrementing short address. One example, I have a sensor launchpad with short address 0x02 I do then press Button 1 to disassociate it from the network. The sensor afterwards immediately rejoins but is assigned 0x03. Since 0x02 is not used anymore, why is the collector not assigning this short address again? Will the collector start assigning these unused addresses first after the maximum number of allowed devices (50th device = 0x33) is reached?

    And another question, do you already know when the next SDK will be released? I am thinking if it makes sense to get to the current one or wait for the next.

  • It assigns a new address because after disassociating the sensor, the collector deletes all the information about that specific device therefore it cant re use the previous address. Also, now the way it works is that the collector wont stop assigning addresses after reaching 50, it will keep going up to  around 65000. 

    Also, Probably you should wait for the next release which should be out by the end of this month. 

  • Thank you for the fast response.

    I understand that the collector deletes all information of the disassociating device, however I thought it would assign this "freed" address again. But it doesnt matter if the collector counts beyond the device limit.

    And I will wait for the release.

    kind regards
    Slev1n