The message-output model in gpsprot.ConfigOptions treats NMEA and the native PVT/satellite messages as independent axes, on the assumption that a receiver's native messages are a separate protocol from NMEA (u-blox UBX, Septentrio SBF): disabling NMEA and enabling native PVT are orthogonal, on different wires. The Quectel LG290P is the first receiver whose native messages are NMEA - PQTMPVT and friends are NMEA sentences, and the only satellite carrier is the standard GSV sentence - and they share the one NMEA output protocol. Clearing that protocol silences the native messages too, and NMEAMsg and SatsMsg can name the same physical GSV sentence, so the axes are no longer independent. The immediate symptom is a latent bug: satpulsed always sets NMEAMsg=None plus PVTMsg, which on such a receiver would darken the NMEA protocol and starve the PVT messages it needs.
The proposed direction is a two-level model: message output is controlled at the low (per-message NMEA sentence) level via NMEAMsg, or at the semantic level via PVTMsg/SatsMsg, but the two cannot be mixed. nmea-out none is the neutral value allowed alongside the semantic level, where it means "native" (emit only the requested native carriers). A new ConfigSupportNativeNMEA descriptor flag marks the receivers where mixing is an error; elsewhere the axes address different messages and combine as they do today. There is no struct change to ConfigOptions - this is a semantics refinement plus one flag.
Affected areas:
- gpsprot:
ConfigSupportNativeNMEA descriptor flag (excluded from ConfigSupportFull, appended to the flag table, never reordering existing bits).
- Quectel backend: the two-level protocol-bit algorithm and do-nothing on a mixed request; fixes the daemon starvation bug above. Lands first, needs no flag.
- satpulsetool: reject a mixed request (explicit
--nmea-out sentences with --pvt-out/--sats-out) on a native-NMEA receiver.
- satpulsed: unaffected - it already operates at the semantic level.
- Workbench UI: mutually exclude the NMEA sentence controls and the PVT/Sats groups, folded into the config-support-gating work.
- gpshwtest: keep the message-output probes single-level, adapt the leave-as-found restore for a mixed as-found table, and record the flag in the baseline.
Needed for #350.
See plan/native-nmea.md.
The message-output model in
gpsprot.ConfigOptionstreats NMEA and the native PVT/satellite messages as independent axes, on the assumption that a receiver's native messages are a separate protocol from NMEA (u-blox UBX, Septentrio SBF): disabling NMEA and enabling native PVT are orthogonal, on different wires. The Quectel LG290P is the first receiver whose native messages are NMEA - PQTMPVT and friends are NMEA sentences, and the only satellite carrier is the standard GSV sentence - and they share the one NMEA output protocol. Clearing that protocol silences the native messages too, and NMEAMsg and SatsMsg can name the same physical GSV sentence, so the axes are no longer independent. The immediate symptom is a latent bug: satpulsed always sets NMEAMsg=None plus PVTMsg, which on such a receiver would darken the NMEA protocol and starve the PVT messages it needs.The proposed direction is a two-level model: message output is controlled at the low (per-message NMEA sentence) level via NMEAMsg, or at the semantic level via PVTMsg/SatsMsg, but the two cannot be mixed.
nmea-out noneis the neutral value allowed alongside the semantic level, where it means "native" (emit only the requested native carriers). A newConfigSupportNativeNMEAdescriptor flag marks the receivers where mixing is an error; elsewhere the axes address different messages and combine as they do today. There is no struct change toConfigOptions- this is a semantics refinement plus one flag.Affected areas:
ConfigSupportNativeNMEAdescriptor flag (excluded fromConfigSupportFull, appended to the flag table, never reordering existing bits).--nmea-outsentences with--pvt-out/--sats-out) on a native-NMEA receiver.Needed for #350.
See
plan/native-nmea.md.