Emlid caster, Rs2 messages Rtcm

[geotimege (Serj)]

Why message 1230 is not sent via Emlid caster, although this message is enabled in Base settings in Rs2?
I check received packets from caster using Ntrip checker. Ntrip checker shows all messages that are enabled in base settings, except 1230.
I also check the stream from the Cors system, 1230 is also enabled in their stream and ntrip checker sees it.
What could be the problem and how to solve it?
Due to the fact that this message does not reach the rover, some Gnss receivers do not receive a fixed solution.

Could you help me figure this out?

[julia.shestakova]

Hi Serj,

What firmware version do you have on your Reach RS2 base? Is it the latest stable version (31.8)?

[geotimege (Serj)]

Good day, Julia! Yes, version 31.8, but it’s the same on other versions.

[julia.shestakova]

I see, thanks! Let me test it as well, and I’ll get back to you.

[geotimege (Serj)]

I think it would be nice to add RTCM 1013 to the stream.

[geotimege (Serj)]

I am still experimenting with the caster and the base. I think my experiments will help you.

I have conducted several tests.

Experiment 1:

I installed Rs2 as a base station. Connected it to emlid caster. The base observes 39-40 satellites of all constellations. It broadcasts information about 30-31 satellites to the caster. When connecting to this base via emlid caster receivers Rs2, Rs2+, Rs3 and Rx, I observe the following situation (all rovers were 30-50 meters from the base in approximately the same conditions). RS2, RS2+ and RS3 work normally and use all satellite constellations, while the solution uses 25-27 satellites out of 30-33 observed by them. At the same time, as I have already said above, the base observes 40, but broadcasts 30-31. Considering the elevation mask and the noise/signal on the rover, we can understand why 25-27 satellites are involved in the solution, which is an acceptable and very good result at the moment. RX in the same conditions observes all satellite groups, but the solution uses only GPS and GLONASS. Following all the same conditions, but disconnecting all Emlid receivers from the QVSTER and connecting Stones s850+, s800a, Trimble R10 and Ruide r93i to it, we observe the following picture. All Stonex and Ruide receivers work normally and see about 35-37 satellites, and the solution uses 29-31 (but somehow their Chinese software does not inspire much confidence, although this is only my subjective opinion). As for Trimble R10 (and it seems to me that Leica receivers will behave the same way), no matter what I do, no matter how I configure messages in emlid caster, and I have probably tried all the options that are available, but Trimble R10 observes 26-27 satellites and uses 12-13 - GPS 7-8, GLONASS 3-4, Beidou -2 (always 2) and completely ignores Galileo. At the same time, connecting it to the local Cors system caster, Trimble R10 also observes 26-27 and uses 16-18 satellites including Galileo satellites (the local Cors system does not support Beidou).

Experiment 2:

The conditions are the same, the only difference is that we only change the caster to another free one, RTK2go. We observe exactly the same situation as I described above.

I have a guess, I don’t know whether you will confirm it or not. It seems to me that Emlid caster is based on Rtk2go, and it in turn is based on Rtklib. Am I right?

Experiment 3:

Now I use Ruide r93 instead of Rs2 as a base station!

I connect it to emlid caster. By the way, with such a connection, message 1230 appears in Ntrip checker. Just like in the first experiment, Emlid and Stonex receivers work the same way and give their maximum, and Trimble R10 refuses to take Galileo into the solution.

Experiment 4:

I connect all the above receivers to the local Cors system. All models, including Trimble R10, give everything to the maximum, observe and use GPS, GLONASS and Galileo in the solution (Beidou is not supported by our Cors system)

I deliberately did not set up an experiment where Trimble will be used as a base station, since a lot is written about this on the forum and not everyone is happy.

Also see the screenshots that I am attaching to this letter. The screenshots show the information that Ntrip cheker gives about the satellite groups observed by the base and their messages.

I am rooting for Emlid, I really like this company and its products, so I want Emlid to become the best.

P.S. Our Cors system uses Leica GRX1200.

[julia.shestakova]

Hi @geotimege,

I’ve done a bit more testing on it too. When I used Reach base, I indeed didn’t see the 1230 RTCM3 message in the NTRIP checker. However, when I checked incoming messages on the rover, it was there. So it should work fine:

This and the fact that you saw 1230 message when using another base confirms that there is no effect on it from the Emlid Caster side. In general, Emlid Caster doesn’t have restrictions for the data formats and particular messages.

@geotimege

I think it would be nice to add RTCM 1013 to the stream.

I searched for more info about it, and it seems to be quite rare in use. I’ve noted your request for it. But at the moment, we don’t have plans for this message.

[geotimege (Serj)]

Hi, @julia.shestakova !
Yes, you are right, with all Emlid receivers except Rx, everything works correctly.
I got interested in this issue because receivers of other brands, such as Trimble and Leica, behave a little strangely. One could write off this strangeness as a problem with the receivers themselves and their software, but for comparison, I connected them to our Cors and everything works fine, i.e. if when connecting Trimble or Leica to Emlid caster, for some reason they do not take Galileo satellites into solution, then when connected to Cors, everything is normal.
The only logical option is to think that there may be a difference between the caster settings.
To determine this difference, I started using NTRIP cheker.
NTRIP cheker showed that two messages do not reach it through Emlid caster, these are 1230 and 1013 (this is clearly visible on the screenshots that I sent earlier). It is clear why 1013 does not come, but I could not explain the problem with 1230.
Attaching this problem to the Ntrip checker application itself also did not work, since the same message is read without problems from Cors.
Yes, I understand that in theory caster should not block anything, but the problems with Trimble and Leica, as well as the inability to attribute these problems to their software or something else, prompted me to write a letter to you and try to solve this problem together.
Considering all this, I thought that 1230 is not explicitly skipped by caster and maybe because of this it is not perceived in Trimble and Leica and therefore Galileo satellites are not taken into account, although on the other hand, as far as I know and all open sources write about this, 1230 only concerns GLONASS, but the fact remains a fact. If the same messages are sent via Emlid caster and caster Cors (except for 1013, but let’s forget about that for now, since emlid doesn’t support it yet), then why are Trimble and Leica behaving so strangely?

I really want to blame it all on their software, but unfortunately I can’t do that yet.

Any ideas on how to solve this, is there any similar experience?
It seems to me that solving this problem will be received with enthusiasm by many, and will only add users to Emlid.
I reread all the threads on the forum concerning this topic, but I didn’t find a solution.

[julia.shestakova]

I just did a similar test using Reach RX with Reach RS3 base via Emlid Caster, RTK2Go, and local NTRIP Service. In all 3 setups, Galileo satellites were used in calculations on the unit. How did you check it in your test? Why do you think that they were not used on Reach RX?

Speaking of Leica or Trimble, I can’t conduct similar tests with them. But I’d first try to understand what’s going on with Reach RX in your tests. Perhaps, it’s something related to the configuration and will also explain the case with Leica and Trimble rovers.

One more thing here is to understand what RTCM3 messages are required from their side. Have you checked it? I agree that the 1230 message is related to GLONASS. So I don’t think it can affect the issue. Still, it is worth checking which messages are needed for Galileo calculation on 3rd-party receivers.

[geotimege (Serj)]

So I conducted a test with Emlid Rx, watch the video screen. Emlid RS2 is used as a base station. Corrections are broadcast via Emlid caster. I am attaching the database settings to this letter as a photo screen, and also attaching a CSV file with measurements. Emlid RX does not use Beidou in these measurements, although if RS2, RS2+ or RS3 measurements are carried out in the same place, they use all constellations of satellites. If we test with Trimble or Leica in the same place, connecting them to the same base, they use only GPS, Glonass and 2 Beidou (always 2). Unfortunately, I can’t upload the CSV and video screen here, so I sent it to you at support.

[geotimege (Serj)]

As for the question about what messages Trimble and Leica need, in this configuration, look at the screenshot, everything works.

[julia.shestakova]

You mentioned previously that only GLONASS and GPS satellites are used on Reach RX. However, based on the CSV file, Galileo is also fine. Did you initially mean Beidou?

The CSV file you shared with me does not contain the number of Beidou satellites used in calculations, and I noticed the same behavior in my tests. I clarified what was going on with the developers. There is indeed a bug with outputting the number of used sats to the CSV for Reach RX. Devs are already working on a fix for it. Still, Beidou satellites are used in calculations on all the units. I’ll keep this thread posted on how it’s going.

@geotimege

As for the question about what messages Trimble and Leica need, in this configuration, look at the screenshot, everything works.

I see, yes. Emlid Caster can’t affect the streamed data in any way. So I’d try to focus on the exact messages needed for your 3rd-party receivers to have Galileo working to investigate it further. What are the models of the receivers you work with? Which RTCM3 messages do they need to use Galileo in calculations?

[geotimege (Serj)]

Sorry, maybe I formulated the question incorrectly earlier and that’s why you misunderstood me.
I said that GPS and GLONASS are used only by Trimble and Leica and they don’t see Galileo at all, and Beidou only sees two satellites, always two satellites no matter what location you’re in.
And RX doesn’t use only Beidou.
As for the messages for Trimble and Leica, I’ll clarify everything again and get back to you.

[julia.shestakova]

I see, yep! Well, speaking of Reach RX, as I said, Beidou is used in calculation. It’s just the thing that the info about the used Beidou satellites is not output to the CSV file. We will fix it.

And yes, for Trimble and Leica, let me know their exact models or which RTCM3 messages they need to use Galileo. By the way, do you also see that Galileo is not used on them when you connect to the RTK2Go?

[geotimege (Serj)]

It’s cool if Rx uses Beidou and the error is only in the formation of the Csv file. I’m glad that the developers are already working on this. Yes, on Rtk2go, Trimble and Leica behave the same way (that’s why I thought there was a connection between Emlid caster and Rtk2go). Regarding messages for Trimble and Leica, I’ll try to find as much information as possible and write to you.

[geotimege (Serj)]

Hello, Julia!

Sorry for not answering for so long, I was looking for information on your questions.

Regarding the exact Rtcm messages for Trimble R10 and Leica.

All official sources say that standard Rtcm messages should be enough. I also talked to other Trimble users, they said that MSM4-MSM7 should work correctly, but the fact remains that something is missing, they said that maybe the caster does not have enough message length and therefore the rover cannot pump them (this was their guess, how much this corresponds to reality I do not know).

From my imperial observations and comparisons I can say the following.

Oddity 1. For some reason, message 1230 is not registered by Ntrip checker if this message is generated by Emlid Rs2, while this same message from the local Cors system generated by the Leica receiver is identified by Ntrip checker without any problems, and this same message is also registered from a third-party receiver connected to emlid caster.

Oddity 2. When connecting to the Rs2 database, Trimble Access software identifies the stream as RTCM 3.3, although RTCM 3.2 is generated.

Oddity 3. When connecting R10 as a rover to the Rs2 database, R10 observes all satellite groups, but as soon as it receives Float or Fix values, it immediately discards Galileo, and also leaves two Beeidou satellites.

From comparisons of two streams (via emlid caster and cors system) I can say that the only difference is in the message 1013 and 1230 (for some reason 1230 does not register Ntrip checker if this message is generated by emlid receivers), while from the cors system receivers of all brands work correctly.

As for the question about the models:

Trimble R10 model 1 and Leica GS14.
The firmware on the Trimble R10 is 5.22.

[inkar.madikyzy]

Hi @geotimege,

Sorry for the radio silence here.

Just wanted to let you know that we’re still working on your case.

[geotimege (Serj)]

Hello @julia.shestakova and @inkar.madikyzy!
Thank you for continuing to work on this issue.
I have been trying to solve this problem all this time too.
Studying this issue I came to the following conclusion. Message 1230 generated by Rs2 is empty (see the screenshot I am attaching to this letter), that is why it is not displayed in Ntrip checker, and is also not perceived by Trimble and Leica receivers, and no matter how strange it may sound, precisely because message 1230 is empty, Trimble and Leica receivers do not take Galileo into the solution.
I looked for the value of the GLONASS phase shift (this is the information carried by message 1230) in open sources, but found nothing.
Please tell me this value and how to implement it in the flow generated by Rs2?

[inkar.madikyzy]

@geotimege, thanks for sharing!

I’ll need some time to check it with the devs team. Once there are any updates, I’ll be sure to let you know.

[geotimege (Serj)]

And I also think that message 1033 should not be empty