issue-7133: add ntrip support

[KnightHawk06]

Add NTRIP/RTK support: caster auth, mountpoint, periodic GGA, RTCM/SPARTN ingest, MAVLink injection

Description

• Adds NTRIPManager to connect to casters (host/port/user/pass), send periodic $GPGGA, and forward RTCM to the vehicle via MAVLink gps_inject_data.
• New Settings -> NTRIP / RTK page with Facts: enable, host, port, username, password, mount point, whitelist, and SPARTN toggle.
• Supports RTCM over TCP (blank mount point) and NTRIP mountpoints; optional SPARTN pipeline (TLS/2102).
• GGA formatter outputs strict NMEA 0183 ddmm.mmmm / dddmm.mmmm with correct checksum and geoid separation of 0.0,M.
• Input field widths sized using textFieldPreferredWidth so the actual text boxes are wider and consistent.

Test Steps

1. Open Settings -> NTRIP / RTK and enable Connect to NTRIP server.
2. Enter Host, Port, Username, Password, Mount Point (blank means RTCM over TCP), and optional Whitelist.
3. (Optional) Enable SPARTN and set port to 2102 for SPARTN-capable receivers.
4. Observe status line: Connecting -> Connected or error text.
5. Verify gps_inject_data is emitted and rover receives RTCM (check vehicle GPS status).
6. Inspect a GGA sentence; confirm no spaces in lat/lon and checksum matches.
7. Negative tests: bad creds or mountpoint show readable errors; disabling NTRIP stops streaming.

Known Issues / Limitations

1. SPARTN path is wired but disabled, not yet tested end-to-end.

Test Environment

• Caster: Thingstream RTCM (https://portal.thingstream.io/)
• Receiver: u-blox F9P
• Autopilot: CubePilot Orange+
• Firmware: PX4 v1.14

Checklist:

• Review Contribution Guidelines.
• Review Code of Conduct.
• I have tested my changes.

Related Issue

Fixes #7133

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Copilot]

Pull Request Overview

This PR adds comprehensive NTRIP/RTK support to QGroundControl, enabling connection to NTRIP casters for real-time kinematic (RTK) positioning corrections. The implementation includes authentication, mountpoint selection, periodic GGA transmission, and RTCM/SPARTN data injection via MAVLink.

Key changes:

• Introduces NTRIPManager for caster connection management and RTCM/SPARTN data forwarding
• Adds new Settings → NTRIP/RTK configuration page with connection parameters
• Implements RTCM parser with message filtering and SPARTN pipeline support

Reviewed Changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/GPS/NTRIP.h/.cc	Core NTRIP implementation with TCP/TLS connectivity and RTCM/SPARTN parsing
src/Settings/NTRIPSettings.h/.cc	Settings group for NTRIP configuration parameters
src/UI/AppSettings/NTRIPSettings.qml	User interface for NTRIP settings configuration
src/FactSystem/	Bitmask overflow fixes and new UI controls
src/FirmwarePlugin/PX4/	Parameter metadata fixes for bit range validation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The registerQmlTypes() method is added but never called. This suggests the QML type registration may not be functioning as intended.

[KnightHawk06]

_ntripManagerRegisterQmlTypes() is actually called automatically by Q_COREAPP_STARTUP_FUNCTION once the Q(Core)Application is constructed.

[HTRamsey]

I've wanted to use Q_COREAPP_STARTUP_FUNCTION in the past but I believe the doc says not to use it unless you are dynamically linking a library or something right?

[HTRamsey]

Also, why not just use the QML_ELEMENT stuff?

[KnightHawk06]

I've wanted to use Q_COREAPP_STARTUP_FUNCTION in the past but I believe the doc says not to use it unless you are dynamically linking a library or something right?

I didn't see this in the doc, can you point me to it?

[KnightHawk06]

Also, why not just use the QML_ELEMENT stuff?

We need one NTRIPManager for the whole app that both C++ and QML can share.

With QML_ELEMENT/QML_SINGLETON, QML ends up managing its own instance (often one per engine), which doesn’t match that “single, app-wide” requirement.

We also need to control when the object is created so it attaches to the right parent (QGCApplication) and avoids being created during short-lived helper runs.

The current pattern (manual registration with a provider that returns NTRIPManager::instance()) guarantees a single, stable instance and consistent ownership across the app.

[HTRamsey]

Gotcha, for joystick manager we just used Q_APPLICATION_STATIC, QML_ELEMENT, and qmlEngine->rootContext()->setContextProperty(QStringLiteral("joystickManager"), JoystickManager::instance());.
You don't have to worry about creating multiple objects because the instance isn't created until it's actually referenced within the code. So the QCoreApplication doesn't actually create any of the singletons

[HTRamsey]

Doesn't look like you reference ntrip in cpp right? QML_SINGLETON should be fine because we only create the qmlengine once.

[HTRamsey]

Would be preferable if the NTRIP stuff was in a separate PR/commit from the metadata, CI, and fact system changes you did. And your added QML file should be part of a qml module in cmake.