U-blox PointPerfect Flex now part of ARK-OS

ARK Electronics now offers u-blox PointPerfect Flex as part of ARK-OS, delivered straight to the flight controller over MAVLink by a small open source client that runs on the companion computer. Users can toggle the service on, enter their credentials, and receive RTK-grade positioning.

PPP-RTK minus the base station

With PPP-RTK, instead of broadcasting one station’s raw observations, u-blox models the error sources themselves — orbits, clocks, ionosphere, troposphere — across an entire continent using a network of reference stations. The user’s receiver applies that state-space model at its own position. The result is PPP’s coverage with RTK-style convergence and accuracy: u-blox quotes 3–6 cm with convergence typically in seconds, across the contiguous U.S., Europe and a growing list of other regions.

PointPerfect Flex corrections are delivered over IP using NTRIP — the service’s original MQTT delivery is no longer supported, and L-band satellite delivery arrives in the first quarter of 2027. The caster does the localization server-side: you report your position as standard NMEA-GGA sentences, and it returns a correction stream generated for right where you are, as if a virtual base station were parked next to your takeoff point. Because it’s plain NTRIP, it slots straight into the correction path every autopilot and RTK receiver already understands.

How the client works

Pointperfect-client-mavlink is a small C++ service that sits between the caster and the autopilot. On one side it opens a TLS connection to ppntrip.services.u-blox.com:2102 with the user’s service credentials. On the other it connects to the autopilot over MAVLink using MAVSDK. Then it does three things:

1. Pulls the vehicle’s position from GPS_RAW_INT telemetry.
2. Reports that position to the caster as an NMEA-GGA sentence every 10 seconds, so the corrections stay localized as the vehicle moves.
3. Forwards the correction stream to the autopilot as fragmented GPS_RTCM_DATA messages.

PX4 injects those bytes into the GNSS receiver — over serial, or over CAN for DroneCAN receivers like the ARK RTK GPS — the exact same path used when QGroundControl streams corrections from a survey-in base, so there is nothing to configure on the flight controller (see the PX4 RTK GPS docs). The receiver sees corrections, reports RTK float, then RTK fixed, and the autopilot’s position estimate tightens up accordingly.

Two correction formats are supported. rtcm pulls from the caster’s NEAR-RTCM mountpoint and works with any RTK-capable receiver, regardless of brand. spartn pulls NEAR-SPARTN instead — u-blox’s native correction format, and their recommendation on receivers that decode it, like the ZED-F9P and X20, for the best performance — with more gains coming in upcoming receiver firmware. Leave the mountpoint field blank and the client selects the right one automatically.

Built into ARK-OS

ARK-OS PR #102 wires the client in as an opt-in service, right alongside the existing polaris client for Point One’s corrections network — pick whichever provider fits your coverage area and your contract. The integration adds the system unit, a default config, and a dedicated mavlink-router UDP endpoint on port 14554.

Configuration happens in the web UI’s service editor. Out of the box, only two fields need attention — the PointPerfect Flex NTRIP username and password. Everything else ships with working defaults.

See more at the ARK-OS website.