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.

CC1310: About the power consume when enter orphan state.

Part Number: CC1310

Hi TI friends:

    We have found that when sensor went to orphan scan state,it will not sleep after enter the second orphan scan.

   Glad to see SDK simplelink_cc13x0_sdk_2_20_00_38 has solved this bug.

   But after we upgrade our sensor to simplelink_cc13x0_sdk_2_20_00_38,one time of orphan scan need 5-6 seconds of non-sleep time and the current during this time is 5-6mA,which made the power consume not so good.(we set orphan scan interval to 1 minute,so the average current is about 500uA).

   I see from code in jdllc.c

void Jdllc_process(void)

{

.....

/* Process scan backoff in case of orphan scan */
if(Jdllc_events & JDLLC_SCAN_BACKOFF)
{
switchState(devInfoBlock.prevDevState);
if(devInfoBlock.prevDevState == Jdllc_deviceStates_scanOrphan) {
ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, true);
}   //TI added in SDK2.20
/* Clear the event */
Util_clearEvent(&Jdllc_events, JDLLC_SCAN_BACKOFF);
}

....

}

my question:

1.what change do you made to solve the orphan scan ?

2.why you add this processing in jdllc.c?

3.Is there way we can do to decrease the current when in orphan scan mode without increase the  orphan scan time interval?

  • Hi Yang,

    Point two is related to point 1, where the changes in jdllc.c is part of solving the orphan scan problem.

    Why this increase the active time with 5 seconds in your case I can not answer, could you recreate this with the default sensor and collector examples and let me know what changes you did so that I can try to reproduce what you are seeing?
  • Hi M-W:
    We didn't change orphan scan processing code,it is the same as TI origin.
    I think you can recreate this issue with your own launchpad.

    Thanks
  • Hi Yang,

    If so, I will have a look at it and see if I can dig something out. I'll let you know when I've gotten around to it!
  • Hi M-W:
    thanks for your help.
    Hoping for your response soon.

    Thanks & BR
  • Hi Yang,

    I tried this out with the default examples, lowering the orphan scan interval to only 20 seconds (just to make it easier to measure) and every time the device went from standby to active for an orphan scan, the active period lasted around 4 seconds which would be 1s / channel which I expect.

    The scan (on each channel) should run for a maximum time is configured by "ApiMac_attribute_responseWaitTime".
  • Hi M-W:

      Thanks for your reply.

       So you mean the default ApiMac_attribute_responseWaitTime is 1s per channel ?

       This seems to be too long as we have configed 5 channels and the orphan scan duration is 1minute.

       Do you have any recommended value for ApiMac_attribute_responseWaitTime ?

       We have modified CONFIG_SCAN_DURATION from TI origin 5 to 3,which made the active scan per channel change from 800ms to 200ms.

  • Hi,

    My understanding of ApiMac_attribute_responseWaitTime is that the resulting time depends on the why and symbol rate (among other things). Running the default 50 kbps PHY 1, the default value would result in ~1s.

    I'm afraid I don't have any recommendation on this value, It should at the very least be long enough to cover the realignment command sent from the collector (as this has to be received within this time window). I would suggest you try this out and see what values work for you.
  • Hi M-W:

      How to caculate ApiMac_attribute_responseWaitTime value?

      for which value corresponding to 1s and which value corresponding to 200ms?

      There seems to be no setting of this value in TI org exmaple.

       

      As we have used 5 channel in our application and the orphan scan duration is 1minute.

      The average current is 500uA high which is really too high.

      We need to find a sollution.

    thanks & BR

  • Hi M-W:
    I have tried to modify ApiMac_attribute_responseWaitTime to 16 and 8 in jdllc_init().

    ApiMac_mlmeSetReqUint8(ApiMac_attribute_responseWaitTime,8);


    But the orphan scan time seems to be still 5-6 seconds.

    In 802.15.4 protocol:

    macResponseWaitTime    Integer 2–64   default 32

    I see no setting of ApiMac_attribute_responseWaitTime in TI org code,so it should be 32 by default.

    But why setting it with smaller number doesn't work?

    BR

  • Hi Yang,

    The value itself is not a hard time, but is the multiples of aBaseSuperframeDuration the device should wait for the responds. aBaseSuperframeDuration is the number of symbols forming a super frame (which in this case is 960 but I recommend you double check this in the IEEE specifications). 

    In the sensor example, ApiMac_attribute_responseWaitTime would be set to 48 per default, 48 * 960 = 46080 symbols which means that at 50 kbps (PHY 1), the timeout would be ~1s. You should be able to use this to calculate what number corresponds to a time ~200ms.

  • Hi M-W:

      I have tried with 16 and 8 to set ApiMac_attribute_responseWaitTime ,but the orphan scan time is still 5-6 seconds.

      Can you tell me the reason?

    Thanks & BR

  • Hi Yang,

    I do not know why it does not work in your case. I made the changes inside the sendScanReq function inside the jllc.c file when I tested this out. Can you try to do the same?

    Could you also try to write and then read back the value to see that it actually was set?

    And as a last resort, could you try to lower the number of channels to 1 single channel just to see if it makes a difference?

  • Hi M-W:

      Thanks for your help.

      add setting this pib processing in sendScanReq  works.

      Now the orphan scan time has decreased to 1.2s as I tested.

      And also if I lower the number of channels to 1 this time is about 0.3s.

      It seems to be a very important PIB which affact data transfer .

      Although I haven't found bugs yet,I still want to know  whether  there is side effect of changing this PIB ApiMac_attribute_responseWaitTime?

    Thanks & BR

       

  • Hi Yang,

    I really can't say anything about possible side effects as I'm not that familiar with the complete IEEE spec or the stack itself. I will try to ask around but my suspicion is that you should follow any recommendations that is in the IEEE spec related to this number. My initial guess is that if the respondsWaitTime becomes to short, devices will have problem re-aligning in certain situations were the collector for some reason is delayed in the responds.
  • Hi M-W:
    Please help to get more infomation from TI internal.
    Thank you :)

    Best Regards
  • Hi Yang,

    I have checked around and the simple answer is that it depends and that you would have to test it out for your application.