Delay when switching off PHS8 | Telit Cinterion IoT Developer Community
April 8, 2019 - 8:51am, 2504 views
Hi everyone,
In my application I have to save power and the PHS8 has only to run as long as the internet connection is needed. When switching off the module with AT^SMSO, it sends the OK answer immediately. Sometimes current drain disappears within one or two seconds but sometimes there is a delay of up to one minute until Vext and the current drain get low. When pulling the Emergency Off - line low during this delay, Vext immedialy goes low.
Now I Have two questions:
What is the reason for that long delay?
Does it afflict damage to the module, when I pull the Emergency Off - line low during this delay?
Can anyone help?
Thank you,
Heinz
Hello,
Using AT^SMSO command lets the module log off from the network and allows the software to enter into a secure state and save the data.
And what is the state of PWR_IND line? It's state change indicates that the module is switched off.
VBATT+ should not be disconnected before the PWR_IND signal goes high. Otherwise there is a risk of losing data.
EMERG_OFF line should be used as a last step in case of serious problems, for example if the software is not responding or reset or shutdown via AT command fails.
I think that the time to switch off the module after sending SMSO command may depend on what the module is currently doing, for example if there is a call in progress. Pulling the EMERG_OFF line causes the loss of all information stored in the volatile memory. And then the module is switched off immediately.
Best regards,
Bartłomiej
Hello Bartłomiej,
thank you for your answer. Unfortunately I have no acces to the PWR_IND line. I know, that I may lose some volatile data with using the EMERG_OFF line, but that does not matter at all and that was no my question. I especially want to know, if there may be any case, that using EMERG_OFF could be harmful for the module.
Best regards
Heinz
Hello,
EMERG_OFF line is dedicated to emergency situations to trigger shutdown as soon as possible. In most cases nothing bad will happen but there is always a small risk.
In case of normal SMSO call it may take some time to shutdown the module as it always tries to close gracefully, there is some communication with the network which ***** to be finalized etc. Please also try to deregister from the network first with AT+COPS=2 before calling AT^SMSO to test how long the deregistration takes and if it has any influence on SMSO execution time.
Regards,
Bartłomiej
Hello Bartłomiej,
thank you very much for this clarification. Of course I have to avoid any risk and I am going to check if deregistering first will help to find the reason and to find a way to switch off faster.
Best regards,
Heinz