Good morning, first I like very much reach rs, we use it with ntrip correction from spin gnss station of region Piemonte Lombardia.
In the field everything goes well, sometimes some problems to have fix but no much.
I try to post process data to correct the floating’s points, and to verify the fixes.
I try with rtklib, both version, emlid and the version that I find here: rtklibexplorer.
I try with default setting like that suggested in emlid guide, and also settings suggested in rtklibexplorer.
I can’t have the same results, perhaps I can’t ‘have the same fixes I had in the field.
Also some fixes are non in the same position I had in the field
I try both combination, the first one with the data downloaded from the site of spin gnss from the closest station, the second with the data recorded with reach rs.
I don’t understand what I’m doing wrong.
In attachment the file that I use. https://we.tl/t-q6QDANEuri
There are few thing you can check first.
1.Is the coordinates from the refrencestation the same for all processes? (check rinex header and compare with result on all output solutions)
2.There are som quirks in RTKlib. I delete the RTKpost.ini file before every new process. I also close the app and reopen it before i run the process BUT after all settings has been applied.
1.Is the coordinates from the refrencestation the same for all processes? (check rinex header and compare with result on all output solutions)
Yes
2.There are som quirks in RTKlib. I delete the RTKpost.ini file before every new process. I also close the app and reopen it before i run the process BUT after all settings has been applied
I try also this option but no substantial difference
The strange thing is that the first 7 points are correct, after 10:20, maybe after some noisy data, rtkpost fix but are different from field solution, as you can see in the image. I check the quality of field solution, the coordinates are correct. I try both fix and hold and continuos for gps data, also glonas fix and old or on, in all the pissible combination, also forward solution and reverse and combined.
Excuse for my bad english
thanks in advance
Ok, that rules out a couple of thing.
So the RTK fix is correct? and processed one is wrong?
Try raising the Elevation mask angle. Sounds like multipath is throwing your points of.
Try raising the Elevation mask angle. Sounds like multipath is throwing your points of.
Seems is not this the problem…
Also I notice big difference between results if I use raw data recorded from reach rs and rinex downloaded from the server…
thanks for your reply.
Yes I mean I tried both: with data recorded on ta and also with data downloaded from server afterwards
Yes in the field I use only one reach ts with rtk from ntrip server. In the WeTransfer there are both.
This is normal as recorded correction data on RS is compressed and sometimes stripped for information (either from the service or the reciver it self) to get the data fast enough out from the service, over the internet and downloaded to the reciver. The raw file you download usually contains alot more data and could process better result, hence post process usually get you better result.
Now, looking at your data there are few things.
1.Using ntrip and a station 12km away in RTK, you will lose some accuracy, i would use more time at each point and consider static mode if signals is poor.
2.Looking at numbers of usable satellites you have about 22 visible at 10 degree mask angle but only 8 good ones after SNR mask is applied (SNR mask at 35). Most of your 8 satellites is below 40 degree has bad SNR (below 45) value which leaves you with few usable high angle satellite and this will not give good accuracy either.
3.Based on you survey and use of ntrip with long distance to base which only gives GPS and Glonass correction, i am confident that use of a second RS acting as local temporary base (you can stil use ntrip with the same refrencestation to establish a known point) and transmitting LoRa with GPS,Glonass,Galileo and SBAS woud give better result.
With a second RS you would also benefit from low angle option with glonass AR enabled. Not sure you get this with other system then reach ? @emlid
WIth glonas AR enabled you system is more robust against multipath.
The setup you have used is pushing limits of what is doable with RTK and the long baseline (12km) under normal condition. Your logs shows conditions with poor receptions which higly influence your accuracy.
And as mentions earlier, changing mode to Static is a quick fix for a solutions with only one RS available.
And for the difference in your points, this is normal as postprocessing will give you different result depending on setting and quality of you data recorded
First, thancks for your answer.
Seem’s that there is no strange things in my problems, so i try some of the advice…
The only thing is thet in my test’s working better with row data recorded from reach than with the data downloaded from server…
Maybe we buy another unit, for us is difficult because i cant’t leave an operator to watch over…
we have, in some circumstance problem with thieves…
auguri a tuttti buon 2019
