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:
https://we.tl/t-NZVrTGVpPq
@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.
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:
https://we.tl/t-x7lXDQm7hn
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?
Thanks.
Hi @Doppler_Uav,
Sorry it took too long. I’m still looking into that. I’ll write you back as soon as possible.
I don’t know… 53km for a base is kinda pushing it to the limits. We use Javad receivers and even in a 20 point network we just completed, most of the baselines were about 10-15 km apart. This was a two county project for aerial mapping for the state. Overall accuracy per point was less than 0.01cm vertical/horizontal, static observations in clear sky environments, 1-hour observation per point. I even used my 2 M2’s on two points as a check, great results with them using the HARXON-HXCGPS500&NONE antenna.
As a side note, we even included three CORS in the network, all of them were less than 10km from the main points. Most of the CORS in our area are spaced about 30km maximum distance.
You need to look at Reach’s data sheet for their machines.
Hi @EBE111057,
Yes I know 53 is not the best distance, but is the nearest CORS I have, so I can not run the test at a shorter distance.
What I was trying to figure out is why the RTK solution was “Fixed” and the Z value changed through time, 1m in 1 hour. I would prefer it to be “Float” or that Reachview gives some warning that the “Fixed” coordinate may not be good.
I would like to have 2RS2 to run the same test at a logical distance (2-3km) but I don’t have them.
I do have a M+, so maybe I’ll try with the Emlid Caster Beta and RTK to see what results I can get at shorter distances.
Why not establish your own CORS for the point you have… You sure enough have the data to determine precise positioning. I would simply PP the data you have with surrounding CORS to determine the position. You’re not getting anywhere with a 53km RTK baseline… atmospheric issues and other factors will limit any RTK value that you’re getting now.
Hi @EBE111057,
I tried that, using that point as a base for a M+ on a tripod, and using RS2 as Rover, with Emlid Caster Beta:
But was difficult to get a Fix. I still can´t get reliable RTK.
I’ve got two M2’s (dual freq) that I use as static receivers. You really aren’t getting the benefit of having an RTK or RTN system if M+(single freq) is base and the RS2(dual freq). It may not even work from reading on the forum. Best to use dual freq. for both receivers, greater range, stability. You have the option of LoRa, which I haven’t tried yet as I have mostly Javad gear here. There are some simple settings for the radio’s listed on Emlid’s site here. I’d advise you to read thoroughly thru the recommendations.
I’m planning on buying the LoRa soon as something to experiment with and possibly to set up a base via internet, doesn’t look that hard; just haven’t had the time.
Hi @Doppler_Uav,
Thank you for your patience!
The behavior you experienced is not natural for Reach receivers and rather unexpected. I’ve checked the logs, but it seems we need more data to investigate it further.
Bryan and Christian are right: with such a baseline, the number of common sats you have may not be enough, and you may experience difficulties with calculating fix solution. Still, such conditions should not lead to the situation you encountered.
During our tests, we were unable to catch such behavior. So, it would be very useful if you can help us by collecting more data. We have the Raw data debug option in the ReachView Settings tab. The logs recorded with this option enabled have additional info that can help to determine what went wrong.
Could you please turn this option on during your next test? Please share these logs with us.
Thanks for your response. I´ll try with that Raw data debug option next time.
I hope I can see some strange behavior to be able to analyze it and find what went wrong in my Test 1, but I’m sure if I want that to happen, everything will be fine, like my test 2 
