rt-navi is a proof-of-concept that real-time application of our P.V.T solver is possible and gives correct results. To do that, we use a U-Blox GNSS receiver that we operate in "raw/manual" mode and serves mostly as a measurement system that we feed to the solver. The solver resolves does all the work and we eventually compare the manual performance to the firmware. We use U-Blox receivers because they are well documented, well supported and fully capable, that many not apply to other manufacturers.

rt-navi is not particularly tied to the receiver, if support for other ever become feasible, we may give it a try.

rt-navi expects a single serial interface and currently does operate with a single receiver.

This application is part of the Nav-solutions framework and is licensed under Mozilla V2 Public license.

rt-navi deploys PPP navigation (direct/absolute) by default. A RTK proof of concept will be developed in near future.

The PPP navigation mode is compatible with any U-Blox supporting the RAW messaging. RTK is feasible starting from F9P serie.

Install the latest release from the official portal:

cargo install rt-navi

Download our latest application and build it manually. rt-navi can then be cross-compiled but it requires the std library.

git clone https://github.com/nav-solutions/rt-navi
cargo build -r

rt-navi cannot be compiled with --all-features (currently).
We use features to select the U-Blox protocol revision, and you can only select one at a time. The default UBX protocol to be compiled is v23.

In this example, we switch to more recent protocol:

cargo build --no-default-features --ubx31

List of supported revisions:

• V14
• V23
• V27
• V31

Use -p,--port to specify the serial interface to the U-Blox.

rt-navi uses the $RUST_LOG environment variable to define its logging behavior. Use trace to unlock all traces.

RUST_LOG=debug rt-navi -p /dev/ttyACM0

[2025-05-11T09:31:21Z INFO  anise::almanac] Loading bytes as DAF/SPK
[2025-05-11T09:31:21Z DEBUG rt_navi] deployed with User {
        profile: Some(
            Pedestrian,
        ),
        clock_sigma_s: 0.001,
    } 

[...]
[2025-05-11T09:31:21Z DEBUG rt_navi] deployed with Config {
        timescale: GPST,
        method: SPP,
        user: User {
            profile: None,
            clock_sigma_s: 0.001,
        },

[...]
[2025-05-11T09:31:21Z INFO  rt_navi] solver deployed
[2025-05-11T09:31:21Z DEBUG rt_navi] deploying ublox..
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-RAWX
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-NAV-PVT
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-SFRBX
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-RATE
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-MON-VER
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] ublox: hw-version: 00080000, sw-version: EXT CORE 3.01 (111141) , extensions: ["ROM BASE 2.01 (75331)", "FWVER=TIM 1.10", "PROTVER=22.00", "MOD=NEO-M8T-0", "FIS=0xEF4015 (100111)", "GPS;GLO;GAL;BDS", "SBAS;IMES;QZSS"]

Soon the navigation messages gathering starts, and so does the measurement collection.
When both align and everything becomes feasible, the solver naturally consumes all of this data and we obtain a P.V.T:

rt-navi currently requires a U-Blox receiver to operate. We offer several compilation options to select the U-Blox protocol ("protocol" version being very important, because it actually defines which receiver you can operate!):

• ubx_proto23 v23 (Default, for M8 series)
• ubx_proto14 v14
• ubx_proto27 v27 (for F9 series)
• ubx_proto31 v31 (for newer series)

TODO

We offer a few options to specify initial x, y and z coordiates. This reduces the constraint to initial fix and make it easier to obtain. We recommend using this only if you have a rather good idea.

rt-navi -p /dev/ttyACM0 --coords-ecef-km=1000.0,2000.0,3000.0

rt-navi uses the combination of several major crates to achieve its objectives

• ANISE
• Hifitime
• Nyx-Space
• SP3
• GNSS-RTK
• UBlox