str2str_tcp in a bad state

[Stefal]

Describe the bug
Sometimes, the main service str2str_tcp is not sending data.
We can see that

• there are no sat levels on the status page
• str2str_ntrip_X services don't send data to the caster but these services buttons are green
• if we set debug level to 2 in run_cast.sh, we can see these lines in the ntrip the logfile.

2 20385.360: readtcpcli: recv error sock=5 err=104
2 23058.733: waittcpcli: inactive timeout sock=5

To Reproduce
Difficult to reproduce. It occurs only from time to time after a reboot or a startup.

Expected behavior
A clear and concise description of what you expected to happen.

Software/Hardware (please complete the following information):

• RTKBase release number 2.4.1
• OS: Armbian
• SBC Orange Pi Zero
• GNSS Device: Ublox F9P
• Connection type: usb

Additional context
Could it be related to RTKLib 2.4.3 b34g?

[Stefal]

Example when str2str_tcp doesn't get data from the F9P :

-- Boot 69d85fd8d47e4bfe9758dd0ad184eb7c --
Nov 16 13:58:19 basegnss systemd[1]: Starting RTKBase Tcp...
Nov 16 13:58:19 basegnss systemd[1]: Started RTKBase Tcp.
Nov 16 13:58:19 basegnss run_cast.sh[592]: stream server start
Nov 16 13:59:20 basegnss systemd-journald[500]: Suppressed 12 messages from str2str_tcp.service
Nov 16 13:59:20 basegnss run_cast.sh[592]: 2023/11/16 13:59:38 [CC---]          0 B       0 bps (0) /dev/ttyS1 (1) 2 clients
Nov 16 14:01:31 basegnss systemd-journald[500]: Suppressed 11 messages from str2str_tcp.service
Nov 16 14:01:31 basegnss run_cast.sh[592]: 2023/11/16 14:01:50 [CC---]          0 B       0 bps (0) /dev/ttyS1 (1) 2 clients
Nov 16 14:02:31 basegnss systemd-journald[500]: Suppressed 11 messages from str2str_tcp.service

str2str_tcp.log file is empty

str2str_ntrip_A.log :

1     0.129: gentcp: gethostbyname error addr=caster.centipede.fr err=11
2    10.024: waittcpcli: inactive timeout sock=4
2    30.028: waittcpcli: inactive timeout sock=4
2    50.040: waittcpcli: inactive timeout sock=4
2    70.052: waittcpcli: inactive timeout sock=4

str2str_file.log :

2    10.016: waittcpcli: inactive timeout sock=6
2    30.033: waittcpcli: inactive timeout sock=6
2    50.044: waittcpcli: inactive timeout sock=6
2    70.058: waittcpcli: inactive timeout sock=6
2    90.065: waittcpcli: inactive timeout sock=6
2   110.079: waittcpcli: inactive timeout sock=6
2   130.087: waittcpcli: inactive timeout sock=6

Does str2str_tcp sometime starts too early ?

[bitfieldfarm]

I have issues with this too, as described here:
https://discourse.agopengps.com/t/rtkbase-no-signal-after-beeing-down/15041

[Stefal]

Hi @bitfieldfarm
I've read the thread on the agopengps forum. One thing is strange : the very low throughput on str2str_tcp.

Your base:
janv. 04 07:55:46 basegnss run_cast.sh[2771]: 2024/01/04 06:56:04 [CW---] 10910068 B 1564 bps
Mine
janv. 09 09:20:52 basegnss run_cast.sh[559]: 2024/01/09 08:21:11 [CC---] -1645917788 B 37178 bps

1564bps vs 37178bps

There is something wrong on the F9P. You can try this :

• Power off the base station, disconnect the power for 10 seconds, then power on.
• Still doesn't work ? Try to detect & configure the F9P again
• Still doesn't work ? Check your antenna cable.

If you're running the latest F9P firmware, you can connect the F9P to U-center, (network connection tcp://your_base_ip:5015) and take a look at the spectrum : #280 (view->messages->ubx->mon->span)

[bitfieldfarm]

Hi
Ok. I've not disconnected yet. Will do later on.
I have no idea what firmware I'm running. But it's bought autumn 2023. Everything worked out of the "box".

I'm new to U-Center. I made the connection to tcp:ip_addr:5015

[bitfieldfarm]

After disconnect power and antenna a wile.
I get the same spectrum after. And the same after detect and reconfigure.

Guess I'd better get on the roof an check the stuff there.

[Stefal]

Your PGA value is very high, I think you have a hardware problem (antenna, cable, or F9P).

[Jef239]

Sometimes, the main service str2str_tcp is not sending data.

I found two big problems with str2str, they may be related

1. If there was a TCP connection, but no NTRIP connection, str2str hangs in an eternal wait for an NTRIP response.
2. str2str NTRIP server is NTRIP v1. And it does not understand the error response from the NTRIP v2 caster, for example Onocoy.

Both bugs work together. That is, with an incorrect mountpoint or login, it can hang until it stops.

To reproduce, you need to connect to the NTRIP-v2 caster, for example servers.onocoy.com:2101 with an incorrect mountpoint or password.

As for the basic service, the inactivity timeout does not work for the COM port in str2str. That is why I observed this situation. In the dmesg logs - USB failure for USB-COM. str2str hangs, not accepting anything. When restarting - everything is restored.

I hope that at least I clarified the situation a little. If you are ready to apply my patches or push them into rtklibexplorer - I can highlight the necessary pieces. In general, everything is now in https://github.com/GNSSOEM/ELT_RTKBase/tree/dev/Install/rtklib