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: Disassociation and old network information in NV memory

Part Number: CC1310

Tool/software: TI-RTOS

Hey guys,

to allow sensors to join another network if their collector is exchanged, I've implemented some kind of „auto disassociation“ in the jdllc.c file. Btw. I am using TI 15.4 Stack and my application is based on the sensor/collector zero project.

If the collector of the network disappears, the sensors will go into the orphan state. After 2 unsuccessful orphan scans, 3 functions will be called:

  1. Jdllc_sendDisassociationRequest();
  2. Util_setEvent(&Sensor_events, SENSOR_START_EVT);
  3. sendAssocReq();

This actually works quite well in most of the cases although I sometimes see strange behaviour.

  • Sensors, which disassociated from an old network send a beacon request, which is followed by a beacon from the new collector, though no association is following. The sensor will send the beacon request not reacting on the beacon again and again indefinitely long… Only solution here is to flash the sensor again
  • Sometimes the sensors join the new collector keeping their old short address, which was assigned to them by the old collector. By "keeping" I mean the new collector assignes the old short address although another one would be right.

  1. So I would like to know, if all the former information regarding the old network is deleted from the sensor (including its own old short address) if I call „jdllc_sendDisassociationRequest();“?
  2. If I don’t call „sendAssocReq()“ the sensor will continuously send „orphan notifications“. Why is that?
  3. Is there a better/more elegant way to proceed regarding the auot disassociation, to have more reliable and stable rejoin behavior?
  4. If a sensor disconnects and joins his old network again, he receives a new short address. How can I prevent that from happening? (because it fills up the list of devices in the network)

Kind regards

Slev1n

  • when the sensor receives a beacon you should set a breakpoint in beaconNotifyIndCb and check the value of of "devInfoBlock.panID" the right value should be "CONFIG_PAN_ID"
  • The problem is, that I can not reproduce the error regarding the ignored beacon from the collector. However, if I will find a way to reproduce it I will debug this function elaborately.

    What could you suggest considering this question:
    If a sensor disconnects and joins his old network again, he sometimes receives a new short address. (again happening only sometimes and still dont know how to reproduce the error) How can I prevent that from happening? (because it fills up the list of devices in the network)
  • Hi Slev1n,

    Are you still having problems with this issue?. I feel like we might have already addressed this in one of your other posts
  • You are right, sometimes the issues I am facing relate closely to each other. I am currently not able to make long term tests. I think it could relate to the fact, that if the sensor disassociates when its collector is gone, that the "parentFound" variable is not set to false, which can lead to a problem when trying to reconnect to a new collector.

    However, I did not have time to work on this problem, since currently I need to get rid of the "sensor doesnt rejoin after being flashed" issue. It's like a hydra with a head of rejoin issues, cutting of one and three new appear :)

    Anyway, the questions within this thread have been answered so far and I can only work on the remaining issues if I am able to reproduce the error, anything else is pure speculation.