Relay back issue with str2str rtklib-b34h on linux

[CalebJRogers]

I've downloaded the latest 2.4.3 RTKLIB-b34h on both Windows (for use with the GUI) and on a RHEL 8 linux machine where I compiled the source code.

My goal: To stream RTCM3 corrections from a VRS over to a serial device on my linux machine, all via the CLI. This requires relaying back the GPGGA statement from my serial device.

My issue: Everything works perfectly on the Windows side using the strsvr.exe application. So this means the serial device as well as my NTRIP caster are all cooperating. However, when I try replicating it from the str2str CLI on linux there is no data flow.

Confirmed no serial port/dial out group issues on the linux machine. I can ping the caster. GPGGA statement is indeed being output from my serial device. I get the following output with info redacted: stream server start 2023/09/06 19:26:12 [WC---] 0 B 0 bps (0) connecting... (1) /dev/ttyUSB3 2023/09/06 19:26:17 [CC---] 452 B 0 bps (0) ***.com/MntPnt (1) /dev/ttyUSB3 ....and so on repeated.

I've tried all sorts of variations on the following command/arguments (including -n ):

./str2str -in ntrip://user:password@***.com:2101/MntPnt#rtcm3 -b 1 -out serial://ttyUSB3:115200:8:n:1#rtcm3

Anything obvious jumping out?

[rtklibexplorer]

The formats (#rtcm3) in your command are unnecessary since they are only used to convert from one format to another. However I suspect this is not your problem. My guess is that the most likely issue is that the relayback option relays back all of the messages from the receiver and not just the GGA message needed by the NTRIP server. You can verify this by disabling all receiver messages except GGA and see if this works. I believe some NTRIP casters are better than others at extracting a GGA message from a stream of other messages.

Another option might be to use the str2str -p option to specify the receiver location, and the -n option to send this back to the NTRIP caster but this requires that you know the rough location of the receiver ahead of time or that you write a script to extract the current location from the receiver and embed this in the command line to str2str.

[CalebJRogers]

Hello and thanks for the reply. One of my attempted variations did exclude the #rtcm formats and also did not work. The only messages being sent from the receiver are GPGGA statements - I've confirmed this in a putty serial terminal. I'll give the -p and -n a try to help troubleshoot, and if it works then I'll pursue the script route in the meantime.

But like I said above, it seems to work flawlessly with the Windows GUI version (same receiver and same NTRIP server/credentials) when simply checking the options box to relay (1) -> (0), so something seems weird..

[rtklibexplorer]

To doublecheck this, I did run the b34h version of str2str on a Raspberry Pi with the same command line you are running (minus the #rtcm3) with a VRS NTRIP server. I worked fine for me when the only receiver messages enabled were GGA but with more messages enabled, the NTRIP server never started streaming data, I assume because it wasn't able to parse the GGA position.

Did you verify your GGA messages had valid positions? If the antenna is indoors or obstructed, you can get GGA messages with a timestamp but no position.

[CalebJRogers]

My GGA messages are valid. I just re compiled and tried again still with no luck. Thanks for looking into it - I will continue to troubleshoot.

[CalebJRogers]

Solved.

I went ahead and tried it with a raspberry pi too - no luck either, which I thought was weird. Then I tried it on another network and am now getting good corrections streamed. My original network is a cell network; not sure if the problem was my cell provider or the actual cell modem, but that is a problem for another day and another group. Thanks!