What about the issue of the unit correctly receiving the base correction RTCM and not recognizing this data?
It is common for IBGE SJSP0 units in Brazil to receive correction data and not initialize, just showing as single.
In this case the unit M2 at 8,36km of SJSP
Receving correction from SJSP0
But after more than 173 messages RTCM continues to show as Single Solution
Change base to EACH at 63km, show FLOAT Solution with 9 RTCM Messages receved.
Hmmm, they are sending out way too many and redundant message, both legacy, msm4 and msm7 at the same time.
I see in the screenshot that the receiver doesn’t receive any base information from the SJSP0 mount point. M2 works fine with the other mount point of this service so I assume that the root of the issue might be in SJSP0 in particular. Have you tried contacting their support to check the state of that mount point?
Hi @liudmila.slepova ,
Negative, many others base have this problem, like CUIB0
I was unable to work with RTK, but I save the RTCM received from this base and process PPK perfectly.
And I contacted IBGE and they haven’t updated recently.
We frequently use these reference bases and after the update that unified all Logging files into a single ZIP (it must have been update 30).
There were more than 20 emails, with recorded logs, videos, screenshots, everything is in support ticket 77896, without solution.
I notice in your screenshots for the problematic bases:
Satellites in view: 0
More than likely the base provider is the problem.
Persist with them.
Hi @timd1971 ,
We use same bases with Topcon and Trimble without problem.
The RTCM received on M2 it’s ok.
Nothing yet, nothing new?
Currently, it’s quite hard to understand why some of the mount points of IBGE NTRIP service don’t work with M2. I checked that the SJSP0 mount point transmits the messages needed for M2 for solution calculation in RTCM 3.3 format. So it should work fine.
However, we tried checking the mount point with the 3d-party app that shows info about the NTRIP stations and it couldn’t display any base info for the SJSP0. At the same time, if you check the other mount point (POAL0) it works fine. The same situation can be seen in Emlid Flow.
So, to understand the cause of the issue, we need more details on this. As I see from your previous correspondence in the support ticket, my colleague asked you to share the LLH file from the survey to continue the investigation.
Please provide the recent data you have with the SJSP0 mount point so we can check what could be the issue:
- The raw data logs from the rover (UBX).
- The base corrections log (RTCM3) from the rover.
- The position log from the rover (LLH).