What is the bug or the crash? What were your expectations and what actually happened?
Position indicator (and precision dot) freezes silently on external GNSS (TCP) disconnect — but recording is correctly blocked
Steps to reproduce the issue
QField 4.2.4
iOS 18.6.2 (iPhone)
External GNSS receiver connected via TCP over WiFi (u-blox ZED-X20P based board, NMEA stream on a local socket server), not Bluetooth.
Positioning source: external device, configured under Settings > Positioning.
Steps to reproduce
Connect to the external GNSS receiver via TCP. Confirm normal behavior: the status dot on the GNSS button goes through "no connection" → red → yellow → green as the fix quality improves.
Let the connection drop silently (e.g. walk out of WiFi range, or the receiver's WiFi link hiccups) — not a clean disconnect from within QField.
Observe the map position and the status dot on the GNSS button.
Try to record a point.
Expected behavior
Some visible indication that the position/fix is stale (indicator turns grey, disappears, shows an age/timestamp, a warning banner, anything).
Version
QField 4.2.4
Operating system name
iOS
Operating system version
iOS 18.6.2 (iPhone)
Reinstall QField
Additional context
Actual behavior
The map position and the status dot both stay frozen at the last known good state, with no visual indication whatsoever that the connection was lost.
However, attempting to record a point is correctly blocked — so QField clearly can detect that the current fix is not usable, but this check doesn't seem to also drive the passive visual indicators.
Why this matters
For stakeout/setting-out work (walking to a specific coordinate to physically mark it), a frozen-but-displayed-as-live position is actively dangerous — a user can mark the wrong physical location without any on-screen warning, unless they happen to also try recording a point (which is correctly blocked) or independently check the receiver's own hardware LED.
Suspected cause
This may be a TCP-specific issue: a silently dropped TCP connection (no clean FIN/RST) is not reliably reported by the socket layer without an active keepalive/timeout — this is a well-known general TCP limitation, not necessarily QField-specific. If the position/status-dot UI only updates reactively when a new NMEA sentence arrives (rather than being re-evaluated on a timer against "time since last fix"), it would explain why it freezes indefinitely instead of going stale — while the recording action, which apparently does check fix freshness at the moment of the tap, works correctly.
Suggested fix
Reuse whatever freshness/age check already gates point recording to also periodically re-evaluate and update the passive position/status-dot indicator (e.g. every 1-2s), independent of whether new NMEA data has arrived.
What is the bug or the crash? What were your expectations and what actually happened?
Position indicator (and precision dot) freezes silently on external GNSS (TCP) disconnect — but recording is correctly blocked
Steps to reproduce the issue
QField 4.2.4
iOS 18.6.2 (iPhone)
External GNSS receiver connected via TCP over WiFi (u-blox ZED-X20P based board, NMEA stream on a local socket server), not Bluetooth.
Positioning source: external device, configured under Settings > Positioning.
Steps to reproduce
Connect to the external GNSS receiver via TCP. Confirm normal behavior: the status dot on the GNSS button goes through "no connection" → red → yellow → green as the fix quality improves.
Let the connection drop silently (e.g. walk out of WiFi range, or the receiver's WiFi link hiccups) — not a clean disconnect from within QField.
Observe the map position and the status dot on the GNSS button.
Try to record a point.
Expected behavior
Some visible indication that the position/fix is stale (indicator turns grey, disappears, shows an age/timestamp, a warning banner, anything).
Version
QField 4.2.4
Operating system name
iOS
Operating system version
iOS 18.6.2 (iPhone)
Reinstall QField
Additional context
Actual behavior
The map position and the status dot both stay frozen at the last known good state, with no visual indication whatsoever that the connection was lost.
However, attempting to record a point is correctly blocked — so QField clearly can detect that the current fix is not usable, but this check doesn't seem to also drive the passive visual indicators.
Why this matters
For stakeout/setting-out work (walking to a specific coordinate to physically mark it), a frozen-but-displayed-as-live position is actively dangerous — a user can mark the wrong physical location without any on-screen warning, unless they happen to also try recording a point (which is correctly blocked) or independently check the receiver's own hardware LED.
Suspected cause
This may be a TCP-specific issue: a silently dropped TCP connection (no clean FIN/RST) is not reliably reported by the socket layer without an active keepalive/timeout — this is a well-known general TCP limitation, not necessarily QField-specific. If the position/status-dot UI only updates reactively when a new NMEA sentence arrives (rather than being re-evaluated on a timer against "time since last fix"), it would explain why it freezes indefinitely instead of going stale — while the recording action, which apparently does check fix freshness at the moment of the tap, works correctly.
Suggested fix
Reuse whatever freshness/age check already gates point recording to also periodically re-evaluate and update the passive position/status-dot indicator (e.g. every 1-2s), independent of whether new NMEA data has arrived.