Instability when using LTE and GPS togeather

Hi,

We are facing an issue that is most probably related to the case when both LTE and GPS are used.
The use case is like a traditional GPS tracker, fixing and tracking stats with GPS and sending that data to the cloud.
The way we are doing that is the following:

  1. Start GPS tracking is a continuous navigation mode
  2. Sending some data over LTE (mostly triggered by external events)
  3. Sending the location data if the GPS had been fixed

So the GPS is running all the time in the "background" and from time to time got preempted by the LTE radion.
The problem that we have is our firmware stuck after some hours and it happens more often if the GPS can not be fixed due to the bad reception.
But it almost did not happen at all if the GPS is able to acquire a fix in a short time (around about 15 seconds).
I tried to track it down by adding verbose logging to any critical parts, but it led nowhere.
The way it sometimes stuck (based on the verbose logs I implemented) is around network communication, socket recv() and send(). The system is not crashing but never returns from those function calls. But this is not a general thing, sometimes can not even reach them, just stuck somewhere else which I could not figure out yet.

Even implemented our own way to switch between LTE and GPS by stopping and resuming
the GPS tracking based on the RRC status changes, but did not help at all. We saw the same behaviors as before.
My assumption is based on the fact that if I disable all GPS activities, and just send dummy GPS data to our cloud, then everything is working just fine. Can run for days with any issues.
So my question would be, how to continue troubleshooting our issue? Is there any restriction in general that I missed maybe about using LTE and GPS together?

Thank you in advance!

Parents
  • Hi,

    I collected logs from the behavior I described.
    We are using nRF Connect SDK v2.2 with mfw v1.3.4 on our devices.
    This is a custom board.
    You can find 3 log sessions in the archive file, the first 2 contain the issue we have.
    The third log session is where the GPS function has been deactivated and ran with no issues at all, I stopped it manually.
    3568.log.zip

  • Thanks for sharing. The initial observation from the logs is that you are running modem FW 1.3.x on revision 1 of the nRF9160. From the modem FW release notes:

    • Note that this modem firmware is targeted nRF9160 SiP Revision 2 
    • It can be used for nRF9160 SiP Revision 1, but only for testing and development
    • It cannot be used for engineering samples of Revision 1 (e.g. DKs or Thingy:91 with version older than v0.9.0
    • After you upgrade to MFW 1.3.x it is not recommended to downgrade to MFW 1.2.x or MFW 1.1.x.(potential file system issues)

    Expect for that, I could not find anything out for the ordinary and will need to forward to our modem team. Are you able to test the application running i.e. mfw 1.2.8? 

    Kind regards,
    Øyvind

  • Our modem team have looked at the logs. They could not find any issues with the modem socket API used in the device. All responses are correct according to logs. For example in log #1 there are 172 send() messages to modem while customer trace shows that message 60 fails: [2023-10-19 15:55:16] Failed to send IoT msg 60”. A possible reason for this issue is the shared RPC memory becoming full. If the received GNSS fixes are not handled and freed properly it will eventually cause hang in data socket.

    Do you have a specific data pattern to send and receive? Is it always send() that causes the hang?

Reply
  • Our modem team have looked at the logs. They could not find any issues with the modem socket API used in the device. All responses are correct according to logs. For example in log #1 there are 172 send() messages to modem while customer trace shows that message 60 fails: [2023-10-19 15:55:16] Failed to send IoT msg 60”. A possible reason for this issue is the shared RPC memory becoming full. If the received GNSS fixes are not handled and freed properly it will eventually cause hang in data socket.

    Do you have a specific data pattern to send and receive? Is it always send() that causes the hang?

Children
No Data
Related