Better str2str services status monitoring

[Stefal]

Is your feature request related to a problem? Please describe.
With the current releases (until 2.6.2), We rely only on the service status (started, error, stopped) to know if the various str2str instances are running correctly.
As an example, we can't know if the ntrip caster respond or not

Describe alternatives you've considered
I just noticed that that str2str output include a useful information:

oct. 13 11:01:40 ubuntu-vbox run_cast.sh[20119]: 2024/10/13 09:01:58 [CW---]    2157584 B   49628 bps (0) localhost (1) connecting...
oct. 13 11:02:30 ubuntu-vbox run_cast.sh[20119]: 2024/10/13 09:02:48 [CW---]    2446752 B   43336 bps (0) localhost (1) mycaster.rtkbase.eu
oct. 13 11:02:35 ubuntu-vbox run_cast.sh[20119]: 2024/10/13 09:02:53 [CC---]    2477564 B   42910 bps (0) localhost (1) mycaster.rtkbase.eu/EMOTEST

[CC---] : Connected / Connected
[CW---] : Connected / Waiting
[-W---] : Not connected / Waiting

[Jef239]

I changed a lot in str2str. Look how the log looks now. Patches are in https://github.com/GNSSOEM/UM980_RPI_Hat_RtkBase/tree/main/RtkLib

[Stefal]

Your link is dead.

What this patch change? If it's a nice enhancement, you should open a pull request on the rtklib repo.

[Jef239]

Your link is dead.

Patches now in https://github.com/GNSSOEM/ELT_RTKBase/tree/main/Install/rtklib

What this patch change?

There are many patches in several directions

1. Radical improvement of diagnostics in the log
2. Output of messages upon disconnection to a file, the contents of which I show in rtkbase to the right of the on/off button. And the yellow color of the button - by the presence of this file. Upon connection, the file is deleted.
3. Incremental timeouts.
4. If IP is specified, we will bind only to it. If not, to all IPs of host.

If it's a nice enhancement, you should open a pull request on the rtklib repo.

It's complicated. Diagnostics of the original str2str shows that the program is alive and how much data it has downloaded. I don't care if str2str dies - the service will show that it has died. I am interested in disconnects and their causes. That's why diagnostics have been completely redesigned. But there is zero chance that the authors of RTKLIB or rtklibexplorer will change the diagnostics goals.

I can make my own fork, but only if you or someone from the community needs it.

There is another problem here. I have made hundreds of improvements in rtkbase. How many of them have you taken? I would be glad if you took everything into mainstream. BUT! We have different approaches, different coding styles, different goals. You do the conversion from the native protocol, I take RTCM3 from the receiver. And this is the same purpose of our project.

And with RTKLIB - different purposes of diagnostics. That's why it is difficult to push the edits into mainstream. And I don't want to waste time trying to persuade them to accept my patches.

If you like this diagnostic format, either use my patches or I'll fork rtklibexplorer.

Sorry for the language, I know it sounds rough, but it's a Google translation.

In general, we are very grateful to you for the great project. Therefore, everything you took for yourself is accepted. What you didn't take, we make patches or work around.

If you want, I can write more pull requests. I write them minimally now - basically only bug fixes.