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.

Sensor Does not Switch to Available Collector Network

Part Number: CC1350

Context

I have a sensor & collector network implemented using the Ti 15.4 stack. I am able to successfully connect between a sensor and a collector.

Problem

I have two collectors I am looking to be able to receive data from a sensor. The device is able to successfully connect to one collector, but fails to join to the other once the first is powered down.

I believe this behavior to be due to the network config from the first collector still being present on the sensor. I am able to change this if I press BTN2 to dissociate the device and restart it. I'm plan implement this failover at runtime, implementing somewhere around the "handleMaxDataFail" within the jdllc code.

I am looking to confirm that doing a dissociate at runtime on the sensor is the correct approach to accomplishing changing of a collector at runtime. Is there any implications that should be considered when doing this? Can the device still rejoin the first collector, should collector2 power off?

Related:

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/734152?RTOS-CC1350STK-How-many-MAX-devices-or-node-can-be-connected-to-single-collector-

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/p/768809/2856604

 

  • Hello CDev,

    I have assigned an expert to comment.

  • Hello CDev,

    This is a very common use case, and you are on the right track.

    You will need to call the disassociate API (the same one called when you press BTN-2) at runtime, and change the state of the sensor to start.

    This will force the sensor to do what you forced it to do when you restarted the device.

    You can have them both ON at the same time, keep in mind that the sensor will scan the channels in its channel list in ascending order and will join the first network/collector it finds.

    Regards,

    AB

  • Sharing for how I solved it:

    From slev1n's post here, I added logic to the ScanCnfCb:

    if (pData->scanType == ApiMac_scantype_orphan) {
                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)
                {
                    Jdllc_sendDisassociationRequest();
                    Util_setEvent(&Sensor_events, SENSOR_START_EVT);
                    sendAssocReq();
                    scan_fail_ctr = 0;
    
                }
    }

    This handles sending the dissociateRequest, resetting to start state (which will call Jdllc_join). The sendAssocReq is more of a hack than the intended result I think. The request will fail, entering into else block and resetting parentFound.

    Additionally, I modified the beaconNotifyIndCb in jdllc.c

                        if(checkBeaconOrder(pData->panDesc.superframeSpec) == true)
                        {
                              devInfoBlock.panID = pData->panDesc.coordPanId;
                              panIdMatch = true;
    //                        if(devInfoBlock.panID == JDLLC_INVALID_PAN)
    //                        {
    //                            /* Device can join any network , associate with
    //                             * first coordinator from which beacon is received */
    //                            devInfoBlock.panID = pData->panDesc.coordPanId;
    //                            panIdMatch = true;
    //                        }
    //                        /* Check the incoming PAN ID to see if it's a valid coordinator */
    //                        else if (devInfoBlock.panID == pData->panDesc.coordPanId)
    //                        {
    //                            panIdMatch = true;
    //                        }

    This solves the issue slev1n faced with his "test 4". In the case where the sensor sends the disassociateReq, but the collector is dead,

    the disassoCnfCb function will enter the else block, and not reset the PAN Id of devinfoBlock. When a second collector is introduced, the panId could not match due to this.

    A few things to note:

    This solution changes the state from scanOrphan to scanActive. This will change the how frequent the scans are from 

    CONFIG_ORPHAN_BACKOFF_INTERVAL from CONFIG_SCAN_BACKOFF_INTERVAL