SIMPLELINK-CC13X0-SDK: TI 15.4 collector/sensor example rejoin issue

Hans Christian Glittenberg

Hi,

I have flashed devices according to project 0. They connect and it's working. I use packet sniffer and wireshark to monitor the packets.

Then I do a factory reset on the sensor. Then I activate permit join on collector. I can see in wireshark that the association process is taking place just after I activate permit join on the collector. I also notice through wireshark that the long addresses are exchanged so that the same physical sensor is recognized as the original device that originally was associated with the collector the first time - great! Then the sensor data (the very long payload) is transmitting regularly (seen from wireshark). I can even toggle the LED sensor through the collector. However: The collector UART output is stating "!Responding: 0x1" for a very long time (10 minutes etc), and then suddenly the sensor data is output on the UART eventually. It seems that there is something wrong here... The collector is evidently receiving the sensor data, but the "top layer" code does not seem to know this.

Let me know if you can reproduce this. Thanks.

over 5 years ago

0 Hector_r over 5 years ago

TI__Genius 12415 points

Hi,

"!Responding: 0x1" is shown in the collector side when a device is not responding. The reason why you see this message after you join the device back to the network is because the device did a new association to the network instead of re-joining the network since you performed a factory reset on the sensor.
On the collector side when a device re-associates with the network, the device is treated as a brand new device and it gets a new short address assigned to it therefore creating a new entry in the associated devices list.
The collector uses the short address to track whether a device is active or not in the network which is the reason why the message "!Responding: 0x1" is displayed meaning that the device with short address 0x1 is no longer responding.

0 Hans Christian Glittenberg over 5 years ago in reply to Hector_r

Expert 2235 points

Hi Hector,

Thanks for your quick reply. I understand your answer, but I think there is something else going on. Let me explain...

You are correct that there is a new association going on, and that it gets accepted (verified since the sensor transmits data and states that it joined the network - both according to wireshark and sensor terminal output).

However, the collector terminal output does not state that a new sensor device has joined the network (e.g sensor 0x2). There is no periodic sensor data on the collector terminal. This should have been the case according to your answer, I would assume(?)

Interestingly, the wireshark sniff packet of the "second" association provides a link-reference to the line number of the first initial association sniff packet. The MAC address is shown here - 8 bytes. It's as though wireshark understands that it is the same physical device that tries to associate "once again".

After a long time the collector suddenly starts to output the sensor data on its terminal - and the sensor is sensor 0x1. The "!Responding: 0x1" stops at the same moment.

It seems to me that that the low layer ti 15.4 stack actually recognizes that it is the same physical sensor that attempts to make a new association (due to the unique 8 byte MAC address). And this is a very good feature! But the "top layer" code does not take this scenario into account. I guess that there is a packet exchange sometime afterwards where the MAC address is sent from the sensor which also makes the "top layer" code aware of the sensor presence, which is why the collector suddenly starts outputting the sensor data on its terminal output - though this is only speculative.

0 Hector_r over 5 years ago in reply to Hans Christian Glittenberg

TI__Genius 12415 points

Hi,

Disregard my previous post, it is incorrect, I just double checked and the collector does check if the sensor device associating the network was already part of the network. In this case your issue is happening because the collector is not sending the configuration message which normally gets triggered in the application by calling pCllcCallbacksCopy->pDeviceJoiningCb but when a device was already previously in the network the collector does not call pCllcCallbacksCopy->pDeviceJoiningCb.

The configuration message sets up the polling interval and the reporting interval on the sensor and since the sensor was factory reseted and it didn't receive the configuration message then it will use the default value for the reporting interval which is 3 minutes. Because of this the Collector assumes that the sensor is not responding since it is expecting the sensor to send data every 90 seconds or whatever value is set in CONFIG_REPORTING_INTERVAL in the collectors config file which is used in the configuration message.

This looks like a bug, I will submit a ticket for this to get fixed.

In the mean time you should be able to get around this by adding the following code in the else statement in line 1174 in the function "assocIndCb" , Add the code that is in between the comments //START ADD CODE and //END ADD CODE

static void assocIndCb(ApiMac_mlmeAssociateInd_t *pData)
{

...


    else
    {
        /* Device already exists use the old short address */
        assocRsp.status = ApiMac_assocStatus_success; 
        //START ADD CODE
        if(pCllcCallbacksCopy && pCllcCallbacksCopy->pDeviceJoiningCb)  
        {
            /* callback for device joining */
            assocRsp.status = pCllcCallbacksCopy->pDeviceJoiningCb(&devInfo, &pData->capabilityInformation);
        }
        //END ADD CODE
    }

...

}

0 Hans Christian Glittenberg over 5 years ago in reply to Hector_r

Expert 2235 points

Thanks, Hector, for the very detailed explanation and fix. It works. For the next release, could it be an idea to add an "elaborate" define to add a lot of debug info to the terminal? As an example I added "addDeviceListItem: Device already existed" in func addDeviceListItem. This would help the developer to more quickly understand the flow and how it all works. Just an idea... :-)

Sub-1 GHz

Sub-1 GHz forum

SIMPLELINK-CC13X0-SDK: TI 15.4 collector/sensor example rejoin issue