Interesting stuff. I’ve had to learn some of the intricasies of coordinate systems while using QGIS. I’ve not thought too much about it in terms of base stations or the commercial systems like RTX and SF3. All of these things, even WAAS come from ground references all on the same continental plate, so after they were determined at some point in the past, any GPS receiver that corrects using those services will stay fixed year to year despite the continent drifting. At some future point when a new datum is chosen, I assume everything will change slightly.
Honestly I don’t really care what datum I’m using. With QGIS I could translate the google imagery to line up with my own GPS coordinates and get what I want, instead of using Google Earth, although Google Earth is easy to use. Does not seem like Google Earth is a good tool for any kind of GIS or AOG work, though.
I’m not sure I care about PPP either, honestly. I think what I might do is compare my F9P RTK position with Trimble RTX and adjust my base station’s position until I get within a cm or two of RTX. That way when I have an issue with RTK on my Trimble 372, it will fall back to satellite-based RTX for 20 minutes, which should end up being close to my RTK line. Right now when I switch to either WAAS or xFill RTX on the 372, it’s off by a few metres from RTK.
Not a topic for this discussion forum but wouldn’t one expect Trimble to fuse the RTX position with the RTK base coordinates? Why not with WAAS too even if the “WAAS location” drifts more. Mostly useful with movable base stations and a quick base location survey.
The datum topic explained above makes my head spin but isn’t that too an issue for fall back from RTK if the receiver does not know the base datum?
RTX is locked to RTK by using the WGS84 datum, when you fire up your 750 and look in the settings the default datum is WGS84, but I am not sure what epoch they reference. The epoch information is most likely sent to the receiver by the RTX satellite to sync.
WAAS is old tech that was meant to help airplanes land, it is a legacy platform that even airports are dumping for RTK.
WAAS also takes a long time to converge to get to its wandering and very low accuracy, coupled with no repeatability over times as low as 15min, its just not worth using. The F9P is more accurate in autonomous mode with much lower convergence time.
WAAS will make you jump more than anything all by itself, its right in its name “Wide Area Augmentation System”
The closest WAAS station to me is 1050kms, so the correction is extremely poor even on good days.
WAAS is also heavily affected by solar weather since it has such generalized corrections with so few ground stations. RTK tailors the corrections to the space weather directly above your head.
I have check local system is ETRF2000 more that I look at it worse it gets in my country they limited precision for coordinates to 5 decimals and free map with parcels is off up to 5m you cant buy them only surveyor can and he is not allowed to sell/give them.
Other options are @torriem way of lining up base cord with GE and take coordinates from GE or go to field and take measurements ? But its hard to get exact boundary as you don’t know if neighbor got into yours parcel and you moved to other side. Main advantage would be that fields line up with GE.
With WGS 84 PPP Base cord taken by rover are absolute and they are tied to base so if base drift in 10y 2.5 cm a year it will be off by 25cm but when i re survey base again to absolute cord those cord taken 10 years ago would lead to same spot ?
Same problem as GE you don’t know exact boundary of fields only where it is now.
Question is for @torriem way when GE map change he just measure new base position on GE and all cord will be good for new map ?
Only way to get precise field coordinates would be to pay surveyor to measure parcel then go to same points that he marked and take coordinates.
I am new to this are there other better way of getting coordinates ?
I’m not sure about that one! I assume so because the PPP stuff takes the drift into account. @PotatoFarmer knows more about this than I do!
There are survey markers you can find that may help in getting “official” numbers for surveying purposes. I found one near my farm but I’ve not been able to look it up to find out what coordinates it’s supposed to be at.
So surveys mostly use the concept of chainage, due to the world changing shape and measurement standards changing. Also because as you put it neighbours like to move the marks. Your land is not recorded as x,y coordinates per say. They are usually recorded chained off of local benchmarks that are set in local legal stone. Land surveys historically have pretty low resolution sometimes a foot or more, but everyone usually had a hedgerow growing in the zone of uncertainty.
If your marks after the survey are then recorded in the same WGS84 protection as google earth they will line up close, but they cap the accuracy at a meter. Probably most of the reason I’m seeing a west shift of the GE imagery by 1m.
All measurements in WGS84 need to be taken in the same epoch (time) or they need to get transformed in post processing between the epochs when they are taken. Why would google use a system that is always changing with time? because the imagery is watching the world change with time.
As long as you do not change your original coordinates you used your lines will not change, all future measurements with that base will be relative to the past measurement too. Do not loose your original coordinates.
Then why PPP? If your coordinates never matched up with anything at anytime it gets much harder to translate them.
If its a boundary disagreement with a neighbour a surveyor is always a yes. The easiest way to map fields is drive them in with your equipment.
Here is what a survey plan looks like with some notes, surveying is 33%art, 33% science, and 33% covering for all the mistakes done with much poorer equipment.
PPP is done to have absolute coordinates in that datum/epoch if base cord don’t change then they drift together and purpose for PPP is to have cord for transformation between other datum and epoch ?
which means that for our single base setup keeping everything in WGS84 will provide year to year accuracy, easy survey of fields. So for AOG its good enough to PPP base and use those cord forever.
I see local datum alot surveyor must transform local cord to wgs84 for surveing so for us it’s one step less.
How do you change datum to local, do you have to transform cord from gps back to local? do you have to use national corrections service?
As long as you use your current epoch PPP in WGS84 forever, your AOG lines will be the same relative to that base forever.
Though technically as time progresses the “real” coordinates are drifting, relative to the planet. Google earths pictures will be on the move too.
You can convert coordinate systems with gis software to varying degrees. You can also put your base coordinates in as the system you want to use, this will get you very close. But then some systems are based on geoid models and some are ellipsoid models that can throw a different curve in things.
NRCAN will spit out IRTF which is basically WGS84 or it can spit out NAD83 CSRS.
So with an emlid RS2 for example, i would PPP and get the nrcan results in nad83 use that for the base coordinates which sets the baseline. The magic now happens at the rover end. When taking a measurement the baseline pulls the coordinates of the rover in line with the nad83 grid, though the rover still is trying to compute a wgs84 position, this confusion takes a bit longer to fix, then once it has the coordinate the RV3 software gives it a nudge for the projection it is in and your on target.
Then finally the data can be post processed for errors, or be use in other modelling.
Accounting for all of these little subtle measurement issues are part of the big cost for very high end receivers like a javad, and gis software. But still does not justify a Starfire6000.
If RTX was locked to RTK, it should not jump away from the wayline when RTK was lost, irrespectively of the datum. I did not consider datum the only concern, more about the RTK base location survey accuracy. A quickly installed tripod might be metres off. RTX lock to RTK should take this error into acount too (don’t know if it does).
If the datums are different, your baseline will be different, and you will jump because of the offset.
If you lose RTK and roll back into autonomous there is no outside factor to cause a jump. You just drift slowly in float from the last fix until RTK resumes.
RTX is RTK, just the corrections come from a satellite instead of radio or cellphone. They still have bases, but also have some magic math to give you VRS style corrections.
Seems I cannot describe my point correctly and it does not belong to this thread anyway. One more attempt, say you run from one RTK base to another, one with correct base survey, the other one 1m off. There will be a 1 m jump at the change even if both are RTK. There will be a similar jump from RTX to RTK that has not been properly configures, even if datums are the same. What could be done? RTX cannot be changed but the receiver can detect the RTK error compared to RXT (at the time both are available).
That’s correct about the two RTK fixes if the base stations are 1m different, hence the desire expressed by those wishing to do official post processing to get consistent positions for their base stations.
And yes, if I have a tractor running RTX and a tractor running my own survey-in base station, they will likely be different. If consistency was desired here, the only solution is to adjust the base station reported position until the roving receivers are reporting the same thing at the same place. This is what I will likely do, rather than do a long survey and post processing.
As for you xFill, I do believe you’re correct that it must adjust the datum (if that’s the right term) so that when you flip to xFill, it’s the same position as it had with RTK.
And creating any kind of accurate maps with GE imagery looks to be problematic. Maybe with QGIS could adjust the a couple of field maps to line up and use that to draw boundaries.
The discussion belongs most definitely its all about datum, and measuring mud with stars. Here is a visual explanation of datum offset and how it causes the jump.
So to sync with RTX you need a Trimble receiver that can transform the position to one fixed epoch. The corrections from RTX are a moving target with time. So its up to the receiver to transform the position to a fixed point in time, and then the proper reference frame for even higher accuracy.
So if you wanted to sync your ag open to rtx you would have to PPP your base in the current epoch, then transform the coordinates back to IRTF2014 2005.0, if that is what the Trimble guidance system you are trying to match uses it could be different.
But you would still have a small offset at that point due to the reference frame, but you could then nudge over the last little bit.
The good news is in all of these systems 1m is still a meter, so if you get close and you know your East and North nudge offsets you can tweak your base coordinates to match.
Hello. What am I doing wrong in the settings. If I have a configuration as in the first photo, I get a FIX at the U-center. If I write fixed coordinates into the configuration as in the second photo, then I get only TIME / DGNSS. Corrections are received from rtk2go.
I feel there is a conflict in the sense that corrections are coming from RTK2GO and seems the receiver is on a tractor. How come the receiver seems to be configured as a base station? The rover needs no survey, neither fixed position coordinates.
Maybe I didn’t explain correctly. When I connected U-CENTER to F9, TIME / DGNSS is displayed. And already on the rover FIX. So that everything is in order.
