Connect a client and use the published stream

Status: Draft

Purpose

Connect an authorised NTRIP client or rover to the published course stream. Confirm data receipt and diagnose common client-side faults.

Learning objectives

After this lesson, you can:

1. Identify the client connection values.
2. Discover or confirm the mountpoint.
3. Connect with approved credentials.
4. Verify continuing correction-data receipt.
5. Separate correction receipt from rover position calculation.
6. Diagnose network, authentication, mountpoint, and freshness faults.

Prerequisites

Complete Lesson 5. The stream must pass its publication checks. Use an approved test client or hardware rover on the trusted network or VPN.

Key terms

• Caster address: The trusted host or address used by the client.
• Caster port: The TCP port used by the NTRIP listener.
• Credential: The approved username and password used for access.
• Connection profile: The saved client values for one caster and mountpoint.
• Correction age: The age of correction data available to the client or positioning engine.
• Fix state: A rover result such as autonomous, float, or fixed, when exposed by the rover system.

Concept explanation

Required client values

An NTRIP client normally needs:

• caster host or address
• caster port
• mountpoint
• username and password when authentication is enabled

The project default port stated by its documentation is 2100. The actual course value comes from the approved configuration. Do not assume the default when the course environment declares another value.

Discovery and connection

The client can request the caster root to obtain the sourcetable. It then requests the selected mountpoint. The caster checks the request target and credentials. An accepted stream receives an NTRIP success response followed by RTCM bytes.

What successful receipt proves

Continuing bytes prove that the client receives a stream. They do not prove:

• correct antenna coordinates
• good satellite visibility
• low correction age at the positioning engine
• a fixed rover solution
• centimetre-level accuracy

These results require additional rover and field evidence.

Safe credential handling

The project uses Basic authentication. Treat the password as reusable. Do not include it in screenshots, exports, command history, or assessment evidence. Use the trusted network or VPN because Basic authentication does not encrypt the connection.

Worked demonstration

The instructor uses an approved test client.

1. Confirm the caster is reachable through the trusted path.
2. Request or review the sourcetable.
3. Select the course mountpoint.
4. Enter the approved username and password without recording the password.
5. Connect.
6. Observe continuing data receipt.
7. Compare the client's receipt time with the caster freshness result.
8. Disconnect and remove the temporary profile.

Expected result: the client receives the selected current stream. No claim is made about rover position unless separate evidence supports it.

Guided practice

Create a course connection profile with placeholders in the evidence copy:

host: <caster-host>
port: <caster-port>
mountpoint: <mountpoint>
username: <course-user>
password: <not-recorded>

Connect and record:

• connection time
• selected mountpoint
• continued data receipt
• correction or stream age if the client exposes it
• practice pathway used

Independent practice

Diagnose one supplied fault. Use this order:

1. trusted network or VPN reachability
2. caster service state
3. listener host and port
4. sourcetable response
5. mountpoint spelling and case
6. username and password
7. stream freshness
8. client or rover input settings

Stop when the failed boundary is proven. Do not weaken authentication.

Checks for understanding

1. Which four values normally define a client connection?
2. What does an unauthorised response indicate?
3. Does receiving RTCM prove a fixed rover solution?
4. Why should the sourcetable be checked before changing rover settings?
5. Why must the password be absent from evidence?

Assessment and evidence

Connect the approved client and submit:

• a redacted connection profile
• evidence of continuing data receipt
• a statement about what the result does and does not prove
• one ordered fault diagnosis

Troubleshooting guidance

Summary

A client needs the correct trusted address, port, mountpoint, and credentials. Successful RTCM receipt proves transport to the client. It does not by itself prove position quality.

Source references

• SRC-PROJECT-OVERVIEW: listener, authentication, mountpoint, and safety boundaries
• SRC-PROJECT-CODE: implemented request, authorisation, sourcetable, and stream responses
• SRC-NTRIP-CONCEPT: general client and caster roles