mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-07-24 15:27:41 +08:00
90913df7de
* feat(gps): inject SPARTN corrections alongside RTCM Add a SPARTN transport-layer framer and feed gps_inject_data through both RTCM3 and SPARTN parsers so PointPerfect-style SPARTN streams can be reassembled and written to the receiver the same way RTCM already is. Gated by CONFIG_GPS_SPARTN (default on). Disabled on px4_fmu-v6x where flash is already at the limit; enabled on ark_can-rtk-gps. Depends on PX4-GPSDrivers for automatic u-blox SPARTN input enable. Signed-off-by: alexklimaj <alex@arkelectron.com> * fix(gnss): avoid undefined shift in SPARTN CRC-32 Use uint64_t for the CRC working register so n==32 does not perform 1u << 32 (clang-analyzer BitwiseShift). Signed-off-by: alexklimaj <alex@arkelectron.com> * make format * feat(gps): enable SPARTN support in board configurations * feat(gps): enhance SPARTN support with additional frame tracking and status reporting * fix(gps): frame RTCM3 and SPARTN from a single buffer Feeding every inject chunk to an independent framer per protocol let each one resync inside the other's payloads. That is not symmetric: RTCM3 is covered by CRC-24Q, but SPARTN's header carries no usable integrity check (TF006 is 4 bits over a non-byte-aligned field) and TF005 permits an 8-bit message CRC, so a stray 0x73 in an RTCM3 payload is framed as SPARTN at roughly 1 in 1024. RTCM3-only is what every board actually runs, and over 50 MB of it the two framers produced 211 bogus SPARTN frames (210 declaring CRC-8), each re-injecting up to 1 kB of the stream back into the receiver. The reverse direction produced none. Frame both protocols from one buffer instead: whichever preamble comes first is framed, and a valid frame consumes its own payload, so bytes inside one protocol's frame never start the other's. The same 50 MB now yields zero. Frames are also injected in arrival order rather than all RTCM3 then all SPARTN, and one buffer replaces two (2248 B/instance, down from ~4350 B). Also reject TF002 message types 5-119, which SPARTN reserves, as the one header field with a checkable range. CONFIG_GPS_SPARTN was default y, so it built into every target with a GPS including px4_fmu-v6x, which the flash report showed gaining the framer despite the intent to keep it off. Default it to n and enable it explicitly where it is wanted; the ark GPS boards already opt in, and SITL opts in so the framing tests keep running in CI. Rtcm3Parser and SpartnParser are replaced by CorrectionFramer; their tests carry over to it. RtcmStress fed "garbage" drawn from 0x01-0xD2 to avoid a preamble, which includes 0x73, and RtcmBustedSender ended its stream on a candidate the framer was still waiting to complete; both now avoid every preamble and flush respectively. * feat(gps): enable SPARTN on ARK flight controllers Covers receivers attached over UART rather than CAN. All four targets link with margin; fmu-v6xrt has no px4board on this branch yet. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> --------- Signed-off-by: alexklimaj <alex@arkelectron.com> Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>