GNSS very bad reception / unreliable fix

[Markus Schlittenbauer]

We are using the Asset Tracker Template with on a nRF9151-SMA-Devkit, using the enclosed external GNSS antenna outdoors (out of the window) and the GNSS reception is very bad.
Even when the device is using the A-GPS and M-Cell location, the GNSS fix sometimes takes minutes to get, even when there is very little obstruction

Are we missing an option to activate the power for the LNA ? (I assume this is already activated in the Asset Tracker Template ?)

What is the recommended setting for a 10 second tracking interval (constantly updating the GNSS fix and sending the latest GNSS fix every 10 seconds) ?

Thanks a lot!

[Nishant Gaurav]

Hi Markus,

A few things to check — the most likely culprit is the LNA not being enabled for the external SMA antenna.

1. Enable the LNA via COEX0 (most important)

On the nRF9151-SMA-DK, the external antenna LNA must be explicitly enabled. Send this AT command (or add it to your modem initialization):

```
AT%XCOEX0=1,1,1565,1586
```

This tells the modem to assert COEX0 during GNSS operation in the L1 band. Without this, the external SMA antenna will perform very poorly regardless of clear sky view.

In your `prj.conf`, also confirm:
```
CONFIG_NRF_MODEM_LIB=y
CONFIG_GNSS_MODULE=y
```

2. Confirm the SMA antenna is physically selected.

The nRF9151-SMA-DK has a solder bridge to switch between the onboard patch antenna and the SMA connector. Double-check the board schematic to confirm ANT_SEL is set for the SMA port.

3. Recommended settings for 10-second tracking interval

For continuous 10s fix + send, add the following to your `prj.conf`:

```
# Continuous GNSS tracking
CONFIG_GNSS_SAMPLE_MODE_CONTINUOUS=y
CONFIG_GNSS_SEARCH_TIMEOUT=120

# Disable PSM — it conflicts with frequent GNSS+LTE use
CONFIG_LTE_PSM_REQ=n

# Give GNSS priority over LTE during fix acquisition
# Send this at runtime before each fix attempt:
# AT%XGNSSPRIO=1
```

Note: LTE and GNSS share the RF frontend on the nRF9151, so frequent 10s LTE transmissions will interrupt GNSS. Using `AT%XGNSSPRIO=1` temporarily during fix acquisition helps a lot.

4. Make sure A-GPS data is being injected

Ensure the device has an LTE connection before starting GNSS, and confirm in `prj.conf`:

```
CONFIG_NRF_CLOUD_AGPS=y
CONFIG_NRF_CLOUD_PGPS=y
```

Without A-GPS injection, cold TTFF can easily take several minutes even with good sky view.

Hope that helps!

[Markus Schlittenbauer]

Thanks for the quick reply.
So far most is clear to me.

However, about the injection of A-GPS data before starting GNSS; at some other point in the documentation I found this piece:

    /* Activate GNSS before LTE connects so the modem RF is shared from the start.

     * CFUN=31 enables GNSS without deactivating LTE; conn_mgr_all_if_connect()

     * then brings up LTE concurrently.

     */

    err = nrf_modem_at_printf("AT+CFUN=31");

Should this be used at all ?

Thanks!!

[Nishant Gaurav]

Regarding AT+CFUN=31: it is a valid command that activates GNSS without changing the LTE state.

However, the key constraint to keep in mind is that on the nRF91 Series, GNSS is time-multiplexed with LTE, and GNSS can only operate when the LTE modem is:

• Completely deactivated, or
• In RRC Idle mode (DRX/eDRX), or
• In Power Saving Mode (PSM)

So using AT+CFUN=31 to activate GNSS while LTE is also active is valid, but GNSS will only get time windows to operate when LTE is in idle/PSM — it won't run freely while LTE is in connected (RRC connected) mode.

[Markus Schlittenbauer]

Thanks, some of your initially suggested settings seemed to have helped as now the GNSS fix comes much faster.
However we are still seeing that after a LTE transmission has taken place, the GNSS modules seems to have to "start from scratch again", as all it does not see any satellites for 10-20 seconds. It this the intended behaviour ?

[00:08:52.901,031] <inf> gnss: GNSS fix: lat=47.855863, lon=12.166669, acc=30.3 m
[00:08:53.235,046] <inf> tracker: Periodic send: fix=1, lat=47.855863, lon=12.166669
[00:08:53.237,670] <inf> coap_client: Position sent (107 bytes): {"fix":1,"lat":47.855863,"lon":12.166669,"alt":551.3,"acc":30.3,"ts":1776929526216}
[00:08:53.897,918] <inf> gnss: GNSS fix: lat=47.855862, lon=12.166670, acc=30.9 m
[00:08:54.906,738] <inf> gnss: GNSS fix: lat=47.855857, lon=12.166663, acc=30.5 m
[00:08:55.907,348] <inf> gnss: GNSS fix: lat=47.855853, lon=12.166661, acc=30.6 m
[00:08:56.866,577] <inf> gnss: GNSS fix: lat=47.855868, lon=12.166648, acc=30.3 m
[00:08:57.237,670] <wrn> coap_client: No CoAP ACK (errno 11)
[00:08:57.237,701] <wrn> coap_client: Send attempt 1 failed (-116), reconnecting DTLS
[00:08:57.238,983] <inf> coap_client: Resolved xxx.dev -> xxx.59.205.118:xxx
[00:08:57.866,668] <inf> coap_client: DTLS socket connected (fd=0)
[00:08:57.868,103] <inf> coap_client: Position sent (107 bytes): {"fix":1,"lat":47.855863,"lon":12.166669,"alt":551.3,"acc":30.3,"ts":1776929526216}
[00:08:58.031,890] <inf> coap_client: CoAP ACK received (13 bytes)
[00:08:58.246,643] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:59.246,734] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:00.246,917] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:01.247,070] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:02.247,344] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:03.247,497] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:04.247,924] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:05.248,046] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:06.248,291] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:07.249,237] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:08.250,213] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:09.251,220] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:10.252,166] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:11.253,112] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:12.254,150] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:13.255,065] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:14.256,042] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:15.257,019] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:16.257,965] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:17.258,972] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:17.589,874] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x02)
[00:09:18.616,271] <inf> gnss: GNSS fix: lat=47.856045, lon=12.166641, acc=66.7 m
[00:09:19.617,523] <inf> gnss: GNSS fix: lat=47.856066, lon=12.166587, acc=36.4 m
[00:09:20.668,792] <inf> gnss: GNSS fix: lat=47.856020, lon=12.166609, acc=34.6 m
[00:09:21.638,397] <inf> gnss: GNSS fix: lat=47.856006, lon=12.166610, acc=32.4 m

[Nishant Gaurav]

Yes, this is expected behavior on the nRF91 Series. What you're observing is the GNSS being blocked by LTE activity during the CoAP transmission.

Notice the flags=0x08 in your log — this corresponds to the NRF_MODEM_GNSS_PVT_FLAG_NOT_ENOUGH_WINDOW_TIME flag, which indicates that LTE idle mode operations are consuming the time windows that GNSS needs to track satellites.

Here's what's happening:

1. During LTE transmission (RRC Connected mode): The GNSS and LTE modem share resources and are time-multiplexed, with LTE having priority. When your device sends the CoAP packet and enters RRC Connected mode, GNSS is effectively blocked.

   After the transmission (RRC Idle mode): Even after the LTE connection is released, the NOT_ENOUGH_WINDOW_TIME flag persists for a while. This is because the flag is based on a rolling average of the time window granted to GNSS — the average is still low immediately after RRC Connected mode, and it takes time (roughly 10–20 seconds) for the average to recover above the 10-second threshold.

 

Recommended mitigations

• Enable PSM (Power Saving Mode): Puts the LTE modem into deep sleep, allowing GNSS to run freely.
• Enable eDRX: Extends the sleep interval between LTE paging events, giving GNSS larger time windows.
• Enable GNSS priority mode: If the NOT_ENOUGH_WINDOW_TIME flag is set in several consecutive PVT events, you can call nrf_modem_gnss_prio_mode_enable() to give GNSS priority over LTE idle mode procedures. It disables automatically after the first fix or after 40 seconds.
  err = nrf_modem_gnss_prio_mode_enable();

[Markus Schlittenbauer]

Hi

yes, we did use nrf_modem_gnss_prio_mode_enable();,
now even after each LTE transmission.

Still we get these results:

[00:08:34.569,366] <inf> gnss: GNSS fix: lat=47.855630, lon=12.166649, acc=7.9 m
[00:08:35.534,027] <inf> gnss: GNSS fix: lat=47.855624, lon=12.166651, acc=7.9 m
[00:08:36.534,088] <inf> gnss: GNSS fix: lat=47.855617, lon=12.166655, acc=8.0 m
[00:08:37.531,280] <inf> gnss: GNSS fix: lat=47.855619, lon=12.166654, acc=8.0 m
[00:08:38.540,100] <inf> gnss: GNSS fix: lat=47.855606, lon=12.166656, acc=8.0 m
[00:08:38.791,076] <inf> tracker: Periodic send: fix=1, lat=47.855606, lon=12.166656
[00:08:38.793,090] <inf> coap_client: Position sent (106 bytes): {"fix":1,"lat":47.855606,"lon":12.166656,"alt":517.3,"acc":8.0,"ts":1776935474855}
[00:08:40.541,748] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:41.542,785] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:42.543,762] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:42.793,823] <wrn> coap_client: No CoAP ACK (errno 11)
[00:08:42.793,853] <wrn> coap_client: Send attempt 1 failed (-116), reconnecting DTLS
[00:08:42.913,085] <inf> coap_client: Resolved xxxx.dev -> xxxxx:5684
[00:08:43.308,898] <inf> coap_client: DTLS socket connected (fd=0)
[00:08:43.310,394] <inf> coap_client: Position sent (106 bytes): {"fix":1,"lat":47.855606,"lon":12.166656,"alt":517.3,"acc":8.0,"ts":1776935474855}
[00:08:43.459,045] <inf> coap_client: CoAP ACK received (13 bytes)
[00:08:43.459,472] <inf> tracker: repeated GNSS priority mode enabled (LTE deprioritised)
[00:08:44.460,510] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:45.461,486] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:46.462,432] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:47.463,409] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:48.464,447] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:49.465,362] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:50.466,369] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:51.467,376] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:52.468,322] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:53.469,329] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:54.470,275] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:55.471,252] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:56.472,290] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:57.472,320] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:58.472,351] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:08:59.472,808] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:00.473,785] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:01.474,761] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:02.475,769] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:03.476,715] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:04.477,722] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:09:04.857,360] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x02)
[00:09:05.888,671] <inf> gnss: GNSS fix: lat=47.855493, lon=12.166722, acc=77.1 m
[00:09:06.888,336] <inf> gnss: GNSS fix: lat=47.855540, lon=12.166707, acc=70.1 m
[00:09:07.892,089] <inf> gnss: GNSS fix: lat=47.855674, lon=12.166618, acc=37.6 m
[00:09:08.888,763] <inf> gnss: GNSS fix: lat=47.855635, lon=12.166672, acc=30.7 m
[00:09:09.895,019] <inf> gnss: GNSS fix: lat=47.855632, lon=12.166692, acc=26.0 m
[00:09:10.888,336] <inf> gnss: GNSS fix: lat=47.855630, lon=12.166700, acc=22.1 m
[00:09:11.886,871] <inf> gnss: GNSS fix: lat=47.855587, lon=12.166723, acc=19.7 m
[00:09:12.889,739] <inf> gnss: GNSS fix: lat=47.855584, lon=12.166724, acc=19.3 m
[00:09:13.889,984] <inf> gnss: GNSS fix: lat=47.855589, lon=12.166722, acc=18.1 m
[00:09:14.889,862] <inf> gnss: GNSS fix: lat=47.855586, lon=12.166723, acc=17.7 m
[00:09:15.916,320] <inf> gnss: GNSS fix: lat=47.855585, lon=12.166724, acc=17.2 m
[00:09:16.919,982] <inf> gnss: GNSS fix: lat=47.855572, lon=12.166723, acc=16.9 m
[00:09:17.927,429] <inf> gnss: GNSS fix: lat=47.855569, lon=12.166720, acc=16.5 m
[00:09:18.931,274] <inf> gnss: GNSS fix: lat=47.855565, lon=12.166720, acc=16.2 m
[00:09:19.908,325] <inf> gnss: GNSS fix: lat=47.855558, lon=12.166723, acc=15.9 m
[00:09:20.917,694] <inf> gnss: GNSS fix: lat=47.855532, lon=12.166741, acc=15.0 m
[00:09:21.911,285] <inf> gnss: GNSS fix: lat=47.855528, lon=12.166745, acc=13.9 m
[00:09:22.889,892] <inf> gnss: GNSS fix: lat=47.855519, lon=12.166755, acc=13.7 m
[00:09:23.884,521] <inf> gnss: GNSS fix: lat=47.855512, lon=12.166760, acc=13.5 m
[00:09:24.923,492] <inf> gnss: GNSS fix: lat=47.855508, lon=12.166765, acc=13.3 m
[00:09:25.921,325] <inf> gnss: GNSS fix: lat=47.855504, lon=12.166768, acc=13.5 m
[00:09:26.921,508] <inf> gnss: GNSS fix: lat=47.855502, lon=12.166768, acc=13.5 m
[00:09:27.890,716] <inf> gnss: GNSS fix: lat=47.855500, lon=12.166769, acc=13.5 m

How can we avoid that it takes 20 seconds after each sending to get a GNSS fix again?

[Nishant Gaurav]

1. Enable PSM (most effective for infrequent sends)

PSM puts the LTE modem into deep sleep, allowing GNSS to run freely without LTE interference.

err = lte_lc_psm_req(true);

if (err)

{ LOG_ERR("lte_lc_psm_req, error: %d", err);

}

With PSM, after the Active Timer expires, the modem enters deep sleep and GNSS gets uninterrupted time. A short Active Timer (e.g. 6 seconds) means the modem enters PSM quickly after each transmission.

2. Enable eDRX

eDRX extends the sleep interval between LTE paging events, giving GNSS larger time windows during RRC Idle mode:

err = lte_lc_edrx_req(true);

if (err)

{ LOG_ERR("lte_lc_edrx_req, error: %d", err);

}

The most reliable fix for your use case is to enable PSM with a short Active Timer (e.g. 6 seconds). This way, after your CoAP send completes, the modem quickly enters deep sleep and GNSS recovers without the ~20-second delay you're seeing. Note that PSM support depends on your carrier network granting the requested parameters.

[Markus Schlittenbauer]

Thanks again for the quick reply.
We are already using eDRX with a 40 seconds sleep time,

[00:00:10.825,134] <inf> gnss: GNSS started (priority mode for initial fix)
[00:00:10.825,775] <inf> tracker: eDRX active: cycle=40.96 s, PTW=2.56 s

but PSM is not applicable, as our networks here allow PSM only with long sleep times (usually 60 minutes or more) and we would need to go to a minimum of 30 seconds or 60 seconds tracking update interval.

I am just wondering why the GNSS seems to start "from scratch" again after the LTE transmission has been done. I would rather expect the GNSS behaving as if the antenna is shielded for some time (showing accuracy dropping from 10 to 90 meters slowly), but not starting from 0.

For example, if I had the antenna outside and move it inside, this is what I got:

[00:32:53.300,842] <inf> tracker: repeated GNSS priority mode enabled (LTE deprioritised)
[00:32:54.301,696] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:32:55.302,673] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:32:56.303,680] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:32:57.304,626] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:32:58.305,633] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:32:59.306,579] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:00.307,556] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:01.308,593] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:02.309,509] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:03.310,485] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:04.311,492] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:05.312,438] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:06.313,446] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:07.314,392] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:08.315,368] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:09.316,406] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:10.317,321] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:11.318,298] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:12.319,305] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x08)
[00:33:12.761,444] <inf> gnss: GNSS searching (0 tracked, 0 usable, flags=0x02)
[00:33:13.781,616] <inf> gnss: GNSS fix: lat=47.855296, lon=12.167014, acc=93.1 m
[00:33:14.679,901] <inf> gnss: GNSS fix: lat=47.855954, lon=12.166539, acc=13.2 m
[00:33:15.679,595] <inf> gnss: GNSS fix: lat=47.855900, lon=12.166602, acc=9.9 m
[00:33:16.682,128] <inf> gnss: GNSS fix: lat=47.855871, lon=12.166620, acc=8.5 m
[00:33:17.685,821] <inf> gnss: GNSS fix: lat=47.855842, lon=12.166633, acc=7.5 m
[00:33:18.692,962] <inf> gnss: GNSS fix: lat=47.855831, lon=12.166636, acc=6.8 m
[00:33:19.682,983] <inf> gnss: GNSS fix: lat=47.855815, lon=12.166646, acc=6.4 m
[00:33:20.685,272] <inf> gnss: GNSS fix: lat=47.855812, lon=12.166646, acc=6.1 m
[00:33:21.684,875] <inf> gnss: GNSS fix: lat=47.855808, lon=12.166651, acc=5.9 m
[00:33:22.681,610] <inf> gnss: GNSS fix: lat=47.855807, lon=12.166649, acc=5.6 m
[00:33:23.684,448] <inf> gnss: GNSS fix: lat=47.855803, lon=12.166645, acc=5.4 m
[00:33:24.681,335] <inf> gnss: GNSS fix: lat=47.855791, lon=12.166638, acc=5.2 m
[00:33:25.683,166] <inf> gnss: GNSS fix: lat=47.855789, lon=12.166628, acc=5.5 m
[00:33:26.684,448] <inf> gnss: GNSS fix: lat=47.855773, lon=12.166618, acc=5.8 m
[00:33:27.688,293] <inf> gnss: GNSS fix: lat=47.855749, lon=12.166597, acc=6.4 m
[00:33:28.683,288] <inf> gnss: GNSS fix: lat=47.855753, lon=12.166597, acc=7.2 m
[00:33:29.683,746] <inf> gnss: GNSS fix: lat=47.855750, lon=12.166593, acc=8.3 m
[00:33:30.666,351] <inf> gnss: GNSS fix: lat=47.855748, lon=12.166586, acc=9.9 m
[00:33:31.689,727] <inf> gnss: GNSS fix: lat=47.855746, lon=12.166579, acc=11.8 m
[00:33:32.683,654] <inf> gnss: GNSS fix: lat=47.855744, lon=12.166572, acc=14.0 m
[00:33:33.679,809] <inf> gnss: GNSS fix: lat=47.855742, lon=12.166564, acc=16.5 m
[00:33:34.669,036] <inf> gnss: GNSS fix: lat=47.855740, lon=12.166556, acc=19.2 m
[00:33:35.658,752] <inf> gnss: GNSS fix: lat=47.855738, lon=12.166551, acc=22.1 m
[00:33:36.659,637] <inf> gnss: GNSS fix: lat=47.855735, lon=12.166547, acc=25.1 m
[00:33:37.657,073] <inf> gnss: GNSS fix: lat=47.855733, lon=12.166543, acc=28.4 m
[00:33:38.659,515] <inf> gnss: GNSS fix: lat=47.855730, lon=12.166541, acc=31.8 m
[00:33:39.650,115] <inf> gnss: GNSS fix: lat=47.855728, lon=12.166535, acc=35.5 m
[00:33:40.681,152] <inf> gnss: GNSS fix: lat=47.855726, lon=12.166529, acc=39.3 m
[00:33:41.678,436] <inf> gnss: GNSS fix: lat=47.855723, lon=12.166523, acc=43.2 m
[00:33:42.674,438] <inf> gnss: GNSS fix: lat=47.855721, lon=12.166517, acc=47.3 m
[00:33:43.679,199] <inf> gnss: GNSS fix: lat=47.855719, lon=12.166511, acc=51.6 m
[00:33:44.650,299] <inf> gnss: GNSS fix: lat=47.855717, lon=12.166505, acc=56.0 m
[00:33:45.680,603] <inf> gnss: GNSS fix: lat=47.855715, lon=12.166499, acc=60.5 m
[00:33:46.686,401] <inf> gnss: GNSS fix: lat=47.855712, lon=12.166493, acc=65.1 m
[00:33:47.687,316] <inf> gnss: GNSS fix: lat=47.855710, lon=12.166487, acc=69.9 m
[00:33:48.691,619] <inf> gnss: GNSS fix: lat=47.855708, lon=12.166481, acc=74.7 m
[00:33:49.666,229] <inf> gnss: GNSS fix: lat=47.855706, lon=12.166475, acc=79.7 m
[00:33:50.660,461] <inf> gnss: GNSS fix: lat=47.855704, lon=12.166469, acc=84.8 m
[00:33:51.661,712] <inf> gnss: GNSS fix: lat=47.855702, lon=12.166463, acc=90.1 m
[00:33:52.922,363] <inf> gnss:   SV  23: cn0=24.6 dB/Hz, elev=30, az=140, flags=0x01

I took the antenna inside at timestamp [00:33:26.684,448], after that the GNSS reception is probably down to 1-2 satellites visible, and so the accuracy drops slowly... but there is still a fix available for another 25 seconds, until it finally breaks down at [00:33:52.922,363]. 

When I put the device outside again before these 25 seconds have passed, it quickly regains accuracy again without ever dropping the fix:



But after an LTE sending, the GNSS reception behaves if it was a full reset.

Can this be avoided somehow ?

Thanks!

[Nishant Gaurav]

Hi Markus,

What you are observing is expected behavior on nRF91 devices due to LTE and GNSS RF coexistence.

this can be avoided somehow,

• A-GNSS assistance data — The single biggest improvement. With fresh ephemeris injected, re-acquisition after an LTE interruption drops from ~20 seconds to 1–3 seconds.
• Minimize LTE TX duration — Shorter transmissions mean shorter GNSS blackouts. Use small payloads and efficient encoding.
• Don't call nrf_modem_gnss_stop() / start() around LTE events — Let the modem manage the arbitration internally rather than doing a full API-level restart.