NTRIP Caster/TCP Server port & setup conflict/issues/startup

[disarticulate]

I'm working on pulling corrections to a larger server that can act as a NTRIP Caster for potentially multiple devices.
I've got the following: firmware:

RTK Everywhere Firmware: v2.3
ZED-F9P Firmware: HPG 1.32 ID: 2B41F211DF

I found a bug in the RTK setup menu for the NTRIPCaster and submitted that here: #859

This allowed me to turn the ntripcaster on.

However, I believe there's an issue in settings:

I believe when NTRIPCaster is on, it only turns on after the Survey-In time & when it does turn on, it shuts off the port 2948 in favor of 2101. I believe these are standard ports.

Additionally, NTRIP Caster's source table appears in complete. This code has a succinct struct for the sourcetable: https://github.com/go-gnss/ntrip/blob/master/sourcetable.go reproduced here:

type CasterEntry struct {
	Host                string
	Port                int
	Identifier          string
	Operator            string
	NMEA                bool
	Country             string
	Latitude            float32
	Longitude           float32
	FallbackHostAddress string
	FallbackHostPort    int
	Misc                string
}

Once the port switches from 2948 to 2101, you can get the full sourcetable from debugging via pygnssutils:

response='STR;SparkBase;none;RTCM 3.0;none;none;none;none;none;none;none;none;none;none;none;B;N;none;none'``

I assume some of these fields should be automatically settable, particularly the lat/long. Other's should be user controlled.

---

At a minimum, there's a confuse between setting the TCP Server and the NTRIP server setting up and changing to a non-documented-in-instructions port.

[disarticulate]

Ok, so it looks like I was in BaseCast mode; switching to Base mode seems to resolve my specific usecase, which is to stream changes to a server that can better handle ntrip (potentially).

However, the confusing bit of the BaseCast mode remains:

• First, it boots into "TCP Server" mode listening to the port defined.
• After it receives, I think, Survey-in data, it switches to undisclosed port 2101

I think the intention of:

SparkFun_RTK_Everywhere_Firmware/Firmware/RTK_Everywhere/TcpServer.ino

Line 236 in 1cce7c8

port = 2101;

Is to use the set TCP Server port, unless it's in AP mode? This logic doesn't seem very straightforward.

It seems like it should use the tcpServer port regardless and the choice is between a typical TCP server or the NTRIP server. So perhaps it should be a radio button selecting tcpServer or NTRip server and both us settings.tcpServerPort

There's also an issue I observed in the BaseCast mode in that there must be a timeout disconnect, but it seems to provide identical TCP Server results, so really hard to figure out what it's doing because the above logic seems to only be implemented after some time.

[disarticulate]

So I reset the profile and just turned TCP server. It does not appear to be stable using the Ethernet connection. When it is live, it resets the gnssstreamer connection, which is just a raw python socket every 30 sections:

ConnectionRefusedError: [Errno 111] Connection refused
[2025-12-20 21:16:05] Process died unexpectedly, restarting...
[2025-12-20T211607] Starting gnssstreamer -> 2025-12-20T211607.ubx
[2025-12-20 21:16:35] Process died unexpectedly, restarting...
[2025-12-20T211637] Starting gnssstreamer -> 2025-12-20T211637.ubx
[2025-12-20 21:17:05] Process died unexpectedly, restarting...
[2025-12-20T211707] Starting gnssstreamer -> 2025-12-20T211707.ubx
[2025-12-20 21:17:35] Process died unexpectedly, restarting...
[2025-12-20T211737] Starting gnssstreamer -> 2025-12-20T211737.ubx
[2025-12-20 21:18:05] Process died unexpectedly, restarting...
[2025-12-20T211807] Starting gnssstreamer -> 2025-12-20T211807.ubx
[2025-12-20 21:18:35] Process died unexpectedly, restarting...
[2025-12-20T211837] Starting gnssstreamer -> 2025-12-20T211837.ubx
[2025-12-20 21:19:05] Process died unexpectedly, restarting...
[2025-12-20T211907] Starting gnssstreamer -> 2025-12-20T211907.ubx

Eventually the port closes. It appears related to the survey in portion of the startup. I'll check if the wifi network portion works to see if it's only the ethernet.

[disarticulate]

It does not appear isolated to ethernet. I've looked through potentially relevant code and can't find a timeout at 30 seconds, but assume there's some handshake missing from the gnssstreamer.

But the fact that eventually the port disappears is concerning, including the loss of wifi.

[disarticulate]

I seem to be consistently crashing the TCP server wether on ethernet or wifi using the gnssstreamer library. It just does the following to stream (https://github.com/semuconsulting/pygnssutils/blob/main/src/pygnssutils/gnssstreamer_cli.py):

        with create_connection((ip, port), timeout) as sock:
            # wrap socket to allow processing as normal stream
            stream = SocketWrapper(sock, encoding)
            _run_streamer(stream, **kwargs)

Do I miss understand what's suppose to happen on this connection? I'm expecting it to just recieve messages indefinitely.

[disarticulate]

Further digging, I made this comment: #801 (comment)

I made a monkey patch to the gnssstreamer to try and keep listening to the socket as follows:

        while True:
            try:
                conn = create_connection((ip, port), timeout)
                # wrap socket to allow processing as normal stream
                set_keepalive_linux(conn)
                stream = SocketWrapper(conn, encoding)
                _run_streamer(stream, **kwargs)
            finally:
                conn.close()
                print('Socket Closed, Retrying...')

This just delayed the inevitable: The port eventually closes. I think it might be related to ublox trying to connect to wifi and then gives up. I'm guessing there's some complicated routing between the ethernet and the wifi settings that need to be resolved.

The next test is to modify gnssstreamer to use UDP as that port seems to be unaffected and should be faster and less CPU intensive since my goal is to collect 24-hour PPP using ppk.

[PaulZC]

Hi Eric (@disarticulate ),

It is very difficult for us to understand what you are trying to achieve. You say you want to "[pull] corrections to a larger server that can act as a NTRIP Caster". So, surely, NTRIP Server is what you need? Correct, it will only connect to the Caster once the survey-in is complete. It you defined a Fixed Base position, it will connect immediately.

I hope this helps,
Paul

[disarticulate]

Yes, I understand. Some of this may be my misunderstanding. However, there are oddities going on with the TCP Server and the NTRIP Caster service doesn't appear to return the correct source table, but that does not seem to matter except it's lat/lng data means it doesn't get pulled up if a client is trying to poll it for the "nearest" location. The source Table as a confusing name "SparkBase" which you need to know for any of these clients. And while the TCP Server is running, instead of the NTRIP, it doesn't act like a NTRIP server.

I then got side tracked into what appears to be another bug: Pulling TCP Server data resets every 30 seconds. Not sure how you want to handle that.

Another oddity is when you do select the NTRIP Caster, it doesn't boot first; it boots after the TCP Server and it changes ports from whatever is listed in the gui to 2101, which is hardcoded.

It you defined a Fixed Base position, it will connect immediately.

I'm trying to get to that, but before I have that I need to record 24HR of data, and my goal is to collect the logs to do this.

[disarticulate]

So I've resolved this specific issue as follows:

1. Turn the ntripcaster on (broken in the UI currently: fix checkbox input with required class for enableNtripCaster index.html #859)
2. Wait for the device to survey in, close the listed port and open port 2101 for the NTRIP Caster
3. User RTKLIB's STRSVR-EX 2.5.0 (https://github.com/rtklibexplorer/RTKLIB) to connect an ntrip client, browse for the endpoint, and connect (note, ublox's ucenter fails to do this; other CLI clients also seem to fail to pull up a list of the clients)
4. Stream to a file

Things still problematic:

1. The TCPServer port is not related to the hard coded NTRIP port:

   SparkFun_RTK_Everywhere_Firmware/Firmware/RTK_Everywhere/TcpServer.ino

   Line 236 in 1cce7c8

   port = 2101;

   but the TCPServer port is the first to come up and be exposed, causing confusion.
2. TCPServer appears to reset every 30 seconds then disappears. I think thats related to the WiFi setting; I'm using the ethernet connection.