After some months waiting for the new stable version, I updated RS2 to firmware 2.24
I mounted the RS2 on a static point on a tripod and connected it via NTRIP to my nearest Caster (53 km) with a SIM card and mobile data, and left the RS2 there for almost 2 hours (until the rain came) .
First it took almost 20/30 minutes to get FIX, and then I expected the Z value to stay the same, or change a small amount, but for 75 minutes I could see a difference of about 1m between the minimum and maximum Z value. All the time, the RS2 at the same point and FIXED solution.
Z value for “Position” from the “Solution LLH” file. 1m difference over time
These are the values of points recorded with Reachview 3 every 15/20 minutes:
I know I am on the NTRIP limits with 53km, but it is the closest station I have and I was not expecting such differences.
- Is that normal?
- Can I improve it?
- If I buy another RS2 (I´m not sure at the moment), can I expect the same performance or using 2 equal antennas and shorter distances may be better and I’ll have reliable RTK?
I’m running these tests to see if I can trust RTK for real work.
Here are the “base”, “solution” and “raw” files from RS2 and the Obs/nav files from the 53km Base.
Any opinions are welcome.
It seems the Rover file only has GPS obs in it (also some GLO, but not usable for some odd reason). Enable all available constellations.
Do you have the .UBX file?
I can’t even get a fix using the rover-data provided.
I did the same test with 2 brand-name receivers. A Sokkia GSR2700ISX and a Spectra Precision Epoch 35. Both are based on the same Novatel OEMV board.
I connected both to my local NTRIP COORS which was sending corrections from a VRS that was about 5km from the receivers.
I collected points for about 2 hours in 10 sec interval and then did a simple statistical analysis.
The variation in Z was about 12cm in one occasion.
The next test was by using sokkia as base station and epoch 35 as rover. The baseline was 1km.
The results was much better by reducing the Z variation in 6cm.
I attach the tests.
epoch-sokkia-test.zip (59.6 KB)
A 53km baseline is very long even for a multifrequency system but I think the variation of 1m is too much. Maybe the Internet connection was not very good?
Anyway by using small baselines you will get better results for sure.
Maybe someone with 2 RS2’s can give us some light?
Yes, it shouldn’t work that way. Thanks for the logs! I’ll thoroughly check them and get back to you with the results.
In the meantime, could you please share the .UBX file as well?
Yes @wizprod and @svetlana.nikolenko, the Rover Obs file has GPS and GLO because when I converted the UBX file I selected that 2 constellations, that are the same that the Ntrip Base transmits. The RS2 had all constellations enabled.
Here is the UBX file:
Thanks @vgo195 for your tests, I’ll take a look at them. And that´s the big question I have: what results would I get using 2 RS2 at a distance of 2/3km (usual ranges in my jobs) running the same test? As you say, someone with 2 RS2 maybe can give us their opinion.
What Software do you use here? Is it U-Blox u-center?
Still float here… How was base-data derived?
I tried going to http://www.sgm.gub.uy/geoportal/index.php/estaciones-referencia/estaciones and selecting the station, but can’t figure out how to download the data?
Hi @wizprod, I downloaded them from an ftp server, they are in 1 hour files and I joined them with the program Teqc.
Here are the original 1 hour zip files:
@Nordstern, I use Rtkplot, from Rtklib-qt-win-v2.4.3b33 downloaded from Emlid website.
Just tried again, tweaking the angle mask to 20 deg, and processing as kinematic instead of static did something. Now up to 75% ish fix rate.
But from 20:45 it gets wonky and floaty again.
@wizprod Would you mind sharing your Rtkpost settings? I tried with different configurations and still get Float.
Anyway, the behavior on RTK is still strange, we’ll see what Emlid team says.
2 posts were split to a new topic: How to download files from Reach
I think your problem is overall low PDOP…
And at 20:45 it got critical (PDOP is >4, it should be <2):
Here is the resulting pos file after quite a few tweaks here and there in the settings:
Here are my settings (running RTKlib B33c, as RTKpost QT can’t use the wildcard-combine-method for the multiple base-file):
Thanks @wizprod! I´ll try with those settings.
It seems that the variation in Z after post-processing is about 30/40cm, while in RTK was about 1m. It´s better, but still not a good variation for a “Fix” solution.
And about PDOP, when I can I will try to repeat the test to see if I get a better geometry of the satellites. I don´t remember right now, but does Reachview have an indicator of PDOP while doing RTK?
It doesn’t. In light of this discussion, it would be a good addition to both the Survey and Status pages.
While collecting a point Reachview shows the PDOP value
Oh, right, that’s true, I forgot about that.
About PDOP value, Reachview 2 shows it, while Reachview 3 doesn’t (or I couldn’t find it).
I run the same test again. This time Fix was faster. The RS2 was static on the same point for about 1:40 hour, and now variation in Z was less than the first test. There is a “jump” at the beginning and from 14:07 the maximum variation is about 15cm.
It´s not perfect, but for 53km baseline maybe is reasonable. Variaton in E/N is about 4-6 cm.
Z value for “Position” from the “Solution LLH” file. 15cm difference over time.
These are the point values recorded with Reachview 3 every 10 minutes:
Post-proccesing the files, the Height value for the point is 20.53, so the question that I still have is:
Why running the same test twice give so different results? I mean, in test 1 I had almost all the time a FIX, but with 1m difference in height. Same location, point and Ntrip base as in test 2.
Here are the files is someone is interested:
this one seems to process much easier. However, Looking at GPS alone, you still have issues with your PDOP.
However, I still think it somehow the ntrip playing up. Can you get between 2 CORS and process against both in PP?
Hi @svetlana.nikolenko, could you check the logs? Any update you can give us about this Z value drift?
Sorry it took too long. I’m still looking into that. I’ll write you back as soon as possible.