RS2+ as Ntrip base for Trimble

Hi, I am trying to use and RS2+ as a RTK base station for some Trimble Receivers (R2,R10). I have got this working well except for the Galileo system. RTCM Messages I am sending from the RS2+ are 1006,1074,1084,1094,1124,1230,1008 and 1033.

Message 1094 is the Galileo message, and I have used snip to understand what is different about the Emlid 1094 message and other services I have access to. The only difference is that the codes L1C and L7Q for Emlid and L1x and L5x for others

Is it possible for Emlid output the 1094 message with the L1x and L5x code?

Attached are some screenshots


1 Like

Hi! I also have the same problem that I wrote about in this forum thread. Look at this information, maybe it will help you.

Emlid promised to study this problem, but so far there is no answer.

1 Like

Hi, yes I have had a read of your thread as well.

Can you confirm your CORS is sending the 1094 message with the L1X (E1) and L7X (E5b) codes and this is working with your trimble gear?

If this is the case then it might be the missing L5x (E5a) that Trimble require for a solution.

Our cors broadcasts these Ntrip messages, see the screenshot. Trimble works without problems from it.

1 Like

Hi guys,

The L5X code refers to the Galileo signal in the E5a frequency band, while L7Q corresponds to E5b. Our Reach receivers can only track the E5b signal (L7Q). This is why, if Trimble indeed requires the E5a signal for the calculation, Galileo satellites from Reach RS2+ would not be considered. Due to hardware limitations, we can’t update the existing devices to support E5a. However, I’ve shared your use case with our development team for future reference.

1 Like

RTCM SC-104 has evolved, and here is a brief history.

With Version 3.2 came Multiple Signal Messages, which combined “messages together with associated data instead of sending separate messages to accomplish the same task.”

Here is the fine print:

"GLONASS Bias Information Message

Message 1230 communicates the GLONASS Code-Phase Bias (CPB) information. This information allows RTK rovers to compensate for differences in biases between themselves and the base station, enabling or improving the resolution of GLONASS ambiguities.

CPB values for all GLONASS FDMA signals available in the data stream of both MSM and Legacy (1081-1088 and 1009-1012) are mandatory for full GLONASS interoperability."

Emlid’s REACH M2 is using RTCM-3.2, and if MSM4 is being used, then 1230 would not be needed, if the above cite is true ( available in the data stream of both MSM).

Via REACH M2 with a GNSS antenna that is capable of receiving them.

Dipping into this rabbit hole, it was suggested on May 25, 2012
.
Instead, a proposal is circulating to apply the correction only to the new RTCM “multiple signal messages” (MSM) (This is discussed in the article by F. Takac et alia cited in Additional Resources). As the MSM messages are new, they are free of backward-compatibility constraints.

As noted before, “GLONASS Code-Phase Bias (CPB) values for all GLONASS FDMA signals available in the data stream of both MSM and Legacy (1081-1088 and 1009-1012) are mandatory for full GLONASS interoperability.”

Also, by May of 2017, SmartNet was using RTCM 3.2 MSM, and deprecated RTCM 2.X And CMR Corrections.

Using the Ntrip checker, RTCM1230 when checked does not show up when RTCM1084 is used.

Conclusion - RTCM1230 is not needed when RTCM1084 is being used on newer equipment. Unknown how Emlid’s programmers dealt with this issue if both RTCM messages are clicked on.

Hi @phainein7,

Thank you for sharing this detailed information. I’ve passed your insights along to our developers for their review.

Septentrio suggests in their “How to set up a base station – Chapter 5: Configuring the output of differential corrections” that when using their latest generation of Septentrio receivers, if MSM4 is checked, then

The following RTCM messages are selected by default:

RTCM1074 GPS MSM4
RTCM1084 GLONASS MSM4
RTCM1094 GALILEO MSM4
RTCM1124 BEIDOU MSM4
RTCM1006 Station description (ARP with Antenna Height)
RTCM1033 Receiver and Antenna Descriptors
RTCM1230 GLONASS L1 and L2 Code-Phase Biases
.
.
I have verified that a Septentrio receiver can output RTCM1230 along with RTCM1084
.
.

Quick question to make sure I’ve got it right. In your earlier comment, you mentioned RTCM messages 1230 and 1094, but now I’m seeing 1084. Are you referring to RTCM 1084 instead of 1094 in this case, or is 1094 still the one to go with?

Typo Corrected Above: RTCM1084

1230 is not being broadcasted when MSM4 is engaged for

RTCM1074 GPS MSM4
RTCM1084 GLONASS MSM4
RTCM1094 GALILEO MSM4
RTCM1124 BEIDOU MSM4

Footnote - There are two topics being discussed:

  1. OP’s question: Message 1094
  2. Second poster’s question: message 1230
    .
    Neither topic is on the same page

OP was asking “Is it possible for Emlid output the 1094 message (Galileo) with the L1x and L5x code?” Hardware specs indicates L5x is not possible: Galileo E1B/C, E5b

Second poster, geotimege, was posting about a different topic, which is about using MSM4 with 1230. Specifically, when RTCM1084 and 1230 are both checked on, 1230 does not show up on NTRIP app.

I later posted that both work on Septentrio’s receiver.

CPB values for all GLONASS FDMA signals available in the data stream of both MSM and Legacy (1081-1088 and 1009-1012) are mandatory for full GLONASS interoperability."

I cited this above, which suggests when 1084 is active, then 1230 is not needed:

Focus Here - Does Emlid’s MSM1084 message contain 1230’s content, as suggested in above cite? Septentrio’s receiver I own will do MSM1084 and 1230 at the same time, but Emlid’s M2/Rs2 will not.

Thanks for clarifying! You’re right; Reach receivers can only track the E5b signal (L7Q).

As for the RTCM 1084 and 1230 messages, I’ve passed this on to the team for further look into.