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: Sensor/Collector example: Sensor has incorrect join behavior

Part Number: CC1310

Tool/software: TI-RTOS

Hey guys,

I am currently using the Sensor/Collector example software and added some code to use it for a PIR sensor. This basically works fine, but I have issues with the sensor rejoining old network and joining a new network when he was in another network before. In the sensor, POWER_MEAS is enabled!!!

I've installed the packet sniffer and wireshark to track current messages and find a solution.

I've been through a few tests and I use wireshark and putty. Putty is used to read out the collector messages via UART to see if it receives messages:

Test 0:

If the network is set up and works after restarting the collector with the restart button, it is not printing any messages to UART anymore though wireshark shows, that the sensor is proceeding to send data..

Test 1:

  1. The network is working and sensor sends data, which I can see in Wireshark and on the UART-Terminal
  2. I do then set the Collector to factory new but I do not remove it from the PC
  3. Wireshark shows that sensor sends data and ACK (though i dont know who send the ACK wireshark doesnt display an address or destination, I guess the collector)
  4. But no data is shown on the UART-Terminal

So, any idea what is happening? Who is sending the ACK, and if the collector is sending the ACK any idea why it is not displaying the value via UART?!

Test 2:

  1. The network is working and sensor sends data I can see in Wireshark and on the UART-Terminal
  2. Collector is removed from the PC (not set to factory new)
  3. Sensor gets into orphaned state and after 3 unsuccessful scans, it deletes NV, sends a disassociation Request and sets a SensorStartEvent.
  4. Collector is connected to the PC again and UART shows data from Sensor 0x02

So this test works perfectly.

Test 3:

  1. The network is working and sensor sends data I can see in Wireshark and on the UART-Terminal
  2. Sensor is removed from PC
  3. Collector set to factory new and removed from PC
  4. Sensor is connected to PC again -> shows orphaned state and after 3 unsuccessful scans, it deletes NV, sends a disassociation Request and sets a SensorStartEvent.
  5. Collector is connected with PC again
  6. Sensor is found again and sends data in Wireshark, the data can also be seen in the collector UART messages

So this test works well, too.

Test 4:

  1. The network is working and sensor sends data I can see in Wireshark and on the UART-Terminal
  2. Collector is set to factory new state and then removed from the PC (sensor is running all the time)
  3. Wireshark shows that every 5s a Beacon request is send to destination 0xffff immediately followed by "Beacon, Src:0xaabb" from 0xaabb but looks they are not pairing.
  4. When I remove the sensor, wireshark shows no further transmissions, so I guess the sensor was sending the beacons before, is that right?
  5. When I connect the sensor again, they pair and it works.

When I repeat Test 4 and I don't remove the sensor but press the sensors reset button it works, too. But using SysCtrlSystemReset() does not work, though I have to solve this issue automatically by software.

To sum it up, the sensor only connects to a new network if the sensor is flashed again with the software, the sensor is removed and connected to the PC again or manually reseted by the reset button...

I need to do solve this by software, any ideas? And regarding Test 1, any idea what is happening?

kind regards

Stefan

  • For Test 1 this is the expected behavior if you are doing a factory reset on the collector. Since the collector has no information about the devices sending the data then it will not display anything specially if you have security enable since the collector wont be able to decrypt the packets given that you need the extended address of the devices to be able to decrypt packets coming from them. Test 1 might work on the way you expect it to work if you disable security in your devices. Please note that this might generate other issues in the collector since it will not have a list of the devices in the network.

    For Test4, this test is a bit confusing, you mention that the sensor is currently in the network and then you factory reset the collector. then the sensor is sending beacons instead of orphan notifications which would happen only if the sensor was factory reset so this does not make much sense to me.
    There are 2 reasons that come to mind on why the sensor might not be joining, one would be that permit joining in the collector side is not enabled. The other one would be that you are triggering an active scan without resetting the MAC to the default values therefore the sensor is still looking for the old network from before the collector was reset to factory defaults therefore it will not join the new network and this is fixed after you do a reset on the device because the values in ram will be erased.
  • Thank you for your elaborate answer Hector and I forgot to mention, I always have "Permit Join" active.

    Regarding Test 1,

    I understand, that the connector should not print anything, but I have two questions here:

    1. Who sends the Ack? And if it is the connector, why is he acknowledging a message he cannot "use"?
    2. Why is the sensor not going into orphaned state if he is not in a network anymore? If I unplug connector from power, the sensor gets orphaned immediately.

    I rather keep the security on, but could you provide me with more details to the security option enabled? A link to a knowledgebase or whitepaper would be sufficient. I am wondering why Wireshark can decrypt the messages so easily.

    Regarding Test 2,

    I've already mentioned, that permit join is active and the reason I am testing this scenario is because it is likely, that the sensor accidentally connects to a collector, which is not the final one, before it reaches it final destination. Thus, I have to change the code enabling the sensor to rejoin to a new network. The following is a code snipped of what I am doing, if the sensor has 3 unsuccessful scans while being orphaned. I edited the function ScanCnfCb() in jdllc.c:

                    scan_fail_ctr = scan_fail_ctr + 1;
    
                    /* If too many scan failures occur, the non volatile memory is erased*/
                    if (scan_fail_ctr >= NUMBER_OF_MAX_SCAN_FAILS)
                    {
                        Ssf_clearAllNVItems();
                        Jdllc_sendDisassociationRequest();
                        Util_setEvent(&Sensor_events, SENSOR_START_EVT);
    
                        scan_fail_ctr = 0;
    
                        //SysCtrlSystemReset();
                    }

    First, I clear NV, than I send a disassociation request and after the I set a "Sensor_start_event". I've also tried a software reset using "SysCtrlSystemReset()" without luck, though.

    I am doing this, because I noticed the following:

    1. If I am in the state, that the sensor is sending data, but the collector is not printing anything like in Test 1 I have to press the left button on the sensor first and then the right button and they connect again. But I cannot perform the same measures, if I cannot detect the state, the sensor is in in Test 1.
    2. If I am sending beacons endlessly like in Test 4 pressing the left and/or the right button doesnt help. But pressing the reset button or plug off/on the USB cable does the trick.

    So my further questions are:

    • How can I detect the state of Test 1 and is "imitating" a left and right button press the most elegant way to get sensor and collector on track again?
    • Shall I detect the state of Test 4 in beaconNotifyIndCb()? And how can I perform pressing the reset button by software (SysCtrlSystemReset() seems not to do the trick or I am using it not correctly)?

    Hope I didnt forget anything and thank you for your help!

    kind regards

    Stefan

  • Hey,

    I am still not able to solve my two problems.

    1. If I am in the state, that the sensor is sending data, but the collector is not printing anything like in Test 1 I have to press the left button on the sensor first and then the right button and they connect again. But I cannot perform the same measures, if I cannot detect the state, the sensor is in in Test 1. Because I dont know where to put ApiMac_mlmeResetReq(true); since the sensor is sending all the time and receiving an ACK. I guess the sensor thinks everything is still fine. Thus I only have to find a way to detect this state...any idea?

    2. After 3 unsuccessful orphan scans I perform three steps

    1. Ssf_clearAllNVItems();
    2. ApiMac_mlmeResetReq(true);
    3. Util_setEvent(&Sensor_events, SENSOR_START_EVT);

    But after that, the sensor tries to connect to the collector I just set to factory new, by sending beacons all the time. In wireshark it looks like this:

    The only way to get out of this "endless" loop, is to push the reset button on the sensor or unplug and re-plug the device.

    Any suggestions are welcome, I am very stuck atm...

  • I got one step further.

    I added two steps, again at the case, when three orphan calls have been unsuccessful:

    1. Jdllc_sendDisassociationRequest(); <-- necessary, to put the variable "parentFound" = false; This is important for the beaconNotifyIndCb(); function
    2. Ssf_clearAllNVItems();
    3. ApiMac_mlmeResetReq(true);
    4. Util_setEvent(&Sensor_events, SENSOR_START_EVT);
    5. Util_setEvent(&Jdllc_events, JDLLC_ASSOCIATE_REQ_EVT); <-- I had to add a associate request.

    Now, it is not stucking in endlessly sending beacons, Wireshark shows this:

    After that, the sensor should start sending messages and it tries, but in the Sensor_sendMsg() function, I can see, that ret is set to true. So the message should be transmitted. Is there a reason, why the extended sensor address is 00:00:00:00:00:00:00:00??

        /* Send the message */
        if(ApiMac_mcpsDataReq(&dataReq) == ApiMac_status_success)
        {
            ret = true;
        }

    The pointer dataReq is filled like this. I compared it to when transmission works and the content looks the same. I dont know why the channel is "0" though it is set to "2" but it looks the same when it works. Can you see anything suspicious?

    Any idea, why I cant see the message in wireshark and collector is not receiving the message?

    It looks to me, that after deleting NV and PAN info and all the stuff, I have to set some plattform specific funtions again. But I dont know which...

  • Ok, I solved the issue of Test 4:
    If the sensor has joined a network and this network disappears, either by setting the collector back to factory new and unpower it until the sensor has disassociated from the old network or just by bringing a new collector and removing the old you have to do the following to join the new network:
    - Jdllc_sendDisassociationRequest();
    - Util_setEvent(&Sensor_events, SENSOR_START_EVT);
    - sendAssocReq();

    Clearing non-volatile memory (NV) or ApiMac_mlmeResetReq(true); are causing issues.

    For identification of Test 1 I will do some thinking and make a new post, this one gets too messy :) Thanks for the support.