How to debug Ntrip stream

Hi there, I’m just one a travel to Africa and want to use the local Ntrip caster for correction. For some reasons the closes stream doesn’t work for any correction of my Reach RS (v2.9.3-r0). Is there any way to debug why the stream can’t be used in this case?

At first it looks good, as if it receives data (see screenshot):

But as I check the status, there is no correction taken into consideration:

Can it be RTCM2?

None of the messages that the caster is sending contain observations, it only sends base station position and ephemeris. RTK is not possible without observations.


Thx guys for your quick responses, I contacted the caster owner and they finally found a error on their caster. I thought that there was the problem, and it was.

@igor.vereninov Igor, how do you read the output? Is it just the lack of obs() data?

So now the output looks much better:

It seems like you are stilling missing message 1002 (GPS observations)
But have message 1077 1087 and 1097 instead (MSM message)
Edit: here is the short description of RTCM messages:

And some more in depth about RTCM messages


It seems like the correction works without the 1002. As I get relatively fast a fix. Should I contact the caster and ask about the missing GPS observations?

No need i think. Its a Multiple Signal Messages 1077,1087 and 1097

Multiple Signal Messages (MSM) Message Types

The Multiple Signal Messages (MSM) can be found in the range of 1070 to 1129. A short press release from RTCM regarding MSM content can be found here. These messages add support for direct Doppler observations (finally!), which can be a critical factor in achieving ambiguity resolution when using L1 only devices on the move.

An overall intent of the MSM message development effort has been to have more uniform and more modernized set of messages that can employed with any GNSS system (not just GPS and GLONASS). To that end, seven new basic message types were defined (see the table below). And then each of these was applied to each separate GNSS system. So for example; an MSM7 style message for QZSS is nearly identical to an MSM7 style message for GPS, only their message ID assignment numbers vary. The seven basic messages each have more informational details than the one that precedes it.

Here is quick summary:

_ The seven defined MSM message types, reused with each GNSS type_
MSM1 DGNSS uses, Pseudorange, (conventional and advanced)
MSM2 RTK uses, Pseudorange only
MSM3 RTK uses, Pseudorange (i.e. Code) and PhaseRange (i.e. Carrier)
MSM4 RTK uses, Pseudorange, PhaseRange, CNR
MSM5 RTK uses, Pseudorange, PhaseRange, Doppler, CNR
MSM6 RTK uses, Pseudorange, PhaseRange CNR, with high resolution
MSM7 RTK uses, Pseudorange, PhaseRange, Doppler, CNR, with high resolution
— Three other messages have reserved number assignments as well,
but at present there is no active development of them.
These seven messages are then assigned to a range grouped for each GNSS system as follows:

_ Msg ID Range_
_ MSM message type IDs assigned to each GNSS type_
1071-1077 GPS (1077 is the best to use. Setting up uBlox with RTKLIB? – use this)
1081-1087 GLONASS (and 1087 would be the one to use here)
1091-1097 Galileo
1101-1107 SBAS
1201-1207 QZSS
1301-1307 BeiDou
As always, see the actual RTCM SC104 standard for the details. In a way much like the popular use of the 1004 message (even when no L2 data was present), many deployment send the MSM7 message as it contains the most details and features. For this reason one can say that the MSM7 message is the one you are mostly going to find being sent (1077, 1087, etc.). At this time, SNIP lists these messages in the RTCM3 decoder dialog as they occur, but does not provide an exhaustive decoding of the element contents in the Lite edition of the tool.

Link to actuall article


This topic was automatically closed after 100 days. New replies are no longer allowed.