RTUX50 - FW0.7.24.1 - No GPS Fix

Networking Solutions Issue
1

After Hours and Hours talking to ChatGPT - we have no idea why the GPS Modul do not make a Satelite FIX. Here a Summary of all Things we do the last two Days. Maybe you have some other ideas?

Teltonika RUTX50 / Quectel RG501Q-EU — GNSS Failure Investigation

1. System

Router: Teltonika RUTX50
Current RutOS: RUTX_R_00.07.24.1
Modem: Quectel RG501Q-EU

Modem identification:

Quectel
RG501Q-EU
Revision: RG501QEUAAR12A11M4G_04.202.04.202

RutOS modem API reports:

version: RG501QEUAAR12A11M4G
cfg_version: 04.202.04.202

Important: RutOS 07.24.1 was installed after the GNSS problem had already occurred. Therefore, the firmware update was not the original trigger.

2. Problem History

GNSS/GPS previously worked correctly.

The problem appeared after a second Traccar/AVL destination was configured. After this change, position data stopped being received.

The AVL configuration was subsequently investigated. No configuration was found that would explain why the GNSS engine itself no longer obtains a fix.

Filesystem timestamps showed a modification of /etc/config/avl corresponding to the Traccar configuration change, but no corresponding modification of /etc/config/gps.

Therefore, the temporal relationship with the AVL change is known, but no causal mechanism between AVL configuration and the GNSS receiver failure has been identified.

The router is installed on a vehicle roof with permanently unobstructed sky visibility.

3. Main GNSS Symptom

The GNSS engine can be started successfully:

AT+QGPS?

+QGPS: 1

However:

AT+QGPSLOC=2

+CME ERROR: Not fixed now

Originally, GSV output showed GPS and Galileo satellite IDs and, for some satellites, elevation and azimuth.

Example:

$GPGSV,2,1,08,01,17,258,,02,43,270,,07,,,,08,71,272,,1*59
$GPGSV,2,2,08,10,63,081,,14,05,330,,15,02,019,,16,14,187,,1*63

$GAGSV,3,1,11,03,14,035,,07,03,133,,08,18,087,,13,54,064,,7*7B
$GAGSV,3,2,11,15,02,068,,21,26,188,,23,51,251,,26,68,260,,7*71
$GAGSV,3,3,11,31,26,313,,32,17,061,,33,17,251,,7*44

The important observation is that C/N0/SNR was empty for every satellite.

Therefore, satellite geometry in GSV was not considered proof of actual RF tracking.

GSA showed:

$GPGSA,A,1,...

No satellites were being used for a position solution.

RMC showed:

$GPRMC,,V,,,,,,,,,,N,V*29
$GARMC,,V,,,,,,,,,,N,V*38

This is particularly significant because there was not only no valid position, but also no GNSS UTC time.

4. Direct NMEA Observation

The USB ports are:

/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB3

/dev/ttyUSB2 carries AT/modem communication.

Inspection of the running gpsd process showed that gpsd had:

/dev/ttyUSB1

open as its GNSS/NMEA device.

For diagnostic purposes, gpsd was stopped and /dev/ttyUSB1 was confirmed to be free. GNSS was then manually started with:

AT+QGPS=1

and /dev/ttyUSB1 was read directly.

The modem continuously produced NMEA, for example:

$GPGGA,,,,,,0,,,,,,,,*66
$GAGGA,,,,,,0,,,,,,,,*77

$GPVTG,,T,,M,,N,,K,N*2C
$GAVTG,,T,,M,,N,,K,N*3D

$GPRMC,,V,,,,,,,,,,N,V*29
$GARMC,,V,,,,,,,,,,N,V*38

$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GAGSA,A,1,,,,,,,,,,,,,,,,*23

This continued over an extended observation period.

Thus:

  • NMEA output from the modem is functioning.

  • GNSS engine is running.

  • No position is available.

  • No satellites are used.

  • No GNSS UTC time is available.

  • After the controlled cold start described below, no GSV sentences were observed in the continuous USB NMEA stream during the tested intervals.

This behavior also occurs independently of gpsd because it was observed by reading the modem’s USB NMEA interface directly.

5. Controlled GNSS Cold Start

A significant issue was discovered during earlier cold-start attempts.

Initially:

AT+QGPSEND
OK

but:

AT+QGPSDEL=0
+CME ERROR: Session is ongoing

and:

AT+QGPS?
+QGPS: 1

RutOS was apparently restarting or maintaining the GNSS session.

GNSS was then stopped through RutOS:

ubus call gsm.modem0 gnss_stop

Result:

{
    "status_id": 0,
    "status": "OK"
}

AT+QGPS? then returned:

+QGPS: 0

However, QGPSDEL=0 still initially returned:

+CME ERROR: Session is ongoing

It was then discovered that gpsd was still running.

After:

/etc/init.d/gpsd stop

gpsd was confirmed to be terminated.

With:

  • gpsd stopped

  • GNSS engine stopped (QGPS: 0)

the following finally succeeded:

AT+QGPSDEL=0
OK

This was the first confirmed clean QGPSDEL=0.

GNSS was subsequently restarted.

The clean cold start did not restore GNSS operation.

6. Full Modem Reset

As a separate test, the RG501Q modem itself was reset using:

gsmctl -Q

The modem rebooted successfully.

After the modem reboot, GNSS was initially off:

+QGPS: 0

gpsd was also not running because it had previously been intentionally stopped during diagnostics.

Normal RutOS GNSS operation was restored using:

/etc/init.d/gpsd start

The receiver was then allowed approximately 10–15 minutes under unobstructed sky conditions.

Afterwards:

AT+QGPSLOC=2

still returned:

+CME ERROR: Not fixed now

Therefore, a full RG501Q modem reset also did not resolve the problem.

7. GNSS Configuration Checked

The RG501Q itself reports the supported QGPSCFG parameters, including:

"outport"
"nmeasrc"
"gpsnmeatype"
"glonassnmeatype"
"galileonmeatype"
"beidounmeatype"
"gnssconfig"
"autogps"
"dpoenable"
"plane"
"suplver"
"agpsposmode"
"agnssprotocol"
"multibandconfig"

Relevant measured values:

AT+QGPSCFG="outport"
"outport",usbnmea

AT+QGPSCFG="gnssconfig"
"gnssconfig",1

AT+QGPSCFG="multibandconfig"
"multibandconfig",7

AT+QGPSCFG="dpoenable"
"dpoenable",0

AT+QGPSCFG="nmeasrc"
"nmeasrc",1

AT+QGPSCFG="plane"
"plane",1

AT+QGPSCFG="gpsnmeatype"
"gpsnmeatype",31

AT+QGPSCFG="galileonmeatype"
"galileonmeatype",31

AT+QGPSCFG="autogps"
"autogps",0

No changes were made to these parameters during this diagnostic sequence.

The supported QGPSGNMEA types were also queried:

AT+QGPSGNMEA=?

+QGPSGNMEA: ("GGA","RMC","GSV","GSA","VTG","GNS")

8. XTRA / Assistance Data

Query:

AT+QGPSXTRADATA?

returned:

+QGPSXTRADATA: 0,"1980/01/06,00:00:00"

Therefore, no valid XTRA data is currently available.

However, this alone would not normally explain a permanent inability to obtain an autonomous GNSS fix under unobstructed sky conditions.

9. RutOS / gpsd

RutOS GPS configuration was inspected and GPS was enabled.

gpsd runs under procd and communicates with the modem GNSS subsystem.

ubus call gpsd position repeatedly returned only zero values, including:

utc_timestamp: 0
longitude: 0
latitude: 0
satellites: 0
fix_status: 0
constellation: ""

This is consistent with the raw NMEA observations.

ubus call gpsd nmea_status returned:

{
    "hosts": [],
    "serials": []
}

This result was not treated as proof of a fault because the exact semantics of this RutOS API response are unclear.

The generic modem UBUS interface exposes GNSS-related methods, but not every listed method appears to be supported by this RG501Q implementation. For example:

ubus call gsm.modem0 get_gnss_state

returned:

Command failed: Operation not supported

10. WWAN / GNSS Conflict

RutOS modem status reported:

"wwan_gnss_conflict": false

The cellular modem otherwise operates normally.

Example operating conditions during investigation:

state: Connected
operator: Telekom.de
LTE
RSRP: approximately -53 dBm
SINR: approximately 30 dB
temperature: approximately 38 °C

No RutOS-detected WWAN/GNSS conflict is present.

11. Current Assessment

At this point, the following have been demonstrated:

  1. GNSS previously worked on this hardware.

  2. The GNSS engine can still be started and reports QGPS: 1.

  3. The modem produces continuous NMEA output.

  4. The failure exists below the gpsd/AVL application layer because invalid GNSS data is observed directly on the modem’s USB NMEA interface.

  5. There is no position fix.

  6. There is no GNSS UTC time.

  7. GSA remains mode 1 with no satellites used.

  8. Earlier GSV output contained satellite geometry but C/N0 was empty for all satellites.

  9. After a confirmed clean QGPSDEL=0, no recovery occurred.

  10. A complete RG501Q modem reset did not restore GNSS operation.

  11. Approximately 10–15 minutes under unobstructed sky after the modem reset still resulted in Not fixed now.

  12. No obvious change has been identified in the checked GNSS configuration parameters.

  13. RutOS reports no WWAN/GNSS conflict.

The current working hypothesis is therefore that the problem is closer to the GNSS RF acquisition path or the RG501Q GNSS subsystem itself, rather than Traccar, AVL, gpsd, or ordinary GNSS assistance data.

This is still a hypothesis, not a confirmed hardware diagnosis.

12. Planned Next Test

The next planned diagnostic step is an antenna A/B test.

A separate known-good GNSS antenna will be connected directly to the router’s GNSS antenna connector, with clear sky visibility.

No GNSS configuration changes are planned before this test so that the current state remains a clean baseline.

If the alternative antenna immediately produces C/N0 values / satellite tracking / GNSS time, the external antenna/cable/RF path becomes the primary suspect.

If the behavior remains unchanged with a known-good antenna directly connected to the router, attention should shift toward the RUTX50 internal GNSS RF path or the RG501Q GNSS subsystem.

13. Questions for Teltonika Engineering

We would particularly appreciate clarification on the following:

  1. Are there any RUTX50 / RG501Q-EU specific diagnostic commands available to inspect GNSS RF acquisition, antenna status, LNA/bias status, baseband tracking, or C/N0 independently of standard NMEA output?

  2. Is the observed condition known on the RG501Q-EU where the GNSS engine remains running (QGPS: 1) but produces no UTC time, no tracked satellites and no C/N0?

  3. Does the RUTX50 provide active GNSS antenna bias power, and is there a supported method to verify its voltage/current or detect an antenna open/short condition from software?

  4. Are there additional Teltonika-specific modem initialization commands or configuration files that influence the RG501Q GNSS RF path but are not visible through /etc/config/gps or the standard QGPSCFG parameters?

  5. Is there any known interaction between AVL/GPS service reconfiguration and the RG501Q GNSS initialization sequence that could persist across Router reboots?

  6. Are the reported values

gnssconfig=1
multibandconfig=7
nmeasrc=1
gpsnmeatype=31
galileonmeatype=31
dpoenable=0
autogps=0

the expected values for an RUTX50 with GPS + Galileo enabled?

  1. If the known-good antenna test produces the same result, what would Teltonika recommend as the next diagnostic step before considering the router/modem hardware defective?