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

[Markus Schlittenbauer]

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

[Nishant Gaurav]

 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.

[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