I have problems with the GPS. Sometimes the NMEA streams becomes empty (nothing received) and I can’t figure out why. Most of the times it works properly.
My current firmware version is EC25AFXGAR07A03M1G.
Dear Customer,
Thanks for the details. Intermittent GNSS output that works most of the time and occasionally goes silent is usually a session/priority behaviour rather than a fix-quality problem, and there are a few things we can narrow down quickly.
First, one important clarification that determines the direction of debugging:
When it “goes empty,” do you see:
(a) zero bytes on the NMEA port (no sentences at all), or
(b) NMEA sentences still coming through but with empty position fields (e.g. $GPGGA with no lat/lon)?
Case (a) points to the GNSS session or port; case (b) points to signal/antenna/no-fix. Please confirm which one you observe.
In parallel, could you check the following configuration on the module and share the responses:
AT+QGPS? (is the session still ON when it goes empty?)
AT+QGPSCFG=“priority” (GNSS vs WWAN priority)
AT+QGPSCFG=“autogps”
AT+QGPSCFG=“outport”
AT+QGPSCFG=“gnssconfig”
AT+QGPSCFG=“gpsnmeatype”
A couple of first-pass checks you can try right away:
-
If the dropouts tend to happen during cellular data activity or in weak-signal areas, please set GNSS to priority and re-test:
AT+QGPSCFG=“priority”,0,1
With WWAN priority, the GNSS engine can be pre-empted during heavy cellular traffic, which produces exactly this kind of intermittent gap. -
Please confirm the NMEA output port is a dedicated port (not shared with the data/PPP path), and that your GNSS settings are saved (persist across reset).
Also helpful for us:
- Does the dropout correlate with anything (data session, handover, weak signal, vibration/movement, temperature)?
- Antenna type (active/passive, and how the LNA is powered) and your VBAT supply design brief VBAT dips during TX peaks can reset the GNSS engine and give this symptom.
- A capture at the moment it fails: the NMEA log plus AT+QGPS? issued right after it goes empty, so we can see whether the GNSS session is still active.
Once we know whether the session stays on when the stream goes empty, we can zero in on the cause. On the firmware side (your current build is EC25AFXGAR07A03M1G), we’ll also check whether a newer release addresses GNSS-stability behaviour, and advise if an update is worthwhile.
Best regards,
Fazrul Redzuan
Field Application Engineer, Quectel Wireless Solutions
(post deleted by author)
Thanks for your fast reply! What I observe is case a). I could not find a correlation with anything for certain, but it seems to happen in zones of weak 4G signal. Our antenna type is active. The problem didnt occur since my first post and I don’t have access to the module currently but I will follow up if I can get more details.
Thank you very much for your help 
Dear Customer,
That’s very useful confirming it’s case (a) (zero bytes, no sentences at all) together with the tendency to happen in weak-4G areas actually narrows this down nicely. It points to the module prioritizing the cellular side when the link is weak, at the expense of the GNSS engine. There are two mechanisms that produce exactly this symptom, and both fit a weak-signal correlation:
-
GNSS/WWAN priority pre-emption in a weak-4G zone the modem works much harder to hold the connection, and if WWAN has priority the GNSS engine is starved of RF time, so the NMEA output stops even though the session is still on.
-
TX-driven supply dip weak signal makes the module transmit at maximum power, which raises current peaks on VBAT. If the supply dips during those peaks it can reset the GNSS engine (and, with an active antenna, briefly disturb the LNA supply).
Since the issue isn’t currently reproducing, I’d suggest two things:
A. Proactively set GNSS to priority and run with it for a while:
AT+QGPSCFG=“priority”,0,1
(Please first read back the current value with AT+QGPSCFG=“priority” so we know the starting point.) This gives GNSS precedence so it isn’t suspended during heavy cellular activity. There can be a small trade-off in WWAN throughput/latency while GNSS is active, which for most tracking use cases is acceptable, let me know if that’s a concern for your application.
B. Check the VBAT supply margin ideally confirm it holds up during transmit peaks in a weak-signal area (a scope on VBAT during a TX burst is ideal; otherwise just confirm the supply and decoupling are rated for the module’s peak current).
And for the next time it does occur, the single most useful capture is:
AT+QGPSGNMEA… (or your normal NMEA log) + AT+QGPS? issued right when the stream goes empty.
If AT+QGPS? returns 1 (session still on) it’s the priority/pre-emption path; if it returns 0 it’s a session/power reset. That one query tells us which of the two mechanisms it is.
No rush at all whenever you can get back to the module. In the meantime, if setting GNSS priority makes the dropouts disappear, that alone likely resolves it. I’ll also check on our side whether a newer firmware build improves GNSS behaviour under weak-signal conditions and let you know.
Best regards,
Fazrul Redzuan