LP-EM-CC1314R10: orphan Sensor rejoin issue - orphan scan not triggered.

Hi Muniyappan,

once the sensor is in orphan state it starts a backoff timer which means it will continuously wait longer before sending the next orphan scan the longer it was disconnected. You can modify the backoff exponent in SysConfig.

1. Are the two logs that you send with different disconnection times?
2. What are your requirements for the rejoining after a sensor is orphaned?

Kind regards,
Theo

1. Are the two logs that you send with different disconnection times?

Disconnection time means backoff timer?. 

Two logs are taken from same setup.

Following are the operations we did,

1. Flash the sensor code to one board and collector code to another board. Attached the screenshots for your reference.

2. Created the PAN network and associated the sensor in the PAN network. Collector and sensor is connected and working as expected.

3. Now we are turning off the collector (Removed the power supply) and observe the sensor operations.

4. Once the sensor is orphaned we will again turn on the collector and see how much time the sensor is taking to rejoin with the collector.

We are repeating the step 3 and 4 multiple times for testing. So there we could able to see 2 scenarios once the collector is turned off,

a. Sensor is periodically sending the orphan notification every 4 seconds (Working flow  - log).

b. Sensor is sending the orphan notification every 7 mins (Issue flow -log ) - occurring very rare.

We assume that whenever collector is turned off, the sensor will send the orphan notification at a same time interval (depending on the backoff exponent). Is our understanding is correct?.

2. What are your requirements for the rejoining after a sensor is orphaned?

Currently we aimed to achieve sensor rejoin to the network with in 3 mins. But It may vary depends on the current consumption of the sensor (because in our setup the sensor will be powered by the batteries and  orphan scan may require more power). We focused more on understanding this orphan mechanism and implement the ideal orphan scan interval based on the power consumption.

Note:

**In entire testing we never power resettled the sensor.

**We have configured about the backoff exponent as follows,

Hope to hear from you. Thanks for your continuous support.

Best Regards,

Muniyappan R.M

Hi Muniyappan,

I tested the configuration that you posted and I could not reproduce a different interval of sent orphan notifications. When I look at the packet sniffer log I can see that the orphan messages are sent always with the same interval according to the configuration of the orphan timer.

Could you perform a full flash erase and then reprogram the chip to ensure there is nothing left from old configurations.


Note that if there is issues with rejoining the collector this is most likely due to the reopening of the network on the collector side. When you powercycle the collector you need to additionally reset the collector and press button 1 again to restart the network properly. This is because of the example application and for the final product you can then of course adjust the software so that no button presses are required and for every startup the network is restarted.


Please let me know if any errors persist.

Kind regards,
Theo

Hi Theo,


As per your suggestion, we enabled the AUTO_START function on both the collector and sensor to restart the network properly. Also we performed the full flash erase after flashing the code.

testing the same again i.e started the nw, joined the sensor and powered down the collector ,

After I power down the collector board I am observing two scenarios,

Scenario 1  (Working flow):

Sensor board sending the orphan notification every 4 seconds. And if I power the collector now , the sensor rejoined the network.

Scenario 2 (Issue flow - occurring very rare):

Sensor board sends the first orphan notification after 420000 ms  (approx. 7 mins) and then it is sending the orphan notification periodically every 4 seconds. (I  ran the sensor boards for about 8 hours in the orphan state). So only the first time, the sensor is taking 7 minutes to send the orphan interval.

The scenario 2 is occurring very rare but the time is exactly around 7 mins. We have no packet sniffer, so we are unable to sniff the packets.

But whenever this issue happens, sendScanReq(ApiMac_scantype_orphan) ->  ApiMac_mlmeScanReq(&scanReq); is triggered and the conf callback is only triggered after 7 mins.

Can you help us to understand how the cnf callback and ApiMac_mlmeScanReq() is working?


Regards,
Muniyappan R.M

Hi Muniyappan,

this sounds very strange and we have never heard of such a case.

I'll start by explaining the link controllers behavior. Once the device does not receive any response to it's data requests for the defined maximum of allowed data failures it will switch the state to orphaned. This state change will trigger an orphan scan using, as you linked, ApiMac_mlmeScanReq(&scanReq); with scanReq = orphan scan. The orphan callback will check if a response was received and change the interval of the orphan scan as defined in SysConfig with the backoff interval.

I tried to reproduce what you are reporting and I observed the network traffic with a packet sniffer. As you can see in the picture below the first orphan scan is triggered after the maximum number of allowed data failures is reached and then performed according to the defined interval.

I never got to a point where the initial orphan scan takes any delay after the maximum number of data failures is reached.

My questions are:
- How do you generate your logs and observe the network traffic since you are not using a sniffer?
- I can see that for this configuration the time from the last data request (58.2 s) to the fist orphan scan (65.8 s) is around 7 s due to the resending of the data request until the maximum number of allowed data failures is reached. Is this what you are referring to? You can change the number of allowed data failures by changing the define CONFIG_MAX_DATA_FAILURES and the maximum number of retries by changing the define CONFIG_MAX_RETRIES. By default both are configured to 5 and with the initial request this is 6x6=36 requests until the orphan scan starts (as you can see in the wireshark recording above).

Kind regards,
Theo

Hi Theo,

Thanks for you effort.

Regarding your question,
How do you generate your logs and observe the network traffic since you are not using a sniffer?
>> Since I don't have the sniffer setup, I am using the debug prints to debug (using separate debug UART). The logs I posted also generated by adding the debug prints.
- I can see that for this configuration the time from the last data request (58.2 s) to the fist orphan scan (65.8 s) is around 7 s
>> In my case it is taking around 420000 milli seconds. CONFIG_MAX_DATA_FAILURES and CONFIG_MAX_RETRIES are set to 5 in my firmware as well.

May be I will debug more on this.

Can you clear me the following doubt alone,

You have mentioned about the orphan scan,
 ApiMac_mlmeScanReq(&scanReq); with scanReq = orphan scan. The orphan callback will check if a response was received and change the interval of the orphan scan as defined in SysConfig with the backoff interval.

In my case after, whenever this issue is occurred, the scanCnfCb() is triggering after 7 mins of  ApiMac_mlmeScanReq().

Is that the expected flow? (Because in working flow the scanCnfCb() callback will be triggered immediately once the scan is requested). We thought the sensor might not sent the orphan scan for 7 mins (is it locked in some state?),  but we cannot conclude anything as we don't have the sniffer setup to confirm.

Best Regards,
Muniyappan R.M 

Hi Muniyappan,

I was running tests now to the side over the last 8 hours and I could not reproduce this.

The scan will take longer the more channels are used but since I assume that you use only one channel it should transition to sending orphaned messages once it finished the resending. What you can see in the log in my last post is the expected behavior when transitioning to orphan mode.

I assume that since you call UART prints in the link controller this might slow down a state transition in some rare corner cases. Did you initialize the UART as non-blocking?

In general we recommend to not use any blocking tasks from the link controller.

Kind regards,
Theo

Hi Theo,

Thanks for the  quick response. Regarding your questions,

I assume that since you call UART prints in the link controller this might slow down a state transition in some rare corner cases. Did you initialize the UART as non-blocking?

>> Yes, I have enabled the UART in the non-blocking mode.

In general we recommend to not use any blocking tasks from the link controller.
>> Understood. We will change the UART mode.

I have requested my team to buy an additional launchpad (CC1352P) to arrange the sniffer setup. Once I have  the sniffer setup, I will remove the Debug prints  (remove the UART config as well) and then test this same scenario .

Regards,

Muniyappan R.M