PLS8 prolonged higher current drain. | Telit Cinterion IoT Developer Community
November 18, 2020 - 11:37pm, 3554 views
Hi,
We are experiencing some strange behaviour with a tracking product we produce using the PLS8. In normal operation these trackers requires an average current of about 70 mA with the PLS8's GPS engine running. Current will peak to about 240 mA during network activity and then drop back to the 70 mA average. Under the operational state where we're seeing the problem, devices are simply connected to the cellular network waiting for any incoming SMS commands. Devices are not connected in any way to the internet in this state The microcontroller operating the PLS8 sends the AT command, "AT+CPMS?", periodically to check for incoming messages (we also have URC set to report incoming messages but found that to not be 100% reliable). Very occasionally, current will increase to about 240 mA during network activity but then stay at that level. Sending the device an SMS command causes the current drain to return to a normal 70 mA average as soon as the message has been received. It's as if the PLS8 starts some sort of continuous cell network activity. Would you have any idea what might be going on here please?
Thank you,
Ed Haslam
Hello,
As I understand the problem is that very occasionally the current consumption does not fall down from about 240 mA to 70 mA after the network activity. Can you explain some more about what kind of activity this is and how long the consumption stays high after that? Can you also try how frequently you observe this?
According to documentation during the data transfer the average current consumption could be much higher that 240 mA. For idle state there are also average consumptions defined. But the device communicates with the network periodically and there may be peaks. Maybe you could enable some diagnostic URCs to monitor the network connection with AT+CGEREP, AT+CEREG, AT+CREG commands and also some indicators with AT^SIND command (please see AT spec for details).
Best regards,
Bartłomiej
Hi Bartłomiej,
Thank you for the reply. This problem has been seen during testing in a static location where devices usually draw on average 60 - 70 mA. Current consumption will increase during network activity and reach peak values around 240 - 250 mA for at the most, a few seconds. The problem we are seeing is, once every few hours or longer, current draw does not drop back from peak values to the lower average current and stays constantly at 240 - 250 mA for minutes or even hours at a time. However, when those periods of continuous high current consumption occur, sending a text message to a device always causes the current to drop back to 60 -70 mA average once a device has sent a text message reply. This problem occurs more with certain carriers than others. This is occuring with devices idle and simply camped on the network. The only modem activity is an "AT+CPMS?" command every two minutes to check for messages (we found that relying on the URC for new messages didn't always seem to work). Curiously, when we coded additional commands for diagnostic purposes, the extended periods of high current drain almost never (but still very occasionally) happen. Typical diagnostic output with additional commands is:
AT+CPMS?
+CPMS: "ME",0,255,"ME",0,255,"MT",0,255
AT^SMONI
^SMONI: 4G,850,2,20,20,FDD,302,610,2B13,1ECCA2A,398,37,-90,-12,NOCONN
AT+CEREG?
+CEREG: 2,1,"2B13","01ECCA2A",7
AT+CREG?
+CREG: 0,1
Can you please tell me what might cause the PLS8 to occasionally operate at this higher current level for such long periods of time?
Thank you,
Ed
Hello,
I can't state for sure why the average consumption in idle can stay at that level for hours.
This might be a kind of abnormal situation, especially that it happens very rarely. This may suggest some network activity still ongoing. In fact this could probably mean the active uplink. You could disconnect the antenna and check what happens with the current then. It it rises even more it would be a kind of confirmation.
If these commands were sent at the moment when this problem occurred they don't show anything abnormal though. If not, it would be good to check if anything changes in the outputs at that time.
You could test if this also happens in 3G. And some other operators.
There are few factors that are relevant here - the module, the network, the hardware, the way that the current is measured.
I think that you can report this to the support line. Your hardware setup may need to be verified to make sure that the measurements are done correctly, the module trace may be necessary to see what is exactly happening on the module at that time (which may be problematic if it happens only sporadically) - maybe it's some issue between he module and the network in the connection release or the module is on a cell border and it is related to cell reselection.
Regards,
Bartłomiej
Hi Bartłomiej,
Thanks for your reply, I know there's a lot of factors involved and it's hard to identify a single likely cause of this problem. We'll try to raise the question with our local field office. Was just wondering though if there may be a clue in the way the problem greatly improves when the additional "AT^SMONI", "AT+CEREG?", and "AT+CREG?" diagnostic commands are being sent to the modem about once every two minutes. It's more than coincidence since I've been able to go back and forth between the two firmware versions and the results are repeatable. Without the additional commands, high current drain for prolonged periods lasting minutes or more occurs at least once every two or three hours. With the additional commands, I'm lucky to catch a sustained period of increased current consumption once every couple of days. What do you suppose those commands might be doing to change behaviour on the network?
Thank you,
Ed
Hello,
The module does some measurements. And these commands only read parameters that the module stores. They don't trigger any network interaction. So in theory sending these commands should have no impact. So I can't provide any proof how and if they could help to recover from this situation.
To be able to diagnose this case from the module side it is necessary to record and analyze traces from the module.
BR,
Bartłomiej
Hi Bartłomiej,
You were correct about the diagnostic commands we added not likely being responsible for a return to normal operation. After further testing, it seems it was only a coincidence that their addition had reduced this problem's frequency. However, there is a factor that definitely is involved. In operation, devices initially check the age of the last downloaded A-GPS file and if out of date, establish a TCP connection, then download the latest file. The TCP connection is then closed and everything else is done by SMS messaging.
If I enter an invalid APN though, so a device has no possibility of getting onto the internet, we never see these extended periods of elevated current consumption. It appears that devices are involved in some sort of ongoing internet activity that our firmware is not responsible for. There is no indication from our debug data while the current drain remains high, that anything internet related is going on. Do you know of anything the network would be doing that requires an APN and might account for the extra current drain, please?
Thank you,
Ed
Hello,
As I understood before this situation happens only after your application is using a data connection (or is it not always true), so it looks like there may be no disconnection sometimes for some reason. I think that it is necessary to trace the module to find the cause. Does it depend on network operators or access technology? APN is necessary for 4G registration but it can be assigned by the network.
Regards,
Bartłomiej
Hi Bartłomiej,
This problem does occur more with some networks than others. If I use an invalid APN, the problem never happens but then I imagine the module is only operating 3G at that point. With the invalid APN, a data connection is never established. So it sounds like whatever is happening is 4G related. I'm not sure how the module's dropping to more reasonable average current levels for hours or days immediately after receiving and replying to a message fits into this though. Is there a best way to make sure the PLS8 consistently draws as little current as possible with 4G while simply waiting for incoming messages?
Thank you,
Ed
Hi Bartłomiej,
Not sure if you saw my previous post. Can you please let me know if there's an optimal way you can think of to make sure the PLS8 consistently draws as little current as possible with 4G operation while simply waiting for incoming messages?
Thank you,
Ed
Hello,
If it was observed only after data transfer and is not observed when there is an invalid APN configured and therefore data connection does not get established this seems to confirm that the problem might be somehow related to connection release procedure. However in 3G and 2G you can also transmit data. So it is a good question if this also happens in other RAT's. You can force the RAT with AT+COPS command.
BTW what is the default way your application is using the data connection - any short log?
We don't know if it's the module's or network's fault. We may expect that the activities that require a communication with the network might be helpful. I suppose that such a brutal thing like forcing network registration again with AT+COPS=0 could help but it's rather not a good solution. You might also try RAT change but it's also not an elegant solution.
BTW could you check ATI1 output?
Best regards,
Bartłomiej
Pages