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.

RTOS/CC1310: Collector assigning the same short address to different sensors

Part Number: CC1310

Tool/software: TI-RTOS

Hey guys,

I am using the sensor collector example in the SLM ETSI mode with non-beacon mode enabled.

In my last setup, I had 15 different sensor nodes connecting with the collector. They had been connected to the collector before, hence the collector knew them. However, I noticed using a sniffer and wireshark, that the collector eventually assigned the same short addresses to different sensor nodes.

And here my code snipped of assocInd(); where I made a change:

        if(assocRsp.status == ApiMac_assocStatus_success)
        {
            /* add to association table */
            maintainAssocTable(&devInfo, &pData->capabilityInformation, 1, 0,
                               (false));
#ifdef POWER_MEAS
            if(POWER_TEST_PROFILE == POLL_DATA)
            {
                generateIndirectRampMsg();
            }
#endif
        }
    }
    else
    {
        /* Device already exists use the old short address */
        assocRsp.status = ApiMac_assocStatus_success;
        /* callback for device joining */
//_____________MY CHANGE START_________________
#ifdef STATUS_MSG
            System_printf("Status: device already exists\r\n");
#endif

         if(pCllcCallbacksCopy && pCllcCallbacksCopy->pDeviceJoiningCb)
         {
               maintainAssocTable(&devInfo, &pData->capabilityInformation, 1, 0, true);
               /* callback for device joining */
               assocRsp.status = pCllcCallbacksCopy->pDeviceJoiningCb(&devInfo, &pData->capabilityInformation);
         }
//_____________MY CHANGE END_________________
    }

I cannot trigger this behavior, however I am not sure what implications this situation can cause somewhere during runtime.

Any idea why the collector is doing this?

Kind regards

Slev1n

  • Hi,

    I have requested our protocol folks to look into this.

    regards,

  • Thank you, I am looking forward to an answer.

  • slev1n,

    Do you restart the network at any time?

    CAn you walk me step by step on what is going on?

    Regards,

    AB

  • I will do my best to recapitulate as closely as possible. Note, that the collector always allows joining.

    1. At the beginning we flash the collector and the ca. 30 sensors and test in our office if they connect and work properly for a few days. Quite rarely it could happen that one sensor disconnects since its messages havent been acknowledged two times in a row or a data request from the sensor has not been acknowledged once. After disconnection the sensor immediately starts to send beacon requests and hence is usually accepted to the network again receiving its old short address. At the point of disassociation, initiated by the sensor, two scenarios are possible. First, the collector notices the disassociation request from the sensor. Second, the collector does not take notice, e.g. because the collector was powered down for some time during which some sensors might have been trying to send data. Sometimes the software of the sensors is updated, though the collector software is not. In this case the sensors connect again to the collector immediately.

    2. We bring 15 (not all sensors) sensors to our field application with a collector. During travelling time, the sensors disconnect again because the collector is offline for a few hours until we reach the place for our field test. The sensors are all powered by batteries. Since many obstacles and a quite high distance from sensor to collector are normal in our application not all messages reach the collector and even during the association process there is a chance, that one of the messages is not acknowledged and the process of association is started again. After some time all sensors are connected, however, now some sensors do have the same short address. Since in my application, we distinguish the data send by the MAC address, so this is not too big an issue, but I am not sure what consequences could ocur. If a data message does not reach the collector the data will be send again the next time together with the new data set, so harsh connectivity environments are not that big an issue, too.

  • I just experienced the same behavior again. I have 28 sensors in non beacon mode. Sending beacon requests each 5s (pretty busy setup, only for test purpose not for application). then the collector is flashed and a sniffer is running parallely. It is a very busy setup, provoking messages which are not acknowledged by the collector causing a disconnect and rejoin of the sensors. Here a snipped of the associations performed by the collector. Again, sometimes the one short address is assigned to different sensors.

    So far any idea how to solve this? Because I have no idea what influences this has on polling. Besides we also plan to switch from non beacon to FH for application in the US and I heard that for sleepy devices short addresses are the address format of choice :)

    Any help appreciated.

  • Hello,

    Can you verify that during your AssocIndCB function you are hitting the maintainAssocTable fuction?

    This is the only place I see that it could potentially fail.

    Regards,