Trying to progress setting up a RUT-955 (RUT9_R_00.07.04.5/2023-07-24) as an NTRIP client via serial to a UHF radio which in turns acts as a repeater and transmits the NTRIP corrections to the GNSS rover receiver. NTRIP network is a propriety breadcrumb (Rajant) network controlled by Leica GNSS Spider and currently supports multiple equipment running various GNSS receivers with built-in NTRIP from several different manufacturers. So NTRIP network is good, receivers with built-in NTRIP & direct Ethernet connections are good, GNSS rover receivers without NTRIP require a bridging system, hence the RUT-955. Infrastructure hardware schematic is something like
RUT-955 is connecting via WAN only, appears good, there is no SIM installed.
Ethernet via WAN (static IP), connects to server ok, client host is received correct, Rover is rejected due to No GPGGA message. No GGA message remains the current blocking point as no position then system unable to return corrections from a the closest reference site? My Comments/Queries are
The WiKi only appears to reference legacy firmware even though the header lists the current firmware version? This has been a little confusing as the current NTRIP package is quite different to legacy versions.
RUT-955 GPS position checks all good, but appears No GGA message when using NMEA source: Router GPS device
Have also tried Pre-defined coordinate (Lat/Long) option without success
I have noticed RUT-955 appears to be attempting to read GGA back from the RS232 device but not being a GNSS receiver then this is not possible. GPS source needs to be the routers built-in GPS
Query. Does the RUT-955 expect or thinks a GNSS receiver connected via RS232 to continue receiving position information for GGA message purposes back to the server/s etc?
Are you refering to the NTRIP wiki article here? It seems that it refers to the latet firmware version. Or maybe you refered to a different article?
When you are using routers GPS, is GPS enabled on the device itself and does it obtain a fix? When source is set as routers GPS, it will try obtain the sentence from its own GPS. If the ‘serial device’ is selected as the source, then the application will read its serial device input and will try to obtain a valid GPGGA NMEA sentence from it.
Check if the router can indeed obtain the sentence.
I had been referencing a different Template:Networking RUT Manual which showed the correct firmware but the contents referenced Legacy firmware. Your link is the correct one, now we are on the same page.
“When you are using routers GPS, is GPS enabled on the device itself and does it obtain a fix?”
Yes all good with routers GPS
Yes Using Routers GPS Device
Also tried Predefined coordinates
There is no way the router can see (as such) the actual GPS receiver as GPS receiver sits on the other side of a UHF radio hence router is connected serially to the UHF radio, UHF radio essentially acts as/configured as a Repeater.
Mostly been testing using NTRIP V1.0 but NTRIP server is set AUTO Detect of the NTRIP type
What I have seen so far is the router is making a request to the server ok, identifies the correct Client Host IP (configured in WAN) but rejects the user with “No GPGGA message received”
How can I then check for the GGA message in the router?
You can enable GPGGA sentence forwarding in GPS → NMEA and send it to your PC running some TCP server (for example, Hercules here).
Alternatively, you can access the command line of the device (instructions here) with username ‘root’ and execute the following commands to view GPS sentences received by the modem itself:
ubus call gsm.modem0 info | grep gps
# based on the output of the command, execute CAT on the USB devie:
cat /dev/ttyUSB1
Ok can see the GPS (& Glonass etc) sentences GSV, GGA, VTG, RMC etc and $GNxxx with Glonass on so no problem with GPS, coordinates match the GPS map/instance page, all good with that.
No such luck with NMEA Forwarding, obviously not getting the IP & Port correct for some reason? But if basically forwarding the same Modem GPS sentences then it might not tell me anything further?
Just clarify a couple of points please?
An instance of NTRIP to work using Router GPS device only requires GPS On & NTRIP Instance On? Is that Correct or are there other services/connections to be enabled?
An instance of NTRIP using Predefined coordinates does not require any other services/connections to be enabled including GPS?
NTRIP Predefined coordinates Lat/Long are Degrees & decimals, and not input as NMEA format DegreesMinutes & decimal minutes
Is there a way to see what the Client is actually sending to the server? Very hard to tell why the server is rejecting the client when by all accounts things should all be good?
Nearest Base - nb 20.08.2023 00:43:24 Spider Server Product Rover user rejected. No GPGGA message received. Access denied. (Client Host: ‘10.39.136.176:52354’)
Nearest Base - nb 27.08.2023 01:51:14 Spider Server Product Rover user rejected. No GPGGA message received. Access denied. (Client Host: ‘10.39.136.176:47260’)
To me the NTRIP instance has all the requirements in this one package/page (apart from GPS if/as required) but appears the GGA is being lost for some reason?
With NTRIP service, the communication is initiated with HTTP request using clients credentials and initial NMEA string. You can capture the traffic or send it to your TCP server. NMEA source option allows you to choose how these coordinates are obtained. You can either enter a static value of GPGGA NMEA using a predefined string or predefined coordinates. The format for cordinates is decimal degrees, not Degree Minutes Seconds. If you select the “Router GPS device” option, the application will attempt to use real coordinates obtained from the router’s GPS device. To use this option successfully, make sure the GPS service on the router is enabled, the GPS antenna is connected, and a GPS fix is acquired. Otherwise, the application will wait for valid GPS coordinates, and communication with the server will not start until then. Alternatively, if you choose the “Serial device” option, the application will read input from the serial device and attempt to acquire a valid GPGGA NMEA string from it. Once again, communication with the server will only begin when valid coordinates are obtained.
If you are entering the sentence manually, make sure that checksum is correct. You can recalculate it using one of the online tools. For example, one here.
If you start NTRIP from the command line, you can see the output. The command will depend on the serial device, thus you can use one of the following:
It is hard to say the reason why it is rejected. I cannot replicate your scenario, thus, as a troubleshooting step, I would suggest checking if it works other NTRIP casters, like SNIP.
Initially it showed there was no NTRIP instance on when in fact there was. 955 had 3 instances configured but only the 1 was on at any one time. There also appeared to be a cross link between Instances, in particular server URL coming through when URL was in fact in another Instance that was definitely switched off.
Short answer was to Default/Reset and re-install firmware version and NTRIP package from scratch.
Have now been able to configure 1 NTRIP Instance that I can access locally with CLI stream indicative of correct config and operation. This at least gives me now a baseline to work to but until I can get the unit back on the operational network then the result with that network & GGA still remains unknown.
In going through the above motions I now have another query regard Local Time/UTC time etc which I will create a new thread for.