Hi
I use emlid reach m+ in ppk mode and use a base with known location . but i always have a fixed error (about 1 m) in check point . what is reason ?
base location and check point first collected in rtk mode with cors correction
Is known location in WGS84?
Yes, it is in wsg84.
Let us be more specific then.
Your base:
You use known location with the same coordinates each time.
Is the base precisely located over that same point each time?
Your rover:
Other than 1m offset, what is the difference between the set a,b,c and a’,b’,c’?
Do both sets represent measurements taken with M+ or is one set from a different data source?
Is each set surveyed at a different time?
Is each set surveyed on a different day?
Have the M+ been rebooted between each set?
Does a,b,c represent permanent marks on the ground that don’t move?
How long is the baseline (base to rover measurement)?
Are you absolutely sure that nobody has moved your base station?
1 Like
In addition to what @bide has already asked, are you sure that the RTK (ntrip-provider) was also working in wgs84 and not in a local system?
1 Like
base :
base location and a , b , c are known in same coordinates .
base precisely located over that same point.
rover :
distance between a,b,c and a’,b’,c’ is 1.5 m and it is correct.
second set (a’,b’,c’) surveyed on a different day.
distance from base to rover is 1.5-2 m .
base don’t moved during observation.
I tested this because we had this problem several times in photogrametric application.
base and a,b,c collected (fixed) in same time in RTK mode . does it matter location of nrip-provider ?
So I am beginning to understand. Between CORS and Reach you get one point, and between Reach and Reach, you get a point 1 meter away.
Cristian is probably right then. It is a problem with the coordinate system of the CORS provider and not compensating for it before using it with your Reach base station.
First of all we need to know how the base point was established? Using an ntrip provider? Cors data?
The offsets are in 99% of cases due to base offsets, in some way or another. And there quite a few ways 
1 Like
Let me assume from the information gathered:
1 Reach with NTRIP corrections:
Establish a point for base.
Establish 3 points for rover (a,b,c)
Done that.
Now, 2 Reach used. One as base used with coordinates that were determined from above.
Rover moved to points a,b,c and those coordinates written down as a’, b’, c’.
A 1 m error was noticed between a and a’ and the same for b and b’ and c and c’.
That is my interpretation of how it was probably done. Please correct me if I am wrong.
1 Like
So if that is the case, then I would assume a transcription error in recording the 1st base coordinate when hooked up to NTRIP.
But like you say Christian, there are many ways this could happen…
I think to help further, that the same work should be repeated again and all the log files uploaded for us to check.
All are correct
1 Like
I can upload this test log files . Do you need this ?
Please do. Also remember to post The base position.
It is not an antenna problem, it is base-position problem, most likely related to how your base coordinates were derived.
I will take a look at your data.
1 Like
I see the same shift. When you measured your RTK base point, what RTK/NTRIP did you connect to ?
I see that CDDIS have a CORS in Tehran, TEHN, however it seems to be 24H behind, as yesterdays data is not yet available.
Tomorrow, when it should be available, I would suggest your try processing your own base-log with that TEHN obs file.
http://www.onpoz.com/Support/BaseStations.aspx (choose IGS/CDDIS)
1 Like
Yeah, can’t see the obs fil just yet on the server. Maybe tomorrow or later today, not really sure how frequent their update routine is.
Can’t access the url, “503 Service unavailble”, maybe getting blocked ?