LTE + GPS on the NRF9160

madubois

Hi everyone,

I try to use the tracker sample. If I use the gps sample, I obtain a fix relatively fast, but it fails when I try with the tracker app. I am able to communicate and connect to golioth, so it is not related to the credentials. If I check the NMEA data, I have a couple of satellite, but I never obtain a fix. If I unplug the LTE antenna after the initial connection to Golioth, I have a fix at some point (maybe 1-2 minutes). I am really not an expert on these fields, but my intuition is that, because the LTE and GPS antenna share some parts of the hardware, it may overflow the GPS part? Let me know if you need more information. Thanks,

Marc

jaredwolff

Hi @madubois

Happy New Year

madubois the LTE and GPS antenna share some parts of the hardware, it may overflow the GPS part?

While there are two ports, you are correct, they cannot run independently of each other. i.e. only one can run at a time since there is only one piece of radio hardware inside the nRF91.

As long as you get a APP_EVENT_BACKEND_CONNECTED or APP_EVENT_MOTION_EVENT it should start the GPS. I believe you will need to solder the jumper (JMP3) to get the motion capabilities.

I would make sure one of those two happens over serial console to confirm at least GPS is being started.

madubois

One element that may indicate a problem is that my registration network seem to be in roaming. Would it be possible that some features related to PSM may be disactivated by the LTE network provider?

madubois

Hi @jaredwolff,

Thanks a lot for your reply. Happy new year to you as well! So it is my understanding I see the APP_EVENT_BACKEND_CONNECTED event. In fact, I can see in Golioth a lightDB State that correspond to the state of my device (IMEA, timestamp, ip address, etc), which confirm that I can successfully connect to the LTE network and that my credentials to Golioth are OK. I was wondering what was the raw info coming from the GPS, so I just added a LOG_INF("%s", nmea_data.nmea_str); in the NRF_MODEM_GNSS_EVT_NMEA case of the gnss_event_handler function. In this setup (keeping everything else untouch), I have the initial LTE communication and the following comunication every 10 minutes (on Golioth), and I can see some NMEA data coming in, but I can only see 3 satellites and no fix even after a while.

If I start the whole process again, wait for the initial LTE communication and then, physically unplug the LTE antenna, I will obviously lose my connection with the network, but then I can get a fix in about 2 minutes. At some point, I will have up to 10 satellites and a strong GPS signal. By looking at the console, I was able to wait for the GPS fix and then replug the LTE antenna and I can see some data point in Golioth, which kind of confirm that the workflow works. So my intuition is that I may have a problem related to potential interferences between the GPS and the LTE signal.

My questions are the following:

Does it make any sense?
Looking at the prj.conf file in the tracker app, it seems there are some environment variables to tune the communication and GNSS schedules. I can see that if I let app running as is, the device communicate with Golioth every 10 minutes (by looking at the Last Report status on the server side). I presume it would be related to one of these variables:

`CONFIG_LTE_PSM_REQ_RPTAU=“00000001” # 10 min
CONFIG_LTE_PSM_REQ_RAT=“00000011” # 6 sec active time
CONFIG_LTE_LC_TAU_PRE_WARNING_NOTIFICATIONS=y
CONFIG_LTE_LC_TAU_PRE_WARNING_THRESHOLD_MS=60000
CONFIG_LTE_LC_MODEM_SLEEP_NOTIFICATIONS=y
CONFIG_LTE_LC_MODEM_SLEEP_NOTIFICATIONS_THRESHOLD_MS=60000

CONFIG_GOLIOTH_SYSTEM_CLIENT_RX_TIMEOUT_SEC=660
CONFIG_GOLIOTH_SYSTEM_CLIENT_PING_INTERVAL_SEC=600`

One element I read on some forum was that the PSM and/or eDRX features could be limited depending on the LTE provider. I noticed during the init sequence that my network mode was Roaming. I use Truphone on a Canadian network. Do you think it’s possible that the Roaming mode would limit the ability to the LTE network to go in sleep mode and thus overflow the GPS signal?
If I set GNSS_SAMPLE_PERIODIC_TIMEOUT to 0, is it going to limit any LTE communication until I receive a valid fix?

I must put emphasis on the fact that this is really not my area of expertise, my apologies if some of my questions may look naive. Anyhow, thank @jaredwolff for this amazing work!

jaredwolff

madubois Does it make any sense?
Looking at the prj.conf file in the tracker app, it seems there are some environment variables to tune the communication and GNSS schedules. I can see that if I let app running as is, the device communicate with Golioth every 10 minutes (by looking at the Last Report status on the server side). I presume it would be related to one of these variables:

Not quite in the way you think at least.

One thing that I had an issue with Golioth early on was that there was no easy way to disconnect and go low power. My guess is the client is keeping the modem alive giving the GPS no active time to get a fix.

madubois One element I read on some forum was that the PSM and/or eDRX features could be limited depending on the LTE provider. I noticed during the init sequence that my network mode was Roaming. I use Truphone on a Canadian network. Do you think it’s possible that the Roaming mode would limit the ability to the LTE network to go in sleep mode and thus overflow the GPS signal?

You are correct here. If it’s not supported by your carrier it will never go to sleep and this as well may cause the GPS side not to have enough contiguous time to get a fix.

One thing you can look for is the modem sleep notifications: LTE_LC_EVT_MODEM_SLEEP_ENTER in app_modem.c. This will tell you if the modem has gone to sleep. (usually PSM mode)

If I set GNSS_SAMPLE_PERIODIC_TIMEOUT to 0, is it going to limit any LTE communication until I receive a valid fix?

It will run continuously but it may be interrupted by modem operations.

From the modifications to the GPS code I think you did, you can also tell when the GPS is active. In non-assisted cases you need at least 60 seconds to 1.5 min to get a fix uninterrupted.