Spec2Skill preview NTRIP Caster
draft

Lesson 7 of 7

OUT-NTRIP-001OUT-NTRIP-002OUT-NTRIP-003OUT-NTRIP-004OUT-NTRIP-005OUT-NTRIP-006OUT-NTRIP-007 180 minutes draft

Final practical assessment

Status: Draft

Purpose

Demonstrate that you can explain, install, configure, deploy, publish, use, and troubleshoot the NTRIP caster in an isolated environment.

Learning objectives

This assessment measures all seven course outcomes. You must work from the approved project documentation and standard tool references. You must not use a completed assessment solution.

Prerequisites

Complete Lessons 1 to 6. The assessor must provide:

  • a clean project workspace
  • an isolated Linux host
  • approved SSH access
  • a sanitised configuration template
  • a compatible receiver or approved RTCM test data
  • an approved NTRIP client
  • one controlled fault scenario

Key terms

  • Assessment environment: The isolated systems used for this assessment.
  • Mandatory condition: A condition that must pass regardless of the numeric score.
  • Evidence bundle: The complete, redacted set of assessment records.
  • Observed practical: A task witnessed by an assessor or verified through trusted system evidence.

Concept explanation

The assessment follows the same data path used by the course:

installation
    -> safe configuration
    -> managed deployment
    -> confirmed input
    -> valid current stream
    -> authorised client
    -> fault diagnosis

Each boundary must have evidence. Success at a later boundary does not remove the need to check an earlier one.

The hardware and test-data pathways assess the same software outcomes. Test data does not prove physical antenna placement, receiver survey quality, or field position accuracy. State the pathway in the evidence bundle.

Worked demonstration

No completed system demonstration is provided during the assessment. The assessor demonstrates only how to prepare evidence:

  1. Replace usernames, passwords, hostnames, addresses, coordinates, and device paths with approved labels.
  2. Keep command names, status values, and relevant safe log messages.
  3. Record the time and assessment stage.
  4. Link each evidence item to one outcome.

Expected result: evidence remains technically useful without exposing private or reusable values.

Guided practice

Before the assessment starts, review this readiness checklist:

  • all required resources are present
  • the host can be restored
  • the course network is isolated
  • credentials are temporary
  • fixed coordinates are approved or survey-in is selected
  • the assessor knows which fault will be introduced
  • evidence storage is ready

The assessor may correct the assessment environment. The assessor must not complete the learner task.

Independent practice

Complete these stages:

Stage 1: explain

Draw the end-to-end data flow. Explain every component boundary.

Stage 2: install

Prepare a clean environment. Install the pinned dependencies. Run the complete test suite.

Stage 3: configure

Complete the sanitised template. Select survey-in or an approved fixed position. Explain the listener, authentication, stream, logging, RTCM, and monitor choices.

Stage 4: deploy

Transfer the application. Prepare the target runtime. Install and start the reviewed service. Demonstrate stop, start, status, and log inspection.

Stage 5: publish

Confirm receiver mode or state the test-data limitation. Verify valid RTCM flow, the sourcetable entry, mountpoint availability, continuity, and freshness.

Stage 6: connect

Connect the approved client. Demonstrate continuing data receipt. State what the result does and does not prove.

Stage 7: troubleshoot

Diagnose the supplied fault. Record ordered observations, the failed boundary, the corrective action, and the restored result.

Checks for understanding

Before submission, confirm:

  1. Can every evidence item be linked to an outcome?
  2. Are all secrets and private site values removed?
  3. Is the receiver mode confirmed or the test-data limitation stated?
  4. Is stream receipt kept separate from rover position quality?
  5. Does the fault record show observations before changes?

Assessment and evidence

Submit:

  • annotated data-flow diagram
  • Python and dependency installation record
  • passing test summary
  • sanitised configuration
  • reviewed service status
  • redacted receiver-mode log
  • sourcetable, continuity, and freshness evidence
  • redacted client receipt evidence
  • fault diagnosis record
  • practice pathway declaration

The pass mark is 70 percent. These conditions are mandatory:

  • no secret or private site value is submitted
  • no unconfirmed base position is presented as valid
  • the caster is not exposed directly to an untrusted network
  • the caster is not described as the rover position calculator

Troubleshooting guidance

Use the boundary order. Do not make several changes at once.

BoundaryEvidence
InstallationEnvironment and test result.
ConfigurationParsed values and safety review.
ServiceStatus and first relevant journal error.
ReceiverSerial open and time-mode acknowledgement.
RTCMComplete valid frames and freshness.
CasterSourcetable, mountpoint, and authorisation response.
ClientReachability, profile, and continued receipt.

Summary

The final assessment requires an end-to-end working system and clear evidence at every boundary. Technical success does not override safety, privacy, or evidence requirements.

Source references

  • SRC-PROJECT-OVERVIEW: project operation and safety requirements
  • SRC-PROJECT-CODE: implemented application behaviour
  • SRC-PROJECT-TESTS: automated verification scope
  • SRC-NTRIP-CONCEPT: general NTRIP context
  • SRC-RTCM-CONCEPT: general RTCM context
  • SRC-RECEIVER-GUIDANCE: receiver context; exact vendor revision remains unresolved