No fix on RS2 via NTRIP

Hi! I am from Poland and I use RS2 only in Rover mode (using NTRIP). I have a problem getting FIX. I tried corrections from two suppliers. One is quite good - FIX obtained after about a minute. However, from another supplier I have been waiting for FIX for a long time. Even if you catch FIX, it quickly goes into Simple mode (corrections are provided). Can you check it out and do something about it? The supplier spreads his hands.
I tried different programs - Fieldgenius, SurvCE, Quickgnss and through the SIM card in RS2 and entering the NTRIP address - every time the same effect.
I use GPS + GLN + GAL + BDS corrections in RTCM 3.2 format

Can you post the raw-log from the rover along with the recorded base-corrections?

Tomorrow I will try to send files for both cases

1 Like

Hi Marcin
Test the Polish programme RTK PowerGPS he is he integrated with receiver set RS2.

R2

http://powergps.pl/
I think, that on the system ASG-EUPOS he should act (using NTRIP).

from my observations it is not the fault of the software. it all depends on the correction provider. I know from my colleagues that the supplier ASG Eupos and Vrsnet work well. I have a problem with corrections from RtkNet. I also did a test measurement on a tripod and there are very large differences between the coordinates (checked on corrections from RtkNet and Nadowski). Soon I will put the results

I put logs below

raw

base

Has anyone checked the logs? I have some conclusions:

  • for me (and other colleagues in Poland) version 2.22.2 works best. There are problems with the NTRIP connection in version 2.22.3
  • rs2 works fine if I connect to NTRIP via ReachView using the built-in sim card. If I send corrections from another program via bluetooth, it is a bit worse, and some correction providers do not work at all.
  • generally there is a problem of long waiting for the first FIX (sometimes even 5-10 minutes).
  • from time to time rs2 catches FLOAT - accuracy is good, but it can’t reach FIX - then I turn the receiver upside down and FIX reaches very quickly.
  • a similar situation is with catching SINGLE- sometimes rs2 falls into single mode and I have to wait a few minutes for a re-fix - even in an open space

I don’t know what has changed in version 2.22.3, but it works much worse with NTRIP and RTCM3 corrections than version 2.22.2 for me.

I took a look at the data.

A few observations:

So it seems that either the RS2/Rtklib doesn’t understand the messages from the NTRIP station, or the NTRIP station sends wierd stuff?

Thank you for checking. What do you suggest to do in this situation? Change provider? Try to use observations from a single station? Until now, I have worked in RTN mode and used a virtual station.

I’d say change provider. I see you already with the provider, so you’re probably not gonna get far there.

Ok. I tried another provider yesterday and I also had trouble catching FIX. I will try to upload logs in the future, if the situation with getting FIX repeats.

1 Like

Hi Marcin,
And here it did so well in tests,


you worried me because I just ordered it RS2
Regards A.G.

Do you perhaps have a different mount point or port to try that outputs a set of corrections different from “GPS + GLN + GAL + BDS”? For instance, just GPS+GLO?

I don’t have another port, but I can test GP + GLN corrections.
I also checked other providers and it was different - sometimes better and worse. But every time I had a situation with a long wait for FIX and falling into SINGLE even in an open space. It seems to me that it was a problem of compatibility with messages from base stations.

Can you make a screenshot of your corrections input menu with the messages tab expanded, so we can see what messages are being sent ?

Today I did a lot of tests and noticed an important matter. Everything works perfectly if I use GPS + GLN corrections. If I use GPS + GLN + GAL + BDS corrections there are very big problems getting FIX. I tested corrections from three different suppliers and there were problems with 4 system corrections everywhere.
So I think emlid rs2 has a problem with GLN and BDS messages.
Below are some screenshots

I made a mistake in the description. I meant problems reading Galileo and Beidou messages from base stations.

If you need any tests, files or logs, I will gladly do them to solve the problem

I analyzed Galileo and Beidou messages sent from various providers.
Supposedly rs2 works without any problems with the ASG-EUPOS provider (he sends MSM5 messages 1095, 1305).
Other providers I’ve checked use MSM4 1094 and 1124 messages. Is it possible that rs2 has a problem with this message format?

Soon I will buy access to ASG-EUPOS for a week and check how 4-system corrections work.

1 Like

I carried out more tests. I bought access from another ASG EUPOS supplier and checked various mounting points.

My conclusions:

  • on RTN corrections (with virtual station) GPS + GLN everything works fine.
  • on RTK corrections (from a single base station) GPS + GLN everything works fine.
  • GPS + GLN + GAL + BDS corrections work well, but only in RTK mode (from a single base station)
  • RTN corrections in the GPS + GLN + GAL + BDS system do not work properly from any supplier (long wait for FIX, then FLOAT jumps quickly and problems with obtaining FIX again - even in open space). Both MSM4 and MSM5

I checked the suppliers: RTKNet, Nadowski, VRSNet, ASG-EUPOS
I checked the programs: SurvCE, Fieldgenius, Quickgnss, RTK PowerGps
I checked the corrections: from the built-in GSM module and sent by BT
I’m using firmware version 2.22.2 because it works best.

Interesting fact: only RTK PowerGps works properly! Corrections sent via BT. The RS2 immediately caught FIX and was maintained even in difficult conditions. The program has a special module for Emlid RS2.
It seems to me that programmers need to somehow modify the messages sent with corrections to RS2 in a way “understandable” for the device.

Is the EMLID team able to do Log analysis and adapt RS2 / Rtklib to messages received in RTN mode for GPS + GLN + GAL + BDS systems?
I can take a measurement with a log record for this purpose.
Please answer - the matter is urgent!

1 Like

I installed the latest 2.23.4 update and did the tests today. it looks like RTN corrections with GPS + GLN + GAL + BDS are working properly!

2 Likes