GNSS very bad reception / unreliable fix

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Thu, 23 Apr 2026 10:17:58 GMT

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.

RE: GNSS very bad reception / unreliable fix

Markus Schlittenbauer — Thu, 23 Apr 2026 09:49:19 GMT

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!

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Thu, 23 Apr 2026 09:24:31 GMT

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.

RE: GNSS very bad reception / unreliable fix

Markus Schlittenbauer — Thu, 23 Apr 2026 09:14:51 GMT

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?

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Thu, 23 Apr 2026 08:21:47 GMT

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:

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();

RE: GNSS very bad reception / unreliable fix

Markus Schlittenbauer — Thu, 23 Apr 2026 07:34:09 GMT

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

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Thu, 23 Apr 2026 07:28:36 GMT

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.

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Thu, 23 Apr 2026 07:20:39 GMT

yes, you are correct — if you were looking for the GNSS LNA solder bridge (SB1/SB2), it appears to be present on the standard nRF9151 DK (with patch antenna), but not on the SMA DK. This is likely because the SMA DK uses external SMA-connected antennas and the LNA configuration may be handled differently on that board.

RE: GNSS very bad reception / unreliable fix

Markus Schlittenbauer — Wed, 22 Apr 2026 19:15:38 GMT

PS: I cant find the solder bridge on the SMA-devkit (Maybe you meant the normal Devkit that has a patch antenna ?):

docs.nordicsemi.com/.../solder_bridge_configuration.html

RE: GNSS very bad reception / unreliable fix

Markus Schlittenbauer — Wed, 22 Apr 2026 18:42:52 GMT

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!!

RE: GNSS very bad reception / unreliable fix

Nishant Gaurav — Wed, 22 Apr 2026 16:29:20 GMT

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!