Our archeological project is using a Reach RS3 this year. It is receiving corrections from an NTRIP service. In previous years, we have used a pair of RS+ units, with one as a local base station. We established the coordinates of the base station based off of known points from an earlier archaeological survey. Our coordinate system is WGS84/UTM 36N
The points we have taken this year using tbe NTRIP are all about 4.2m east and .85m south compared to our previous points taken with the local base station. I have seen this by comparing coordinates of fixed points (like trench corners) taken last year and this year.
I normally would assume that the NTRIP is more correct. However, in overlaying our previous points onto high resolution safellite images (where our trenches are visible), the data seemed nearly spot on. When we overlay the new points taken using NTRIP corrections, the points no longer line up with the image, and are shifted east and slightly south to where they should be to line up with the image.
So, how to proceed? Trust the NTRIP? The NTRIP base is about 19km away. Could that be the source of the problem? Should I try using a virtual reference station?
We shot in the base station by first using a known point from an earlier archeological survey as a base. The points from that survey (from the early 2000s) used survey datums established using a single average solution. That is possibly the source of the error.
What gives me pause is the relationship to sattelite imagery, where the old data seems to line up more accurately than the new.
Sounds like a classic datum mismatch. Might be different in your location but base coordinates and therefore the corrections they send are normally in the local plate fixed coordinate system so check that out first. A few meters difference is typical.
Also bear in mind that the plate you are surfing through WGS84 is leaving those old WGS84 coordinates you are clutching somewhere in your wake. They may no longer be where you think they are on the ground to one extent or another and the difference continues to grow over the years. Here it’s 7cm a year.
A local plate fixed datum comes along for the ride and the coordinates don’t change, that’s why CORS normally use them.
What coordinate system, (horizontal and vertical) (and geoid) is the NTRIP service using? The RS3 and NTRIP service must match.
Also, sounds like all the measurements made up until the NTRIP service are based on SINGLE averaged (your assumed made up “known point”) using your own pair of RS+ units. So all those points are offset incorrectly in the real world by a few meters in all directions (and when used with NTRIP service).
You’re lucky your old points are even matching the basemap imagery??? Is it your own drone basemap imagery or something else?
If your NTRIP service is reputable, and your coordinate systems MATCH, than that is what you should be using here on out and may need to measure some old points again and shift the old to new and see what kind of differences you get over 24 years of time. Obviously do this with seperate CAD files so you don’t lose your old data.
Not sure, but the NTRIP service may have already changed over the NEW datums coming up??? Provide what you find out about the NTRIP service datums.
Wondering how EMLID will be handling this new datum change coming up.
Yes, but it turns out the NTRIP is just in WGS84, not the Greek grid (EGSA87) as I had thought. That the stations on Cyprus are in WGS84 has been confirmed several times by the company representative. So at least much of my original question from the earlier thread should be moot.
Knowing how your baseline control got there is paramount. Normally you can rectify the data to make them align but you have to know the datum and make sure it’s not rotated and/or scaled. Not as significant when you are working small sites but still throws a wrench in the process.
You are dealing with a lot of moving parts that are compounding your challenge:
Unknown/flip-flopping local datums
WGS84 diverging fast, you are on a very active plate boundary
Existing data based on rubbery autonomous (single) positions, and
Existing data collected over a long time frame (decades of drift)
It’s not clear from either thread if you have already done so, but it would be a good idea at this point to take a breath and literally put a stake in the ground to help start figuring some of this out.
For example even AUSPOS can provide you a robust ITRF 2014 position utilizing regional IGS stations that you can trust, not from the local networks.
If you used the point of your previous local base you could shift/correct that data
Use it to validate the integrity of your NTRIP corrections, and potentially confirm whatever datum it may actually be using.
Use it to shift and align your legacy data to current epoch if you have it’s collection dates. If not, rounding it all up with a rough shift from sampling could be better than what you have now.
Use it for future shifts or transformations once you sort out a plate fixed CS
And going forward, record it with your rover every collection day at minimum as sanity check, and potentially detect and correct blunders. Your provider could also decide on a whim to use yet another datum next week and you wouldn’t know. Could save a lot of hard work.
In your muddling’s remember that that even if your NTRIP source was coordinated WGS84, it’s moved. I say was because for any computations you need to factor in the coordination date (epoch) to figure out how far it’s travelled.
You have good equipment capable of providing differential to the cm level, do it justice. Even in one year your NTRIP base will have moved many times more than that.
I would also be asking for a certificate or other confidence in the bases alleged coordination & date. Maybe it was WGS84, but was it also autonomous…and not even averaged? Unlikely, but the point is you just don’t know.
I’m continuing to work on this issue. But I also wanted to check as to what degree GPS jamming/spoofing could be affecting our results. Cyprus, especially where we are working, has been regularly subject to GPS spoofing, with the Emlids (and our phones) showing a drastically and obviously wrong location (it’s always the Beirut airport). I don’t get a fix in this situation, obviously, and am usually floating or have no solution. Once the spoofing event is over, the RS3 (and our phones) are back in Cyprus and I can get a fix.
My question is, to what degree can GPS spoofing (as well as more general jamming, which I’m sure we’re getting too) affect the specific accuracy of measurements, even when we have a fix solution. Our heights have been all over the place it seems this year, with points taken at the same location over three minutes showing a variation of 10+ centimeters. This is giving me pause as to whether it is possible to get any cm-level accurate measurements given the level of interference. We had assumed that once the spoofing event is over, we were okay to take points because we had a fix solution. Were we wrong to assume this?
Highly unlikely, as you’ve seen spoofing impacts by design are at the gross end of the scale. And remember they are based on the code and not the cm carrier phase level. And even if they could, I don’t really think anyone would be spoofing a specific point 10cm from your location…unless of course you are particularly unpopular there or start seeing airliners approaching your RS3 to land. In which case forget the data and run.
Interference a little more open but again unlikely. To get a fix the software needs to see a lot of things finely line up with a high level of confidence to the next nearest possible integer so any serious noise would more likely result in no fix.
I would be looking to closer to home, normal domestic issues there would be far more likely. For example, other than the plethora of other issues in the posts above, those orders of magnitude would be more typical of multipath if you had any large walls or rock obstructions around? As the SV orbits continue, the incident angles and therefore the reflections from fixed obstructions change and thus the potential variability of the results.
It’s great to see the ongoing discussion in this thread!
@tpl124 This will be the first concern is that the known point you are using as a base might be based on a single solution. A single solution provides meter-level accuracy. Meter-level error in all directions is expected.
Since you have internet coverage in your survey area, if you have confirmed that the datum of your NTRIP service aligns with your project settings, you can try averaging Fix for the base position and overlaying it with the latest satellite imagery.
