Publish and verify correction data

Status: Draft

Purpose

Start the caster with approved input. Verify that confirmed, valid, and current RTCM data is available through the configured mountpoint.

Learning objectives

After this lesson, you can:

1. Confirm the receiver time mode before publication.
2. Explain RTCM frame completion and CRC checks.
3. Request and interpret the project sourcetable.
4. Verify stream continuity and freshness.
5. Diagnose a fault between receiver input and mountpoint output.

Prerequisites

Complete Lessons 1 to 4. Use either a compatible receiver or approved RTCM test data. Keep the service on the isolated course network.

Key terms

• Preamble: The byte pattern that starts an RTCM 3 frame.
• Payload: The message data inside a frame.
• CRC: An integrity value used to detect a damaged frame.
• Frame continuity: Continued receipt of complete frames over time.
• Freshness: The age of the most recently observed stream data.
• Receiver time mode: Confirmed fixed or survey-in base operation.

Concept explanation

Receiver confirmation

The application configures the receiver after every serial connection. It sends a receiver command and waits for acknowledgement. If the receiver rejects the command or does not answer, the caster closes the serial connection and retries. It does not serve an unconfirmed base position.

RTCM framing

A serial read can contain part of one frame, one complete frame, or several frames. The framer keeps incomplete bytes, finds the declared frame length, and checks the CRC. It discards invalid frames. It publishes valid frames without changing their payload.

The configured sourcetable description can list message types such as station position, multi-signal observations, and GLONASS bias information. The lesson does not require detailed decoding of observation fields.

Stream publication

A request for / returns the sourcetable. A request for the configured mountpoint starts the stream after any required Basic authentication.

The sourcetable uses configured latitude and longitude in fixed mode. It uses 0.00 values during survey-in. Do not interpret survey-in sourcetable values as the final antenna position.

Publication evidence

One client connection is not enough evidence. Check these boundaries:

1. serial device opened
2. receiver mode acknowledged
3. valid RTCM frames observed
4. configured mountpoint advertised
5. current bytes received from the mountpoint
6. monitor reports a current stream

Worked demonstration

1. Start the course service.
2. Read the service log until the receiver mode is confirmed.
3. Request the sourcetable from the caster root.
4. Confirm the configured mountpoint and RTCM description.
5. Connect the approved local monitor or test client.
6. Observe continuing frame receipt.
7. Stop the input in the controlled exercise.
8. Confirm that the freshness or stale-stream warning changes.
9. Restore the input.

Expected result: only valid frames reach the mountpoint, and stopped input is visible as a freshness problem.

Guided practice

Use the hardware or test-data pathway.

1. Record which pathway is used.
2. Confirm service state.
3. Confirm receiver mode or identify the test-data limitation.
4. Record observed RTCM message identities without copying payload data.
5. Confirm the sourcetable entry.
6. Measure stream continuity for the instructor-defined period.
7. Record the most recent stream age.

Test data can prove framing and distribution. It cannot prove physical antenna placement or receiver survey quality.

Independent practice

Diagnose one instructor-supplied fault:

• wrong serial path
• missing serial permission
• receiver acknowledgement timeout
• damaged test frame
• wrong mountpoint
• stopped or stale input

Check one boundary at a time. Do not change unrelated settings.

Checks for understanding

1. Why must incomplete bytes remain in the framer buffer?
2. What happens to a frame with an invalid CRC?
3. Why must receiver mode be confirmed before publication?
4. What position appears in the sourcetable during survey-in?
5. What is the difference between a disconnected client and stale source data?

Assessment and evidence

Publish the course stream and submit:

• redacted receiver-mode evidence
• sourcetable entry
• continuity and freshness result
• identified practice pathway
• one fault diagnosis record

Troubleshooting guidance

Summary

A publishable stream needs a confirmed receiver mode, valid frames, a correct mountpoint, and current data. Verify each boundary. Do not treat successful test data as proof of a physical base installation.

Source references

• SRC-PROJECT-OVERVIEW: receiver confirmation, sourcetable, and stream behaviour
• SRC-PROJECT-CODE: RTCM framing, CRC, caster request, and health behaviour
• SRC-PROJECT-TESTS: tested framing and monitoring behaviour
• SRC-RTCM-CONCEPT: general RTCM context
• SRC-RECEIVER-GUIDANCE: receiver context; exact vendor revision remains unresolved