nRF9160 - CFUN=0 - order of operations?

I searched the forum and found quite a lot of hits for CFUN, where CFUN=0 is faced delays.

My understanding of the other tickets is, that the EPS-detach sometimes takes longer, in my cases up to more than 60s.

CFUN=0 also saves the configuration to the NVM.

With the large times, what is executed first? The EPS-detach or the save to NVM? Or is the order independent?

(Just to mention: in my experience, some network provider seems to not answer to the EPS-detach while others do. That makes  EPS-detach with a that long timeout somehow a wast of energy.) 

Parents
  • Hello,

    I have asked the modem team. They should know this.

  • Any update?

    Let me add:

    I know the ommon explanation for the longer times to at+cfun=0 , but I feel strange about that.

    If my modem is in sleeping mode and wakes up to send data, that works very frequently fast (from LTE-M 0.5 - NB-IoT up to 5s), but switching off takes in difference very often a lot longer.

    From other "close/shutdown" definitions, one of the most common failure in the implementation is to try to implement "weak close" in a reliable way. e.g. if the implementation must anyway handle cases, where the "close" didn't work, the specification commonly uses a "weak close". That works usually by a simple close request and the other respond and closes. The respond may get lost, but a retry of the close request will not work, because the other has already closed. Not sure, if that is the root-cause. At least spending that long time in switching off seems to indicate, that there are issues.

Reply
  • Any update?

    Let me add:

    I know the ommon explanation for the longer times to at+cfun=0 , but I feel strange about that.

    If my modem is in sleeping mode and wakes up to send data, that works very frequently fast (from LTE-M 0.5 - NB-IoT up to 5s), but switching off takes in difference very often a lot longer.

    From other "close/shutdown" definitions, one of the most common failure in the implementation is to try to implement "weak close" in a reliable way. e.g. if the implementation must anyway handle cases, where the "close" didn't work, the specification commonly uses a "weak close". That works usually by a simple close request and the other respond and closes. The respond may get lost, but a retry of the close request will not work, because the other has already closed. Not sure, if that is the root-cause. At least spending that long time in switching off seems to indicate, that there are issues.

Children
Related