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

[Øyvind]

Thanks for testing! I've forwarded this internally to get more feedback on possible cause. 

Kind regards,
Øyvind

[Øyvind]

Hello again, 

Upon reviewing the modem log, it was observed that LTE is active. However, +CEREG notifications have not been subscribed, and therefore are not visible in the log. Power Saving Mode (PSM) has been requested, albeit without any specific parameters. As a result, the default configuration is applied, which includes an active time of one minute. The network accepts this configuration, and PSM with a one-minute active time is consequently utilized.

When GNSS is initiated, LTE activity intermittently disrupts GNSS operation until the modem enters PSM following one minute of inactivity. After this transition, the GNSS signal levels are notably low. Although the GNSS module is able to track some satellites, it fails to decode ephemerides for a sufficient number of them.

An examination of the Automatic Gain Control (AGC) level indicates that it is slightly low, suggesting the possibility of interference. It is recommended to verify the testing environment, specifically, the physical location of the device during testing. For instance, interference from nearby electronic devices such as laptops could be a contributing factor.

Updating the modem firmware to the latest version is advisable, as recent releases include significant improvements to GNSS functionality. However, it should be noted that firmware updates alone will not resolve the issue of low signal levels. It is understood that the device is utilizing the onboard GNSS antenna provided with the development kit (DK). Please verify if external or onboard antenna is used.

[PeterIoT]

Sorry for the late response.

During last weekend we managed to solve the problem. The issue was that the device was too close to the laptop. Upon switching to a longer cable and keeping around 1m distance from the laptop, we are able to get fixes without problems in a reasonable 30-60sec interval.

Thank you for the help.

[Øyvind]

I'm glad we were able to to help! Good luck in the ongoing testing, and let us know if you get any further or other issues.

Kind regards,
Øyvind