Fast SVIN¶

Fast-SVIN mode accelerates the survey-in process by feeding RTK or PPP corrections to the GNSS receiver.

Overview¶

Standard survey-in can take several minutes to achieve centimeter-level accuracy. Fast SVIN reduces this to approximately 90 seconds by utilizing correction data from nearby reference stations.

How It Works¶

Standard vs Fast SVIN¶

Technical Principle¶

Fast SVIN combines: 1. Standard survey-in procedure: The ZED module performs normal position averaging 2. RTCM corrections: Incoming corrections refine position estimates 3. Accelerated convergence: Corrections reduce initialization time

Sequence¶

1. Query Request¶

The RTK Base emits an MQTT query to find nearby correction sources:

Topic: base/{SN}/query/rtcm/req

Payload: lat=LAT,lon=LON

• LAT: Latest coarse latitude
• LON: Latest coarse longitude
• LON: Latest coarse longitude

2. Response from NTRIP Forwarders¶

Any available NTRIP forwarders respond with:

Topic: base/{SN}/query/rtcm/resp

Payload: topic=RTCM_TOPIC,keepalive=KA_TOPIC,dist=DISTANCE,prio=PRIO

Fields:

• RTCM_TOPIC: Topic to subscribe for RTCM data
• KA_TOPIC: Topic for sending keep-alive messages
• DISTANCE: Distance from remote station (informational)
• PRIO: Station priority (lower is better)

3. Station Selection¶

10 seconds after the initial query: - RTK Base evaluates all responses - Selects station with highest priority (lowest PRIO number) - Remembers only the selected station

4. Keep-Alive and RTCM Reception¶

• Sends keep-alive messages to selected station only
• Subscribes to RTCM_TOPIC for correction data
• Injects RTCM data into GPS receiver

5. Timeout and Retry¶

If no RTCM received for 60 seconds: - RTK Base restarts the query process - Searches for alternative correction sources

Sequence Diagrams¶

Standard Fast SVIN Flow¶

sequenceDiagram
    participant Base as RTK Base
    participant MQTT as MQTT Broker
    participant Forwarder as NTRIP Forwarder
    participant ZED as ZED-F9P GNSS

    Base->>MQTT: Publish query<br/>base/{SN}/query/rtcm/req<br/>lat=XX.XX,lon=XX.XX
    MQTT->>Forwarder: Broadcast query
    Forwarder->>MQTT: Publish response<br/>base/{SN}/query/rtcm/resp<br/>topic=...,prio=N,dist=XX
    MQTT->>Base: Deliver response

    Note over Base: Wait 10 seconds for all responses

    Base->>Base: Select best priority (lowest number)

    alt Best response found
        Base->>MQTT: Subscribe to RTCM topic
        loop Every 20 seconds
            Base->>MQTT: Publish keep-alive
        end
        MQTT->>Base: RTCM correction data
        Base->>ZED: Inject RTCM via UART
    else No valid response
        Base->>Base: Retry after timeout
    end

Timeout and Retry Flow¶

sequenceDiagram
    participant Base as RTK Base
    participant MQTT as MQTT Broker

    Note over Base: RTCM query in progress

    alt No RTCM for 60 seconds
        Base->>Base: Clear current RTCM config
        Base->>MQTT: Re-send query<br/>base/{SN}/query/rtcm/req
        Note over Base: Wait for new responses
    end

PointPerfect Integration¶

For PPP (Precise Point Positioning) correction data, the RTK Base can receive RTCM streams from u-blox PointPerfect service via MQTT.

Architecture¶

PointPerfect corrections are delivered through an intermediate MQTT bridge that:

1. Connects to u-blox ThingStream API
2. Forwards RTCM data to the RTK Base's MQTT subscription
3. Handles keep-alive and connection management

Implementation¶

See the PointPerfect to MQTT Bridge repository for the reference implementation.

This service bridges PointPerfect NTRIP/MQTT streams to the RTK Base's expected MQTT format, enabling Fast SVIN with continental-scale PPP corrections.

Configuration¶

When using PointPerfect:

• Set appropriate priority value in forwarder configuration (typically lower/higher number for PPP vs RTK)
• Ensure MQTT credentials for PointPerfect broker are configured
• Configure keep-alive interval (default: 20 seconds)
• PPP corrections provide <50cm accuracy globally, independent of local base stations

Configuration¶

Survey-in Parameters¶

{
  "gnss-survey-mintime": 90,
  "gnss-survey-maxtime": 540,
  "gnss-survey-accuracy": 1.0,
  "gnss-survey-accuracy-corr": 0.5
}

Parameters:

• mintime: Minimum survey time (seconds)
• maxtime: Maximum survey time (seconds) - timeout
• accuracy: Target accuracy without corrections (meters)
• accuracy-corr: Target accuracy with corrections (meters)

API Commands¶

Start Fast SVIN:

curl 192.168.4.1/change \
  --data '{"gnss-survey-mintime":90,"trigger-gnss-survey":true}'

Or via MQTT:

Topic: base/{SN}/change/post
Payload: {"gnss-survey-mintime":90,"trigger-gnss-survey":true}

UI Integration¶

v4.0 Unification¶

Fast SVIN and Standard SVIN now share the same UI:

• Single "Start Survey-in" button
• Automatic detection of correction availability
• Progress indicator shows estimated time
• High Precision (HP) bit managed automatically

Display Information¶

During Fast SVIN, the web interface shows:

• Elapsed time
• Current accuracy
• Correction source (if available)
• Distance to reference station
• Estimated completion time

Failover and Redundancy¶

Multiple NTRIP Forwarders¶

Several NTRIP forwarders can operate in parallel: - RTK Base selects only one based on priority - Automatic failover if selected station fails - Priority can be adjusted per forwarder

Priority Management¶

System administrators can influence selection: - RTK stations: Priority proportional to distance - PPP stations: Fixed priority number - Scaling: Adjust PRIO values as needed

Custom Forwarder Service¶

Example implementation: 1. Collects all active RTKBases 2. Responds to queries with aggregated info 3. After selection, bases communicate directly 4. No further server intervention needed

Performance¶

Typical Results¶

Factors Affecting Performance¶

Positive:

• Nearby reference station (<50km)
• Good sky visibility
• Strong cellular/WiFi connection
• High-quality antenna

Negative:

• Remote location (>100km from stations)
• Urban canyon/multipath
• Poor network connectivity
• Antenna obstructions

Migration from v3.x¶

Automatic Migration¶

When upgrading from v3.x to v4.x:

1. System detects v3 reference position
2. Performs Fast SVIN automatically
3. Calculates delta between positions
4. Stores both position and delta
5. Preserves Low Precision mode

Delta Management¶

Delta Check at Startup: - With corrections: 0.5m threshold (improved safety) - Without corrections: 7m threshold (as before)

HP Bit Control: - Remains OFF during migration - Can be manually enabled after restore - Automatically enabled for new Fast SVIN

Troubleshooting¶

Fast SVIN Not Starting¶

Symptoms: Survey takes >180 seconds

Checks: 1. Verify MQTT connection is active 2. Check for correction sources in area 3. Confirm network connectivity 4. Review logs for query/response messages

Incomplete Fast SVIN¶

Symptoms: Survey times out or accuracy insufficient

Solutions:

• Extend maxtime parameter
• Check for RTCM data reception
• Verify antenna has clear sky view
• Try standard SVIN as fallback

Correction Data Stops¶

Symptoms: Survey stalls after partial completion

Actions:

• System will retry query after 60 seconds
• Check correction source availability
• Verify keep-alive messages are sent
• Review MQTT connection stability

References¶

• REST API - Configuration endpoints
• MQTT API - RTCM query topics
• Architecture - ZED state machine
• Release Notes - v4.0.0 migration details