I’m building an RTCM relay for a corrections service that will relay GNSS data to autonomous rovers as an RTK solution. Currently I am trying to set up an NTRIP client that will connect to a mount point, extract RTCM and publish it out on our own network. The mount points we are using require a username and password to connect, but I see no option to include that when building an Orekit NTRIP client. Is this feature not available in the gnss package or am I overlooking something? Any help would be appreciated!
You should just have to use the standard java.net.Authenticator class and its setDefault method to set up the authenticator you want. It may be something that displays a logging window if you are in a graphical user interface, or it can rely on credentials read on file or passed by environment variable. Orekit does not provide an authenticator by itself because it is a security sensitive thing, so we let users decide by themselves the level of security they need.
I’m returning to work on the relay project after setting it aside for a time and am having trouble connecting to any of the sources I have available to me using the Orekit NtripClient.
I have tested connectivity to these sources using this CLI tool, and my credentials work just fine when connecting to a mount point.
I have run through a debugger to see the cause of the failure, and it seems NtripClient.java expects the HTTP response to have the content type “gnss/sourcetable” when in fact the response is showing a type of “text/plain.” Is there any way around this? This particular source is provided by TopCon.
There are several other sources I have tried, and all of them fail in one way or another mainly due to the HTTP response not being formed exactly how the Orekit client expects it.
Any recommendations are welcome! Also, if there are any code examples of the NtripClient being used somewhere besides the Orekit test repo, I would be interested in looking over them. Perhaps I am setting something up incorrectly when trying to connect to a source? Any advice is welcome, thanks!
It seems we are picky about conformance to NTRIP V2, maybe the caster you use is NTRIP V1? The content-type was different in NTRIP V1. There are also other differences with NTRIP V1 that made it impossible to parse with regular HTTP handling, the major one being that instead of using “HTTP/1.1 200 OK” as the first response line, NTRIP V1 used “SOURCETABLE 200 OK”, which broke everything!
Do you have a correct first line and only an incorrect content-type (hence some hybrid between NTRIP V1 and NTRIP V2)?
Sorry for the delay.
The caster you connect to seems to not be compliant with Ntrip V2 specification despite it advertises it.
We can try to work around this, but I would suggest you to notify the producer about the issue so they fix their generation program. Also note that when one requests gnss data, the content type should be “gnss/data”, is there the same issue for this request?
Could you try the following patch as a work around? ntrip.patch (1.6 KB)