nRF9160DK - Tracking satellites but not getting fix

[PeterIoT]

Hello Nordic team,

We're experiencing a GNSS issue with our nRF9160-DK (PCA10090 1.1.3 2024.44) and would appreciate any guidance you can provide.

About 4 days ago, we were successfully obtaining GNSS fixes in 30-50 seconds during cold starts outdoors with clear sky visibility 1-2 times. We continued development work, and now the same hardware is unable to acquire any fix even after 600+ seconds of continuous operation.

We're developing our firmware in Rust using the nrf-modem and embassy-nrf crates. Our GNSS configuration includes:

AT%XCOEX0=1,1,1563,1587

Looking at the NMEA output from a 600-second test run 30511.log.txt(conducted outdoors, clear sky, walking around), we can see:

• Satellites are being tracked
• SNR values are abnormally low (typically 24-29 dB, occasionally reaching low 40s)
• No position fix is ever acquired (GPGGA shows fix quality 0, GPRMC shows status "V" for invalid)
• GPGSA shows mode 1 (no fix) with DOP values at 99.99

Steps taken:

• Performed AT%XFACTORYRESET=0 before running the code that produced these logs
• Tested outdoors with clear sky view for extended periods
• Verified LNA and MAGPIO configuration

We are currently in the process of acquiring a Segger to potentially update (or downgrade) the modem firmware.

• Could the abnormally low SNR values indicate a hardware issue (LNA failure)?
• Could updating the modem firmware resolve not being able to get a fix?
• What diagnostic steps would you recommend to isolate whether this is a hardware vs. firmware issue?

Logs are attached above and trace-2025-10-28T17-04-27.467Z.mtrace is here. Any insights into what might have changed or what we should investigate would be greatly appreciated.

Thank you for your assistance!

[Øyvind]

Hello, and thanks for providing both application logs and modem traces. I will have a look and discuss internally. From the modem trace I see that you are using mfw_nrf9160_1.3.4, are you able to test with 1.3.7 as well? I.e. modem FW 1.3.6 had the following changes:

*** Changes
***********
- Enhanced GNSS first fix position accuracy and sensitivity performance.
- Enhanced GNSS position accuracy in dense urban environments.
- Improved GNSS recovery speed from inaccurate assistance data.
- Improved GNSS stability and accuracy of heading output.
- Optimized GNSS duty cycle power consumption.

We're developing our firmware in Rust using the nrf-modem and embassy-nrf crates. Our GNSS configuration includes:

Just to have this tested, are you seeing the same test results with the official GNSS sample? I would assume the same but just to exclude any custom code issue.

At what location are you testing? 

Kind regards,
Øyvind

[PeterIoT]

Hello,

First of all, thank you for the prompt response!

The Segger should be arriving during this week and we will be able to update the modem firmware. The Rust code we are using is tested to be able to acquire fix. Last week while we were developing our GNSS module, we tested it a few times and were able to acquire fix in a reasonable 30-60sec interval. We moved on to develop our LTE module, and the problems started to arise when we wanted to try out transmitting actual GPS data. We reverted to the last known bare minimum GPS version, but it was not getting fixes anymore. We did a factory reset and all we could but no fix was acquired.

probe-rs (the flashing/debug tool we are using) uses WinUSB drivers while nRF Connect uses Segger drivers. It was quite challenging to make the two drivers coexist next to each other while being able to debug and flash using probe-rs and listen for mtraces via nRF Connect Cellular Monitor. Unfortunately, due to this we are not able to flash the sample codes without completely redoing our drivers and later dev environment. If you could look at the traces and logs before that, we would greatly appreciate it.

We are testing at the outskirts of Budapest, under clear sky without any obstructions. The area has max 5-6 meter high family houses, and the test is conducted at least 10m away from any building.

Thanks again!

[Øyvind]

PeterIoT said:

The Segger should be arriving during this week and we will be able to update the modem firmware.

The nRF9160DK has a Segger onboard debugger. You should be able to program the nRF9160 on the development kit without issues. 

[PeterIoT]

I assumed I needed a Segger because when I tried to use the programmer, I got the error message:

18:08:00.746	No operations possible for device.
18:08:00.746	If the device is a MCUboot device make sure it is in the bootloader mode

I read somewhere that I might need an external debugger, which is why I made that assumption. After some fiddling with the drivers, I managed to update the modem firmware to 1.3.7.

Unfortunately, after conducting another 600-second test, the issue persists—satellites are being tracked without obtaining a fix.

[PeterIoT]

I also conducted a test with your official GNSS sample. Same results, outside under clear sky without any obstructions.

Tracking:  5 Using:  0 Unhealthy: 0
-----------------------------------
Seconds since last fix: 593
Searching [/]

NMEA strings:

$GPGGA,000953.11,,,,,0,,99.99,,M,,M,,*69
$GPGLL,,,,,000953.11,V,N*45
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*2D
$GPGSV,2,1,5,11,,,26,12,,,24,21,,,24,29,,,18,1*54
$GPGSV,2,2,5,31,,,24,1*55
$GPRMC,000953.11,V,,,,,,,060180,,,N,V*07