Normally you must also make a transformation of the WGS-84 system towards the terrestrial system (utm ground coordinates), so that the measurements made with the GNSS receiver are in conformity with the measurements made by the conventional instruments.
1 Like
Did you record the BASES Average Single coordinates of the first visit, then plug them back in on the next visit to remeasure at the same exact BASE mark?
I don’t think that is the issue in this case with the way he shot them in. If they were originally located with the Reach RS+ and then resected by the instrument the relativity should be the same. He should be able to consistently stakeout with expected tolerances with the Reach RS+. This is most likely a matter of GNSS precision and the quality of the RTK.
1 Like
Now I think your scenario comes in if he was using local grid, collected those points with the instrument off the ground coordinates and then tried to match them up… That’s what happens to me all the time when I try to localize to the network our surveyors already had setup. It would be nice if I could just import there localization file… Ok, back on topic. 
1 Like
Yes Fix and Hold
the same base
Wonder if you need to measure a THIRD time all the good, the bad (and the ugly) points? First FIX AND HOLD, then CONTINUOUS to see if something weird is still happening. (Third time’s a charm… or it’s all just effed up).
I don’t think your holding your mouth the right way, or the planets haven’t lined up just right. ; )
They were not just simple checks to see the quality of the measurements. It is very rare what happened I always have a difference between 1 and 2 cm with the total station by the cartographic projection. I noticed it for the first time when I wanted to check a stake I had put weeks ago! It’s like you say a fixed false. And I clarify that it is when I make a stakeout of a point already measured, only twice I pass. once with Lora and once with Ntrip
I would temporarily leave the total station out of the equation for now. Re-check using ONLY your RS+ BASE & RS+ ROVER via LoRa. See if you get very close results with either FIX AND HOLD, then try with CONTINUOUS. Once you dwindle that down, then you can use the total station or even your CORS station to compare again. It may just be a FALSE FIX, so CONTINUOUS should solve that, but you won’t know until you try.
Thank you ! I will try it and I will comment.
unfortunately I do not have CORS available to a radius of 15 km, I can not do that test. I’ll do it when the RS2 arrives
No worries, just use your (2) RS+ BASE & ROVER via LoRa so you can rule out if there is a problem with the receiver(s) or the RTK settings etc. Then go from there.
1 Like
https://drive.google.com/file/d/1DlcUwE_JZhV2xVeQYu4_BfHv0Jta9i9m/view?usp=sharing
These are the data of the second day of survey, always use the same work with which I could review points of the previous day with the same base in NTRIP.
You keep mentioning NTRIP? But you say you are not using CORS? Do you mean that you are using NTRIP with RTK2GO or something? Just a little confused here.
To clarify, do you have (2) RS+ receivers or just (1) receiver?
Thanks Luis, hope you get things worked out. ; )
Tim! I have two receivers RS + use youcors for NTRIP
2 Likes
Post process the raw file. If they come inline after that, it’s the latency most likely. If you’re on LoRa, at 1100 meters with the stock radio, I’d expect it to cute cut out often. If you need very accurate points, they should be done post-processed as a static survey anyway.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.